Welcome back. In this video, I want to cover another part of the AWS global network, specifically the Edge Network, and that's AWS Local Zones. Now, this is a key architectural concept that you'll need to understand for all of the AWS exams, and especially so for the real world. So, let's jump in and get started.

Now, before we talk about local zones, let's just refresh our memory on what the typical region and availability zone architecture looks like without local zones. So, we have a region, and let's say that this is US West 2, and within this, we have three availability zones: US West 2A, US West 2B, and US West 2C. And then running in this region across those availability zones is a VPC.

Now, an AWS region has high performance and resilient internet connections, and sitting between these and the AWS private zone is the AWS public zone. So, this is the zone where all of the AWS public services for that region run within. And then lastly, on our right, we have our business premises. What we know about this architecture so far is that it scales. It can grow with your requirements, and that's really important because this is fully managed within the region. We also know that it's resilient to failure. The failure of one availability zone won't impact other availability zones, assuming a solutions architect has designed a solution which has infrastructure duplicated across all of the availability zones and things in one availability zone consume from that availability zone only, often regionally resilient services.

Now, what I haven't talked about until now is the effects of geographic distance. The availability zones in this region might be hundreds of kilometers away from the business premises. Now, this distance, even assuming that we're using fiber, can cause latency. And this latency causes a reduction in performance, and this performance impact is noticeable at this distance. To many use cases, a few milliseconds of latency might not sound like much, but for applications which are sensitive to latency, this can really matter. An example might be a financial trading application. Even if we use Direct Connect, physics and the speed of data transfer from point A to point B matters. So, how can we fix this? Well, we can use AWS local zones, and let's see how this changes the architecture.

Let's adjust the diagram a little and make it easier to see. And we're going to add some subnets in availability zones 2A, 2B, and 2C. And we'll also have some EC2 instances running in these subnets. When we're discussing local zones, we can refer to this region as the parent region. So, this region is the parent region to any local zones which operate in the same geographic area. So, we're also going to add some local zones to this architecture. Now, these are identified starting with the region name and then a unique identifier for the local zone. In this example, we have US West 2 and then LAS-1, which is a local zone in Las Vegas. And we have US West 2 as its parent region. So, you can see the link between the local zone and the parent region because you can read the parent region at the start of the local zone name.

Now, it's possible to have multiple local zones in a given city. For instance, in this example, we have US West 2-LAS-1A and 1B. And both of these are in Los Angeles. Notice how they use the international city code to identify them. Now, think of these as related to the parent region, but they operate as their own independent infrastructure points. So, they have their own independent connections to the internet. And additionally, generally, they also support Direct Connect, which means you can achieve high performance, private connectivity between your business locations and these local zones.

Now, different services support local zones in different ways. And over the course of your studies, you're going to learn how. With EC2 and VPCs, the VPC is simply extended by creating subnets within the local zones. And then within these subnets, you can create resources as normal, utilizing the proximity of the local zone. So, these resources benefit from super low latencies. The performance between the business premises and the local zone is at the extreme end of what's possible because of the smaller geographic separation between the local zone and your business premises.

Now, an important thing to keep in mind is that some things within the local zones still utilize the parent region. So, in this example, the subnets created in the local zones behave just like those in the parent region, and they have private connectivity just like any other subnets would. Local zones have private networking with the parent region. So, remember that. However, if we create EBS snapshots, then these use S3 in the parent region. It means they still benefit from the AZ replication across all availability zones within that region that snapshots would normally benefit from. So, certain things occur within the local zone, but certain things rely on the parent region. And one common example is EBS snapshots.

Now, let's finish up this video with some key summary points because for most of the AWS certifications, you only need to have this high-level architectural overview. So, think about local zones as one additional zone or one additional availability zone, so they don't have built-in resilience. Conceptually, one zone runs in one specific facility. So, you can think of them like a single availability zone but near your location. So, they're closer to you, so they have lower latency, and lower latency means better performance. So, just imagine taking one of the availability zones within a region and duplicating it but putting it in a building next to your business premises. Now, it won't always be that close, but there are some businesses which are built very close to these AWS local zones by design. So, you're able to get really close to the AWS infrastructure.

Now, not all AWS products support using local zones, and for the ones that do, many of them are opt-in and many of them have limitations. So, if you're ever going to utilize local zones, you need to make sure that you check the AWS documentation for an up-to-date overview of what's supported within the local zones in your specific geographic area. And I've made sure to include a link attached to this video which gives you up-to-the-minute overviews for all of the AWS local zones.

Now, Direct Connect to local zones is generally supported, and this allows local zones to be used to support any extreme performance needs or performance requirements. And once again, local zones do utilize the parent region for various things, and one example is EBS snapshots are taken to the parent region and replicated over S3 in that parent region.

Now, just to summarize this, you should use local zones as an architect when you need the absolute highest level of performance. Local zones, much like CloudFront edge locations, are much more likely to be positioned closer to your business than the parent region and any of the normal availability zones. But if you do utilize local zones, you need to make sure that they do offer the functionality that you require. So, essentially, this is just another tool that you can use to build architectures as a solutions architect.

Now, this is everything I wanted to cover in this video. I just wanted to give you a high-level overview of the architecture of local zones. So, go ahead and complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, I want to cover Amazon SageMaker from a high-level perspective. Now, this is a product which you need to understand at only a foundational level for most AWS exams, but in depth for some others. If any additional knowledge is required for the course that you're studying, there will be follow-up deep dive videos. But if you only see this one, this is all that you'll require.

Now, I have to apologize in advance. I don't like creating lessons which I don't think add much real-world value. SageMaker is a special kind of product where you're only going to be able to use it effectively if you have some practical experience. But because you don't need to understand how to use it in depth for most of the AWS exams, I don't really want to waste your time going into significant depth. It's a fairly niche product to use in the real world. So, this lesson is really just going to present some high-level features. And you're not going to get as much value doing it this way, but it's just one of those things that we have to do in this way to avoid wasting time. So, you probably won't really like this lesson, but just stick with it because it will benefit you for the exam.

Now, let's jump in and get started straight away. So, SageMaker is actually a collection of other products and features all packaged together by AWS. And it's an implementation of a fully managed machine learning service. So, it essentially helps you with the process of developing and using machine learning models. So, this includes data fetching, cleaning, preparing, and then training and evaluating models, and then deploying those models and then monitoring those models and collecting data. So, it's used for this entire machine learning lifecycle, and it's AWS's way of implementing one product or one container of products which can help you for this entire lifecycle.

Now, there are a few key things that you need to be aware of about SageMaker. The first is SageMaker Studio. And this is essentially an IDE or integrated development environment for the entire machine learning lifecycle. So, this allows you to build, train, debug, and monitor machine learning models. So, think about this as a development environment for the machine learning lifecycle. If you see this mentioned on the exam, you understand that at a high level what it is.

Now, within SageMaker, you have the concept of a SageMaker domain. And I want you to think about this as isolation or groupings for a particular project. So, you're provided with an EFS volume, separate users, you can use applications, policies, and different VPC configurations. So, just think of this as almost a container for a particular project. And when you start using SageMaker, you'll have to create a SageMaker domain in order to interact with the product.

Next, we've got containers. And these are essentially Docker containers which are deployed to specific machine learning EC2 instances. So, these are specific types and sizes of EC2 instances which start with ML and they're designed specifically for machine learning workloads. Now, these Docker containers are machine learning environments which come with specific versions of the operating system, libraries, and tooling for the specific task that you're wanting to accomplish. And there are many different pre-built containers that you can utilize with SageMaker.

Now, SageMaker is also capable of hosting machine learning models. So, you can deploy machine learning models as endpoints that your applications can then utilize. And there are various different hosting architectures which are either based on serverless or consistently running compute. Now again, this is beyond the scope of this high-level architecture video, but I did just want you to be aware that SageMaker can host your machine learning models. This is something that you need to be aware of for the exam.

And then finally, be aware that SageMaker itself has no cost, but the resources that it creates do have a cost. And it's fairly complex pricing because of the range of services which can be created by SageMaker. And another important concern about SageMaker is because of the complexity of those resources and because of the compute requirements of machine learning in general, the resources which are deployed can be relatively large and carry significant cost. And to help you with this, I'm going to include a link attached to this video which details some of the important cost elements for this product.

Now, at this point, that's everything I'm going to cover in this video. I need to apologize again, because I know it's at a very abstract and high level. But the only thing that you need to be aware of for most of the AWS exams is how it works structurally at a high level. There's only one exam where you need additional levels of understanding, and that's the machine learning specialty exam. So, if you're studying this as part of the machine learning course, you're going to find many other videos which are deep diving into how SageMaker works, including advanced demos or mini projects which are going to give you practical experience. But if you only see this one video, it means you're studying a course which only needs this really high-level understanding.

And with that being said, that's everything I wanted to cover in this video. So, go ahead and complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this video, I'm going to continue my super high-level overview of the AWS machine learning services, this time looking at Amazon Fraud Detector. Now, once again, for nearly all of the AWS certifications, a very high-level overview is more than enough. If you do need any additional knowledge for the course that you're studying, I will have follow-up videos, but this one just covers the basics, so let's jump in and get started.

Now, Amazon Fraud Detector, as the name suggests, is a fully managed fraud detection service. This allows you to look at various historical trends and other related data and identify any potential fraud as it relates to certain online activities. So, this might include things like new account creations, payments, or guest checkouts. Now, the architecture of this, much like the other managed machine learning services, is that you upload some historical data and you choose a model type.

Now, for this particular service, we have a few different model types. First, we have online fraud, and this is designed for when you have little historical data and you're looking to identify any problematic events, such as new customer accounts. You might not have any data for a particular customer—logically enough, they're just signing up for an account. So, this looks at general trends, such as if there are any surrounding elements of concern around this particular sign-up for this particular user.

Now, we also have another model type, which is transaction fraud. This is ideal for when you do have a transactional history for that customer, and this transactional history can be used to identify any suspect payments. This is fairly commonly used when you're performing credit card transaction validation. Generally, you do have a full purchase history for a customer, so for example, what stores are used, the types of purchases that are used, the value of those purchases, the countries that the purchaser is in or the store is in, as well as the amounts and times of day. So, you can build up a fairly good profile for a given customer of what their normal transactions are like, and this is what this particular model allows. You can import the transactional history for one or more customers and use this to identify any suspect payments.

And then the last is the account takeover model type, and this can be used to identify any phishing or other social media or social-based attacks. For example, if somebody signs in from a completely different location or if they're referred from a certain site, all of this can be taken into account to identify if this user has potentially been affected by an account takeover attempt.

Now, the way that this product works is that all of the various events are scored, and then you can create rules, which is basically a type of decision logic, and use this to react to these scores based on your business activity or business risk. So, Amazon Fraud Detector is another back-end style service, which generally you're going to be integrating into your applications or environments rather than using interactively from the console.

Now, this high-level understanding is everything that you'll need for most of the AWS exams, so I'm going to limit this video to covering just this high-level overview. So, at this point, we have finished. Go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, I'm going to continue my super high-level overview of the AWS machine learning services. This time, I'm looking at Amazon Forecast. Now, this is not weather forecasting, but forecasting based on time series data. Once again, for nearly all of the AWS certifications, a very high-level overview is more than enough. If you need any additional knowledge, I'll have follow-up videos, but this one just covers the basics. So let's jump in and get started.

Amazon Forecast provides forecasting for time series data. This means things like predicting retail demand, supply chain, staffing levels, energy requirements, server capacity, and web traffic. So, any type of data that is time series, where you have a large amount of historical and related data, can be used with Forecast to provide the ability to forecast future trends and events. Now, the way you do this is by importing historical data and related data. Simple historical sales data might include just an item being sold and then a date and timestamp. You can use this to trend how popular that item is throughout the time series and use that for simple forecasting.

Related data includes extra contextual information, such as any promotions that might have been running throughout a time period and even things like the weather, which can influence the data over a particular time period. So, Forecast uses both of these different sets of data—historical and related—and it understands what's normal over a particular time period. The output of this will be a forecast and forecast explainability. Now, the forecast itself is simple enough to understand. It allows you to trend out the future demand for a particular thing or understand the future requirements for a particular thing. The explainability, though, goes into more depth. It allows you to extract the reasons for changes in this demand.

For example, I mentioned the weather as a related data item. Well, in the retail world, weather can have a huge impact on the general demand levels for products. Generally, all products will be influenced to some base level by the weather. Some weather patterns may cause people to stay at home, while others may encourage people to go shopping. Now, this obviously has a much greater effect for physical shopping in a retail establishment versus online shopping, but other elements of weather can also affect online shopping. For example, if it's raining heavily, you might see a demand increase for certain types of clothing. So, this is all involved in the ability to forecast future demand based on historical data, and this is what this product provides.

Amazon Forecast is a managed service that provides the ability to get access to forecasting for time series data. You can interact with the product from the web console, where you can use it to see visualizations, such as past data, future forecasting, and explore the explainability of that forecast. It can also be interacted with using the CLI, APIs, and the Python SDK. Now, once again, this is a back-end service. It's generally something that you're going to use as part of either a business process or integrating it with your application. It's relatively niche in its use, and so for most AWS exams, this high-level overview is everything that you'll need.

If you do need any additional knowledge for the course that you're studying, there will be additional theory and/or practical videos. But at this point, that's everything I wanted to cover in this high-level video. Go ahead and complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, I want to cover the high-level architecture of the Amazon Translate product. This is another machine learning product available within AWS, and if you need any other knowledge beyond architecture, there will be additional videos following this one. If you only see this video, don't worry, it just means that this is the only knowledge that you need. Now, let's just jump in and get started straight away.

Amazon Translate, as the name suggests, is a text translation service based on machine learning. It translates text from a native language to other languages, one word at a time. The translation process is actually two parts. First, we have the encoder, which reads the source text and then outputs a semantic representation, which you can think of as the meaning of that source text. Remember that the way certain points are conveyed between languages differs. It's not always about direct translation of the same words between two different languages. So, the encoder takes the native source text and outputs a semantic representation or meaning, and then the decoder reads in that meaning and writes it to the target language.

Now, there's something called an attention mechanism, and Amazon Translate uses this to understand context. It helps decide which words in the source text are the most relevant for generating the target output, ensuring that the whole process correctly translates any ambiguous words or phrases. The product is capable of auto-detecting the source text language. So, you can explicitly state what language the source text is in, or you can allow that to be auto-detected by the product.

In terms of some of the use cases for Amazon Translate, it can offer a multilingual user experience. All the documents within businesses are generally going to be stored in the main language of that business. However, this allows you to offer those same documents, such as meeting notes, posts, communications, and articles, in all the languages that staff within your business speak. This can make it much easier for organizations with offices in different countries to operate more efficiently. This also means that you can offer things like emails, in-game chat, or customer live chat in the native language of the person you're communicating with, which can increase the operational efficiency of your business processes. It also allows you to translate incoming data, such as social media, news, and communications, from the language they're written in into the native language of the staff interpreting those incoming communications.

More commonly, Amazon Translate can also offer language independence for other AWS services. For example, you might have services such as Comprehend, Transcribe, and Polly, which operate on information, and Translate offers the ability for these services to operate in a language-independent way. It can also be used to analyze data stored in S3, RDS, DynamoDB, and other AWS data stores.

Generally, with this product, you're going to find that it's used more commonly as an integration product. So, rather than using it directly, it's more common to see it integrated with other AWS services, other applications (including ones that you develop), and other platforms. So, in the exam, if you see any type of scenario that requires text-to-text translation, think Translate. If you see any scenario that might need text-to-text translation as part of a process, Translate can form part of that process. You might want to translate one language into another and then speak that language, or you might want to take audio in one language, output text, and then translate that to a different textual language.

Keep in mind that Translate is often used as a component of a business process. So, really keep that in mind. It's not always used in isolation. Now, with that being said, that is everything I wanted to cover in this video. Go ahead and complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, we're going to be doing a really quick overview of Amazon Transcribe. Now, there isn't a lot to understand about this product, so let's just jump in and get started straight away. Amazon Transcribe is an automatic speech recognition (ASR) service. Essentially, the input to this product is audio, and the output is text. It takes audio in the form of speech and then outputs the text version of that speech. It offers various features that improve this process, such as language customization, filters for privacy, audience-appropriate language, and speaker identification. In addition, you can configure custom vocabularies and create language models specific to your use case.

The product operates on a pay-per-use model, and you're billed per second of transcribed audio. Now, to make it easier to understand how it works, I'm going to switch across to my console and give you a quick demonstration. I'm at the AWS console, logged in as the IAM admin user of my general AWS account, and I'm in the Northern Virginia region. I will go ahead and click in the search box at the top, type "transcribe," and then click to move to the Transcribe console. Once I'm here, I'll click on "real-time transcription" because this is what I'll use to demo the product.

When I get there, I'll click on "start streaming," say something into my microphone, and then click "stop streaming." I say, "I like cats, dogs, chickens, and rabbits. Spiders not so much." At this point, we can see that the product has transcribed what I said into my microphone into text, and by clicking here, we could download a full transcript of this audio. If we scroll down, we're able to look at some of the more advanced features of the product. You can specify a specific language or set it to auto-detect the language. You can enable or disable speaker identification, set various content removal settings such as vocabulary filtering, or redact personally identifiable information. If we expand customizations, it's here where we can specify custom vocabulary, partial result stabilization, or a custom language model. We can even expand this to look at application integration.

So, this product is capable of being integrated with your own applications or other AWS products, and it's listed in the menu on the left, where you can interact with specific versions of Amazon Transcribe, such as Call Analytics or Transcribe Medical. Now, both of these are beyond the scope of what I want to cover in this video, but I did want you to be aware that they exist.

Now that we've completed the walkthrough, let's move on to the second part of the theory I'll be covering in this video. In terms of the use cases of Amazon Transcribe, it allows you to do full-text indexing of audio, so you can convert audio into text and use that text for full-text search. It can also be used to create meeting notes. If you use the product to ingest audio from any meetings that you conduct, you can have full text records of those meetings. Additionally, it can be used to generate subtitles, captions, or transcripts of any video your organization uses. The product comes in a number of specific flavors, including Transcribe, Transcribe Medical, and Transcribe Call Analytics. In the Call Analytics version, you're able to ingest audio from any phone calls and assess the characteristics, perform summarization, and analyze categories and sentiments of the people talking on that call.

The product is also capable of being integrated with your own applications through APIs, as well as being able to integrate with other AWS machine learning services. Amazon Transcribe can convert speech into text, and then that text can be ingested by other AWS machine learning products to perform further analysis. Now that's the product at a high level, and in this video, we're just sticking to this high-level summary. If the topic you're studying requires any additional information, there will be further theory and practical videos. However, for most AWS certifications, this is all the information you'll require. So go ahead and complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this video, I want to briefly talk about Amazon Textract. Now, much like the other machine learning products which I'll be covering, in this video I'll only be covering Textract from a high-level architecture perspective. If more knowledge is required, there will be additional theory or practical videos, but don't be alarmed if this is the only one. That just means that this is the only level of knowledge that you'll require. Now, let's jump in and get started straight away.

So, Amazon Textract is another machine learning product available within AWS. This product is used to detect and analyze text contained within input documents. And currently, input documents mean JPEGs, PNG, PDF, or TIFF files. Now, these are the inputs, and then the outputs are extracted text, the structure of that text, and any analysis which can be performed on that text. So, this is a product that can take in one of the supported document formats and extract any relevant information. As you'll see, this can include things like generic documents, identity documents, or receipts or invoices. I'll be demoing a couple of these from within the AWS console later on in this video.

Now, for most documents, the product is capable of operating in a synchronous way, so real time. If you're inputting a normal-sized document, then you can expect the results of that analysis almost immediately after you submit. For large documents, these are processed in an asynchronous way. So this might be a large PDF, I think hundreds of pages. For this, you might have to submit the job and then wait for processing to occur. The product is pay-as-you-use, but it does offer custom pricing available for large volumes.

Now, in terms of the use cases of this product, at a high level, it offers the detection of text and the relationship between that text. So, for example, you might have a receipt or invoice, and it will be able to detect all of the relevant items, such as prices and products, dates, as well as any interaction between those different elements. So, it might know, for example, that a particular product line has a specific price, and this has a specific element of tax. It also generates metadata, such as where that text occurs. For particular types of documents, it offers specific types of analysis. For generic documents, it might be able to identify names, addresses, and birth dates, but for receipts, it might be able to identify prices, vendors, line items, and dates. For identity documents, it can also do abstraction of certain fields. So, you might have driver's licenses, which offer a driver’s license ID, and then passports, which offer passport IDs. The product is capable of assessing both of these and abstracting that into a document ID field.

So, you can analyze many different types of identity documents and store all of that data in a common database schema, which has abstracted field IDs, such as document ID. Now, again, this product is capable of either being used from the console UI or from the APIs. It can be integrated with any applications that you either develop or architect. As well as this, it can also be integrated with other AWS products and services, including other machine learning products. Now, it's going to be far easier for you to understand how this product works if I give you a brief example. So, I'm going to go ahead and switch across to my AWS console and step through a couple of examples. So let's go ahead and do that.

Okay, so I'm at the AWS console and logged into the IAM admin user at the general AWS account. I have the Northern Virginia region selected. So, I'm just going to go ahead and click in the search box at the top and type Textract, and then click to move to the Textract console. I'm just going to step through a very simple set of examples. So, I'm going to go ahead and click Try Amazon Textract, and the console itself will give you a couple of examples of how it can be used. In this particular case, it’s analyzed a vaccination card. You can see that on this card, the data is in both a structured and unstructured format. So, we have a number of the fields that are stored in a relatively structured way, such as last name, first name, date of birth, and a patient number. We also have a table below it, which stores the dates of the various vaccinations.

As you might know, if you've taken a number of vaccinations, this can either be typed, handwritten, or stamped, and it’s often not always within the nice confines of a particular area of the table. Now, this product is able to extract all of the important elements. You can see that as I'm hovering my mouse here, it's able to identify the particular elements of data. So, I can click on all of these individually, and you can see that they're now selected in this results table on the right. It's intelligent enough to identify these individual elements, even if they're slanted or different sized or in a hard-to-read format. So, this is a simple vaccination record, and we can see all of the information stored on the right.

We do have different sample documents, though. If we click on this dropdown, we've got a pay stub. This is obviously more complex with a larger amount of data, and as you can see, it’s still identified all of this information. So, it's extracted all of the key values from this table. Now, what's even cooler is if I click on tables on the right, we can see that for this specific table, it’s even got the intelligence not only to extract the data but also to extract the actual table structure itself. I can move through the document and see multiple tables, each containing information. As you can see, a lot of these are really complex in the formatting, and yet the product has managed to extract all of the data with no problems. We’ve got other types of documents. For example, this is a loan application, and again, the text extract product is capable of extracting all of this, including larger blocks of text and enabling us to browse through and deal with that data, both interactively from the console, but we could also do this from the APIs from within our own application.

Now, the product also has some specific types of analysis that it can do. So, if I click on Analyze Expense, it's able to perform an extraction of data on a sample receipt. You can see in this example, not only is it able to extract textual data, but it can also extract vendor information from these receipts. We can also perform the same type of process to analyze ID documents. In this case, we're showing a driver’s license, and it’s able to extract this number on this driver’s license to be a document number. We can see this document number here. It’s abstracted this driver’s license number to be the document number. If we switch to a passport document, in this particular case, it's going to take the passport number and it will extract this also into a document number.

Now, if you're doing identity document verification, for example, if you run an online application and need to perform know-your-customer or anti-money laundering techniques, where you need to identify and verify ID documentation, then this ability to take specific fields of certain identity documents and abstract them away and use the same data structure is really valuable. Now, this is everything I wanted to cover about the Textract product. Again, this is a basic architectural level introduction. If for the particular topic that you're studying, you require additional information, then there will be videos following this one, which go into more depth, either theory or practical. But if you don’t see any additional videos on this product, don't worry—it simply means that for whatever topic you're studying, this is all the information you require.

At this point, though, that is the end of this video, so go ahead and complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this video, I want to talk about another really cool AWS product called Amazon Recognition with a K. Now let's jump in and get started because I'm actually super excited to step through this product and how it works. Recognition is a deep learning-based image and video analysis product. Deep learning is a subset of machine learning. So this is to say that Recognition can look at images or videos and intelligently do or identify things based on those images or videos.

Specifically, it can identify objects in images and videos such as cats, dogs, chickens, or even hot dogs. It can identify specific people, text—for example, license plates—activities, and what people are doing in images and videos. It can help with content moderation, so identifying if something is safe or not. It can detect faces, analyze faces for emotion and other visual indications, and compare faces, checking images and videos for identified individuals. It can do pathing—so identify movements of people in videos—and an example of this might be post-game analysis on sports games, and much, much more. It's actually one of the coolest machine intelligence services that AWS has, and that's saying a lot.

The product is also pay-as-you-use, with per-image pricing or per-minute-of-video pricing. It integrates with applications via APIs and it's event-driven, so it can be invoked, say, when an image is uploaded to an S3 bucket. But one of its coolest features is that it can analyze live video by integrating with Kinesis video streams. This might include doing facial recognition on security camera footage for security-type situations, distinguishing between the owner of a property and somebody who's attempting to commit a crime. All in all, it's a super flexible product.

Now generally, for all of the AWS exams, you will need to have a basic understanding of the architecture. There are some AWS exams—for example, machine learning—where you might need additional understanding. And if you're studying a course where that additional understanding is required, there will be follow-up videos. In general, though, it's only a high-level architecture understanding. And one example architectural flow might look something like this: An image containing Whiskers and Woofy is uploaded to S3. Now we've configured S3 events, and so this invokes a Lambda function. The Lambda function calls Recognition to analyze the image. It returns the results, and then the Lambda function stores the metadata together with a link to the image into DynamoDB for further business processes.

To give some context as to the other things that Recognition can do, let's just take an entirely random selection of images from the internet. Recognition can identify celebrities such as Ironman. It can also identify mic chambers, that I think as a machine learning service, it might be slightly biased. It can identify text in images or videos, such as license plates on cars or other internet memes. It can even identify objects, animals, or people in those same memes. For faces specifically, it can identify emotions or other attributes. So, for example, identifying this random doctor is a male who currently has his eyes open and is looking very, very serious rather than being happy in any way.

So that's Recognition. If you have questions in the exam which need general analysis performing on images or videos for content, emotion, text, activities—anything I've mentioned in this lesson—then you should default to picking Recognition. It's probably going to be the correct answer. Now with that being said, that is everything I wanted to cover in this video. 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 video, I want to briefly talk about the Amazon Poly product. This is going to be another very brief video, and all you need to know for most AWS exams and to get started in the real world is the product's high-level architecture. If there are any other knowledge requirements for the topic that you're studying, there will be additional videos following this one. If not, don't worry—this is everything that you'll need to understand. Now, let's just jump in and get started.

Amazon Poly, at a high level, converts text into life-like speech. In the example below, it takes the sentence “I like cats, dogs, chickens and rabbits, spy does not so much,” and generates a life-like voice or life-like speech from it. Essentially, the product takes text in a specific language and produces speech in that same language. This is really important to understand: Poly performs no translation. It can only take text in a given language and output speech also in that language.

There are two modes that Poly operates in. The first is standard TTS, or text-to-speech, which uses a concatenative architecture. It essentially takes phonemes—the smallest unit of sound in the English language. For example, for the letter “A,” the phoneme is “a.” Poly takes these smallest units of configuration and uses a concatenative architecture to build patterns of speech. The second mode is neural text-to-speech. This approach takes those phonemes, generates spectrograms, puts the spectrograms through a vocoder, and that process generates the output audio. This is a much more complex way of generating speech using artificial intelligence. It is much more computationally heavy, but what it does is result in much more human or natural-sounding speech.

The product is also capable of outputting in different formats such as MP3, Agvorbis, or PCM. The output format that you'll choose depends on how you're intending to integrate Poly with other products. For example, you might choose PCM if you're looking to integrate with various AWS products. It fully depends on what your architecture is.

There are a few final points that I want to cover. First is that Poly is capable of using the Speech Synthesis Markup Language (SSML). This allows you to provide additional context within the text so you can control how Poly generates speech. Examples include emphasizing various parts of sentences, pronouncing things in certain ways, whispering certain components of the text, or using an over-exaggerated newscaster speaking style. These are all things you can control with SSML.

Again, Poly is the type of product that's going to be integrated with other things. For example, there’s a WordPress plugin that allows articles on WordPress blogs to be spoken. Poly can be integrated with other AWS services where you need speech to be generated from text, or you can integrate Poly with your own applications using the APIs. This is another product that will more often be used as part of a larger solution.

Now, this isn’t a product where you’re going to get much benefit from seeing it in action. It’s a very niche product that you’re only ever going to use in certain situations. For most AWS exams, you just need a high-level architectural overview. At this point, that is everything I wanted to cover in this video. Go ahead and complete the video, and when you’re ready, I’ll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover the high-level architecture of Amazon Lex. Amazon Lex is a product that allows you to create interactive chatbots. For most areas of study and for solutions architects working in the real world, you only need a basic level of understanding, and that's exactly what this video will provide. If you need to know anything beyond this, the course you're studying will likely include follow-up videos to this one. If not, don't worry—this video will cover everything that you need. Now let's jump in and get started.

Amazon Lex is a back-end service. It's not something you're likely to use from a user perspective. Instead, you'll use it to add capabilities to your application. Lex provides text or voice conversational interfaces. For the exam, remember “Lex for voice” or “Lex for Alexa.” If you're familiar with Amazon voice products, just know that Lex powers those products—it provides the conversational capability. It's what lets the lady in the tube answer your questions.

Lex provides two main bits of functionality. First is automatic speech recognition (ASR), which is simply speech-to-text. Now, I say “simple,” but doing this well is exceptionally difficult. If any of you have tried using Siri, Apple’s voice assistant, you may have noticed how often it gets things wrong compared to the Alexa product. That’s because Siri doesn’t do ASR as well as Lex. And for any lawyers listening—this is just my opinion.

Lex also provides natural language understanding (NLU) services, which allow it to discover your intent and even perform intent chaining. Imagine the act of ordering a pizza. You might start the conversation by saying, “Can I order a pizza please?” or “I want to order a pizza,” or even “A large pepperoni pizza, please.” The intent—the thing you want to do—is ordering pizza, and it's Lex's job to determine that. But what about your next sentence? “Make that an extra large, please.” Lex needs to understand that this second statement relates to the first. As humans, this is easy—we're good at natural language processing. Computers historically haven't been, but Lex enables voice and text understanding in your applications without needing to code that functionality yourself. You simply integrate Lex, and it does the hard work for you.

As a service, Lex scales well and integrates with other AWS products such as Amazon Connect. It’s quick to deploy and uses a pay-as-you-go pricing model, meaning it only costs when you’re actively using it. This makes it ideal for event-driven or serverless architectures. In terms of use cases, Lex can help you build chatbots—the kind that pop up on websites asking if you need help—or automated support chats for logging tickets. You can also build voice assistants that respond when you ask for something, just like the lady in the tube. Use cases also include Q&A bots or enterprise productivity bots—basically, any interactive bot that accepts text or voice and performs a service.

Let’s now review some of the key Lex concepts. Lex provides bots that are designed to interactively converse in one or more languages. I previously mentioned the term "intent." This represents an action the user wants to perform—things like ordering a pizza, ordering a milkshake, or getting a side of fries. In addition to intents, we have the concept of utterances. When creating an intent, you can provide sample utterances—these are ways an intent might be expressed. So to order a pizza, milkshake, or fries, a user might say “Can I order,” “I want to order,” or “Give me a.” These are all different ways of expressing or uttering an intent.

Along with configuring utterances, you also need to tell Lex how to fulfill the intent, and this is often done using Lambda integration. If Lex understands that the user wants to order a pizza, it needs a way to initiate that process—Lambda functions are typically used for this purpose. Lambda works especially well in event-driven architectures, making it a natural complement to Lex. Additionally, Lex includes the concept of a slot, which you can think of as a parameter for an intent. These might include the size of the pizza (small, medium, or large), the type of crust (normal or cheesy), and other similar details. You can configure slots as required parameters that Lex must gather from the user during the interaction.

Just to reiterate, Lex is a product you won’t usually interact with directly through the console. It’s something you’ll architect into your applications. If you want to provide interactive voice assistance via a chat or voice-capable bot, you’ll use Amazon Lex. So remember this for the exam.

With that being said, that is everything I wanted to cover in this video. Go ahead and complete the video, and when you're ready, I’ll look forward to you joining me in the next.

Welcome back, and in this video, I'm going to quickly discuss the functionality provided by Amazon Kendra. This is something for which you only need the highest level of exposure for most AWS exams. If you need to know more than this basic level, there will be other videos diving deeper into Kendra's functionality, but this video will stick to the basics. So if it's the only video on Kendra in the course that you're taking, that's fine—this is everything that you need to know. Let's jump in and get started.

Kendra is an intelligent search service whose primary aim is to mimic the experience of interacting with a human expert. The idea is that you can use Kendra to search a data source and feel as though you're getting answers from a human specialist on that topic. It supports a wide range of question types, beginning with simple factoid-based questions such as "who," "what," and "where." You might ask questions like "Who wrote this book?" or "What is the best type of animal?"—of course, it's cats—or "Where is this particular place?" Kendra will attempt to surface the relevant information in a way that replicates the quality and context awareness you'd get from a human.

Another type of question Kendra supports is descriptive questions, such as "How do I get my cat to stop being a jerk?" In these cases, Kendra needs to understand not only the text of the question but also the intent behind it—what you're actually trying to find out. Lastly, we have keyword-type questions, which are much more nuanced than they may appear. For example, if you ask, "What time is the keynote address?" the word "address" could be interpreted in multiple ways—either a location or, in this context, a speech. Kendra must determine the actual intent of the query, which is a complex problem and one of the reasons why Kendra adds significant value as a service.

Kendra is a backend-style service used to provide functionality to the applications or systems you design and implement. Typically, you'll incorporate search capability into an application and use Kendra as the backend that powers it. Let's go over some of the key concepts in Kendra. It begins with an index, which is a searchable block of data organized for efficient querying—this is what Kendra searches against when users submit queries. Then there's the data source, which refers to the original location of your data; Kendra connects to and indexes data from this source.

Examples of data sources include S3 buckets, Confluence, Google Workspaces, RDS, OneDrive, Kendra Webcrawler, WorkDocs, FSx, and many others. There are too many to list here, but I’ll attach a link to the video for a full list. The idea is to configure Kendra to synchronize a data source with an index on a schedule, keeping the index up-to-date with the data at the original source.

The actual content being indexed consists of documents, which may be either structured or unstructured. Structured data includes things like frequently asked questions, while unstructured data may be HTML files, PDFs, or plain text documents. Again, there are many more types supported, and I’ll include a link with a full overview of them.

Kendra integrates with a number of AWS services, such as IAM for access control and the IAM Identity Center (formerly AWS SSO) for single sign-on. Just to emphasize once more, Kendra is a backend product. It provides capabilities to other applications via APIs, and while you may use the AWS Console for the initial setup, Kendra is not typically interacted with directly by end users.

That covers everything you need to understand about Amazon Kendra for most AWS exams and as a foundational introduction for practical use as a solutions architect. At this point, go ahead and complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this video I want to very briefly talk about Amazon Comprehend and this is a natural language processing service available within AWS. In short you input a document and it develops insights by recognizing the entities, keyphrases, language sentiments and other common elements of that document. Now this video is going to cover the basics. If you need to have a greater level of understanding for the thing that you're studying there will be follow-up videos. But in this video we're going to cover the important high level elements so let's jump in and get started.

So I mentioned moments ago that Amazon Comprehend is a natural language processing service and that you input a document so conceptually think of this as text and then the output is any entities, phrases, language, personal identifiable information so any important elements of a document is surfaced by the Comprehend service and you get access to all of these things which have been identified. Now the Comprehend service is a machine learning service and it's based on either pre-trained or custom models so you've got the option of using either of these. Now the product is capable of doing real-time analysis for small workloads or asynchronous jobs for larger workloads and the service can be used from the console or command line for interactive use or you can use the APIs to build Comprehend into your applications.

Now it's going to be far better for you to gain an understanding of this product if you can see it operate visually. So I'm going to go ahead and switch across to my console and just give a brief walkthrough of exactly what the product can do. Now you can either watch me do this walkthrough or you can follow along within your own environment but I'm going to go ahead now and switch across to my AWS console.

Okay so I'm currently logged into my AWS console I'm logged in as the IAM admin user of the general AWS account and as always I've got the Northern Virginia region selected. Now once I'm here I'm going to click in the search box at the top and just go ahead and type Comprehend and then click on Amazon Comprehend. When you first move to the Comprehend service you'll see something like this you've got the hamburger menu on the top left where you can access all of the detailed areas of the console but just to illustrate this I'm going to go ahead and click on launch Amazon Comprehend.

Now when you first launch the product it does give you some sample input text so that you can see exactly how the product works and we're going to start with this sample text. So if I just scroll down slightly under input text you'll be able to see the analysis type is built in and this allows you to have real-time insights based on the AWS built-in models so this is one of the machine learning models which I discussed in the theory part of this lesson. We've also got custom and this allows you to create custom models which fit your data. In this case though we're going to use the built-in analysis type and if I just scroll down this is sample input text it essentially describes an individual, a company, it includes some credit card information as well as other personally identifiable information.

So what I'm going to do is go ahead and click on analyze to analyze this sample input text. So examples of what we get are entities so it searched the input text and it's identified anything which it classifies as an entity and examples of this are persons so the person entity and it identifies a person here which is the recipient of this email as well as the sender. So John is identified as a person and it has a 0.99 plus confidence. Now this is expressed from a value from 0 which is 0% through to 1 which is 100% and the confidence level shows how confident comprehend is of its identification. In this case it's over 99% sure that John is a person.

Next we have any company financial services and this has been identified as an organization again with a high level of confidence. We have a credit card information and this has been identified as an entity of type other. We have a location so an address and then other again in the form of an email address again with 99% plus confidence.

Now what we can also do is click on key phrases and have it filter based on all of the key phrases within this text. We can click on language and the product is capable of identifying any languages used in the text in this case English with again a 99% confidence. We can click on PII and see any personally identifiable information. So we have names, we have credit card numbers, date and times, bank account numbers, bank routing, address, phone numbers and emails and we can even click on sentiment to identify the overall level of sentiment in this text and for this it's identified the majority as being neutral.

Now what I could do is replace this text so I'm going to do that. So I'm going to click in the box and delete it and I'm going to replace it with this. So my name is Adrian and I'm 1300 and 37 years old, my favorite animals are cats and I own 500 of them and my least favorite are spiders. I'm going to go ahead and analyze this piece of text. This time what I want to focus on is the sentiment analysis so it still identifies all of the keywords, the quantities in the form of my age and the number of cats that I own. It's still identifies the language used which is English and if I click on sentiment we'll see that there is some neutral, positive and negative but overall it's a mixed sentiment and that's because I specified that my favorite something is cats and my least favorite are spiders. So there's a mixed level of sentiment in this text.

If for us to go ahead and delete the spiders part so just have my name, my age, my favorite animals and how many of them I own and then go ahead and analyze this and then go to sentiment. Now we'll see that it's changed. We have a mixture of neutral sentiment and positive sentiment so you can see how sentiment, key phrases and any personally identifiable information can be surfaced from an input document and that's what the Comprehend service does.

Now again this can be used from the console, the CLI and the API so while I'm demonstrating a very simple interaction with this product you can use the API's and integrate it with your applications or other parts of the system so this is an important product to understand both from a solutions architect, developer and operations perspective.

Now at this point that is everything I wanted to cover in this video I just wanted to give you a really high-level overview of how the Comprehend product works. At this point though go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk in a little bit more detail about the backups and resilience options we have with Redshift. In the last lesson you learned how Redshift functions within a single availability zone and so it's at risk from the failure of that availability zone. Based on this as a solutions architect you need to ensure that you design your systems with this in mind. So let's step through the options that we have and I'll try to keep this nice and brief because it's really a continuation of what I covered in the previous lesson.

Now let's say that we have a Redshift cluster in US East 1. It's simplified a bit and so it only has two availability zones, Availability Zone A and Availability Zone B. And as we know now Redshift runs from only one of them. In this example Availability Zone B. Now this means that if we have a failure in Availability Zone B we have problems. The entire cluster will fail and any data it's managing will be at risk.

Redshift provides a number of useful recovery features. First it can utilize S3 for backups in the form of snapshots. Now there are two types of backups supported by the system. Automatic backups which occur once every eight hours or so or every five GB of data change and these occur automatically into S3. They have by default a one day retention period configurable for anything up to 35 days and you get backup capacity totaling the capacity of your cluster for free included in the price of the cluster. Now the snapshots are incremental so only the data changed is stored and charged for. There are also manual snapshots which are performed explicitly by a person or a script or a management application and these have no retention they last until they're removed by a manual process.

For both types of backups because they're stored on S3 you immediately benefit from the resilience profile of S3 meaning that data is replicated between three or more Availability Zones in that same region. So while Redshift isn't resilient across Availability Zones in a region the data managed by Redshift can be. Restoring from snapshots creates a brand new cluster and you can choose a working Availability Zone for that cluster to be provisioned into.

Now if you have a major problem in the region impacting multiple or all Availability Zones in that region then Redshift offers further resilience still. You can configure snapshots to be copied to another AWS region. For example you might choose to copy snapshots to AP, Southeast 2, Land of Kangaroos, Australia. This means your data would be safe even from the failure of the entire original region and a new cluster could be provisioned in this new region quickly in the event of a disaster. Copied snapshots can be set with an independent retention period and this can help minimize costs.

Now that's pretty much all I wanted to talk about with regards to Redshift backups. There are questions in the exam about Redshift and high Availability and resilience options and so I think it's important to cover that and how you can avoid the single AZ risks by using backups effectively and so that's what we've covered in this lesson. With that being said, thanks for watching, go ahead and complete the lesson and then when you're ready you can move on to the next.

Welcome back. In this lesson, I want to briefly talk about Amazon Redshift. Redshift is a complicated product and there's no way that I can talk about it all in this lesson, so I'll be focusing on the things which really matter for the exam from a solutions architect perspective. Now we have a lot to cover, so let's jump in and get started.

Redshift is a petabyte scale data warehouse. A data warehouse is a location where many different operational databases from across your business can pump data into for long-term analysis and trending. It's designed for reporting and analytics, not for operational style usage. And I'll explain what that means in a second. It's petabyte scale because it's been designed from the ground up to support huge volumes of data.

Now Redshift is an OLAP database rather than OLTP, which is what RDS is. The difference is really important to understand for the exam. Online transaction processing or OLTP captures, stores and processes data from transactions in real time. So this is the type of database used when, say, adding orders to an online store or a database of the best cat pictures in the world. It's designed, as the name suggests, for transactions and this means inserts, modifies and deletes. Online analytical processing or OLAP is designed for complex queries to analyze aggregated historical data from OLTP systems. So other operational or OLTP systems put their data into OLAP systems. RDS might put its data into Redshift for more detailed long-term analysis and trending.

Now Redshift stores its data in columns. Imagine a database of all the best cats in the world. Every row in the database represents one cat. It stores the microchip ID, the name, the age, the color, its favorite food and so on. In a row-based or OLTP database, data is stored in rows because you always interact with specific records—specific cats—so updating their ages or editing other attributes. This means that if you wanted to query the average age of all the cats in the database, you'd need to read through every row looking for just one field. With column-based databases, data is stored in columns—so all the names, all the ages, and so on. It makes reporting-style queries much easier and more efficient to process.

Now Redshift is one such database. It's a column-based database and Redshift is delivered as a service just like RDS. It's pretty quick to provision and you can actually provision it, load data, use it for something, and then tear it down when you’re finished. Generally, data is loaded into Redshift before being worked on, but the product includes some really advanced functionality. Two in particular are really cool. First is Redshift Spectrum, which allows for querying of data on S3 without loading it into Redshift in advance. This is great for larger datasets. You still do need a Redshift cluster, but it means that instead of going through the time-consuming exercise of loading data into the platform, you can use Redshift Spectrum to query data on S3.

There's also Federated Query, which is kind of like Federated Identity, but instead of identities, it allows you to directly query data that's stored in remote data sources. So essentially, you can integrate Redshift with other databases—foreign or remote databases—and query their data directly. Now Redshift integrates with other AWS tooling such as QuickSight for visualization and it has a SQL-like interface for data access. It allows you to connect using JDBC and ODBC standards, so if your database app supports either, then it can connect natively to Redshift.

Now let's go through some key architectural points before we look visually at how Redshift fits together. First, Redshift is a provisioned product. It uses servers, so it's not a serverless product like say Athena. It's also not something that you would really use on an ad hoc basis like Athena. It's much quicker to provision than an on-premise data warehouse that you have to create yourself, but it does come with a provisioning time. It's not something that should be used for ad hoc queries of large-scale datasets on S3. That’s much more aligned to the functionality which Athena provides. So for ad hoc queries, look towards Athena as a default rather than Redshift.

Now Redshift uses a cluster architecture and a really important architectural principle to understand is that the cluster is actually a private network. You can't access most of the cluster directly. Redshift runs with multiple nodes and high-speed networking between those nodes. Because of this, logically it runs in one availability zone, so it's not highly available by design—it's tied to a specific availability zone. All Redshift clusters have a leader node and it's the leader node that you interact with. The leader node manages communications with client programs and all communications with the compute nodes. It develops execution plans to carry out complex queries.

Specifically about the compute nodes—these run the queries which were assigned by the leader node and they store the data loaded into the system. A compute node is partitioned into slices. Each slice is allocated a portion of the node's memory and disk space where it processes a portion of the workload assigned to that node. The leader node manages distributing data to the slices and apportions the workload for any queries or other operations onto the slices. The slices then work in parallel to complete the operation. A node might have two, four, sixteen, or thirty-two slices—it depends on the resource capacity of that node.

Redshift is a VPC service and so all parts of the system can be managed as you would expect. This includes VPC security controls, IAM for permissions, KMS for at-rest encryption of the data, and CloudWatch can also be used for monitoring of the platform. Now because of the way Redshift is architected, it has a feature called Enhanced VPC Routing. By default, Redshift uses public routes for traffic when communicating with external services or any AWS services such as S3 when it's loading in data. If you enable Enhanced VPC Routing, then traffic is routed based on your VPC network and configuration. This means it can be controlled by security groups, network access control lists, it can use custom DNS, and it will require the use of any VPC gateways that any other type of traffic requires—so internet gateways, NAT gateways, or any other VPC endpoints to reach AWS and external services.

If you want advanced networking control, then you need to enable Enhanced VPC Routing. Now that's a good one to remember for the exam. If you do have any customized networking requirements, then you do need to enable Enhanced VPC Routing. I just wanted to stress that again because it really is a critical point to remember for the exam.

Now let's look at the architecture of Redshift visually before we finish with this lesson. We start with a VPC and in there is a subnet in one availability zone. Let’s say inside that we create a Redshift cluster. In the cluster there's always a leader node and it's to this leader node that anything outside of the cluster connects in order to interact with the cluster. Things like management applications or workbenches or visualization—all of this interacts with the Redshift cluster via the leader node using ODBC or JDBC style connections. Inside the cluster are the compute nodes and the slices on those nodes, as well as the storage attached to each of the slices in the compute nodes.

Because Redshift is located in one availability zone, there are a few ways that Redshift attempts to secure your data. First, data is replicated to one additional node when written. That way the system can cope with localized hardware failure. Additionally, automatic backups happen to S3 by default around every 8 hours or every 5 GB of data written to the cluster. This happens automatically and has a configurable retention period. These backups occur to S3 and so you now have data stored across availability zones at this point. So the data with the Redshift cluster is at least resilient against the failure of an availability zone. Additionally, you can create manual snapshots also stored on S3, but you have to manage the retention yourself as an administrator. You can also configure snapshots to be automatically copied across AWS regions, which provides you with global resilience and an effective way to spin up a Redshift cluster in another region if you have a DR event.

In terms of getting data into Redshift, you have a few options. You could load that data from S3 or you could copy data in from products such as DynamoDB. You can migrate data into Redshift using the database migration service from other data sources and even AWS products such as Kinesis Firehose can stream data into Redshift.

Now for the exam, the really important bits to understand are which products can be integrated, how Redshift fits into architectures, what it can be used for, and how to design a Redshift implementation. I've covered most of the important architectural points that you'll need for the exam within this lesson. In the next lesson, I want to talk in a little bit more detail about Redshift backups. It won't be a long lesson, but I think it will be worthwhile doing because it will have benefits for the exam. That’s everything I wanted to cover in this lesson. Go ahead and complete the lesson and then when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson I want to cover the ElastiCache product. This is one which features relatively often in all of the associate AWS exams and fairly often at a professional level. It’s a product that you’ll need to understand if you’re delivering high performance applications. It’s one of a small number of products which allows your applications to scale to truly high-end levels of performance. So let’s jump in and take a look.

So what is ElastiCache? Well, at a high level it’s an in-memory database for applications which have high-end performance requirements. If you think about RDS, that’s a managed product which delivers database servers as a service. Databases generally store data persistently on disk. Because of this, they have a certain level of performance. No matter how fast the disk is, it’s always going to be subject to performance limits. An in-memory cache holds data in memory, which is orders of magnitude faster, both in terms of throughput and latency. But it’s not persistent and so it’s used for temporary data. ElastiCache provides two different engines, Redis and Memcache D, and both of them are delivered as a service.

Now, in terms of what you’d use the product for—well, if you need to cache data for workloads which are read heavy (read heavy being the key term that you need to remember at this point), or if you have low latency requirements, then using ElastiCache is a viable option. For read-heavy workloads, ElastiCache can reduce the workloads on a database. And this is important because databases aren’t the best at scaling, especially relational databases. Databases are also expensive relative to the data that they store and the performance that they deliver. So for heavy reads, offloading these to a cache can really help reduce costs—so it’s cost-effective. Remember that for the exam.

ElastiCache can also be used as a place to store session data for users of your application, which can help to make your application servers stateless. This is used in most highly available and elastic environments—those that use load balancers and auto scaling groups. But for any systems which need to be fault tolerant, where users can’t notice if components fail, then generally everything needs to be stateless, and so ElastiCache can help with this type of architecture.

Now, one really important thing to understand for the exam is that using ElastiCache means that you need to make application changes. It’s not something that you can just use. Your application needs to understand a caching architecture. It needs to know to use a cache to check for data, and if data isn’t in the cache, then it needs to check the underlying database. Applications need to be able to write data and understand cache invalidation. This functionality doesn’t come for free, and so if you’re answering any exam questions which state no application changes, then ElastiCache probably won’t be a suitable solution.

So let’s have a look visually at how some of these architectures work. Architecturally, let’s say that you have an application—obviously the Categorum application—and this application is being accessed by a customer, in this case, Bob. The application uses Aurora as its back-end database engine and it’s been adjusted to use ElastiCache. The first time that Bob queries the application, the Categorum application will check the cache for any data. It won’t be there though, because it’s the first time it’s been accessed, and so this will be a cache miss. That means the application will need to go to the database for the data, which is slower and more expensive. When it’s accessed this data for the first time, the application will write the data it just queried the database for into the cache. If Bob queries the same data again, then it will be retrieved directly from ElastiCache and no database reads are required. This is known as a cache hit. It will be faster and cheaper because the database won’t be used for the query.

Now with this small-scale interaction, it’s hard to see the immediate architectural benefit of using ElastiCache. But what if there are more users? What if instead of one Bob, we have many Bobs? Assuming the patterns of data access are the same or similar, then we’ll have a lot more cache hits and a much smaller increase in the number of database reads. This will allow us to scale our application and accept more customers. If the application data access patterns of our user base is similar at scale, then it will mean that most of the increased load placed on the application will go directly onto ElastiCache. We won’t have a proportional increase in the number of direct accesses against our database. This will allow us to scale the architecture in a much more cost-effective way than if everything used direct database access. We can deliver much higher levels of read workload and offer performance improvements at scale. This is a caching architecture and a very typical architecture that ElastiCache will be used for.

Let’s take a look at another use case, and this is using the product to help us with session state data for our users. Let’s say again that we’re looking at our Categorum application, but now it’s running within an auto scaling group with three EC2 instances and a load balancer. It’s using Aurora for the persistent data layer. Again, we have a user of our application—Bob. The application I’m demoing in this part of the lesson is actually the fault tolerant extreme edition of Categorum. Even when components of the system fail, the application can continue operating without disrupting our user Bob. The way it does this is by using ElastiCache to store session data. This means that when Bob first connects to any of the application instances, his session data is written by that instance into ElastiCache. It’s kept updated if Bob purchases any limited edition cat prints. So the first time Bob connects to any of the instances, that instance writes and maintains the session data for Bob using ElastiCache.

If at any point the application needs to deal with the failure of an instance—where previously the session data would be lost and the application functionality disrupted—the Categorum extreme edition can tolerate this. If this occurs, Bob’s connection is moved to another instance by the load balancer, and his experience continues uninterrupted because the session data is loaded by the new instance from ElastiCache. This is another common use case for ElastiCache: storing user session data externally to application instances, allowing the application to be built in a stateless way. This in turn allows it to go beyond simple high availability and move towards being a fault tolerant application.

ElastiCache commonly helps with either read-heavy performance improvements, cost reductions, or session state storage for users. What’s also important for the exam is that ElastiCache actually provides access to two different engines: Redis and Memcache D. It’s important that you understand the differences between these two engines at a high level. So let’s look at that next.

The differences between Memcache D and Redis start with the fact that both engines offer sub-millisecond access to data. They both support a range of programming languages, so no matter what your application uses, you can use either engine. But they diverge when it comes to the data structures each supports. Memcache D supports simple data structures only, such as strings. Redis, on the other hand, supports much more advanced types of data, including lists, sets, sorted sets, hashes, bit arrays, and many more. For example, an application could use Redis to store data related to a game leaderboard and keep a list sorted by rank. Redis can store both the data and the order of the data, significantly improving application performance.

Another difference is that Redis supports replication of data across multiple availability zones, making it highly available by design. This can also be used to scale reads using those replicas. Memcache D doesn’t support replication in the same way. While you can create multiple nodes and manually shard your data—such as storing certain usernames in one node and others in another—Redis supports true replication across instances for scalability. So in the exam, if you see questions about multi-availability zones or high availability and resilience, Redis should be your likely answer.

Additionally, Redis supports backup and restores, meaning that a cache can be restored to a previous state after a failure. Memcache D does not support that; it lacks persistence. So if the exam question asks about recovery of a cache without data loss, Redis is your best choice. Memcache D does have an advantage in that it’s multi-threaded by design and can better utilize multi-core CPUs, offering significantly more performance on that front. A notable Redis-only feature is transactions—this is where multiple operations are treated as a single unit, meaning either all succeed or none do. This is useful when strict consistency is required.

Both of these engine types can use a range of instance types and sizes. I’ve included a link in the lesson description that provides an overview of the different resources that can be allocated to both caching engines. You don’t need to know the specifics for the exam, but architecturally, be aware that instance types with more or faster memory will offer an advantage when running ElastiCache.

For the exam, focus on recognizing the types of architectures that benefit from an in-memory cache. These include systems with read-heavy workloads, needs for cost reduction when accessing databases, sub-millisecond access requirements, or systems that require external session state storage. Just remember—it doesn’t come for free. You need to make application changes. This is not a plug-and-play solution for apps that can’t be modified. With that being said, that’s everything I wanted to cover from a theory perspective in this lesson. Go ahead, complete the lesson, and when you’re ready, I’ll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about Amazon Athena. This product is one of those hidden gems available within AWS which are really valuable as long as you understand the features that it provides. So let's quickly jump in and explore the architecture.

So what is Athena? Well, it's a serverless interactive querying service. Put simply, it means that you can take data stored within S3 and perform ad hoc queries on that data, paying for only the amount of data consumed while running the query and the storage used within S3 to store the original data. It has no base monthly cost, no per minute or per hour charges, you just pay for the data consumed.

Now what's really special about Athena is how it handles the structured, semi-structured and even unstructured data that it uses. Athena uses a process called schema on read. And the way that I want you to imagine this is like a window or a lens through which you see the data in a certain way but where the original data is unchanged. Your original data stored on S3 is never changed. It remains on S3 in its original form. The schema which you define in advance modifies data in flight as it's read through the schema. So it translates the original unmodified source data into a table-like structure as it's read through the schema. As you query the data, the original data is read, left unmodified and the translation only happens within the product during the querying process. I can't stress this enough, the original data is maintained in its unmodified state within S3.

Normally with databases you create tables and you have to load data into those tables. The data needs to be in the format of the tables or you need to perform ETL processors which stands for extract, transform and load. With Athena this isn't required. You define how you want the data to look in the form of a schema and in a non-modifying way data is loaded through this on the fly. And then any output can be sent to other AWS services.

Now let's look at this visually because it's going to be easier to understand if you see the architecture. So Athena starts with the source data which is stored on S3 and conceptually this is read only. It's never modified. Now the product supports a wide range of data formats and this is growing all of the time. Some examples include XML, JSON, comma and tab separated values, Avro, Parquet, Ork and even custom application log formats such as Apache and AWS services such as CloudTrail, VPC Flow Logs and more. So this data on S3 is fixed. It doesn't get changed and that's probably one of the services most fundamental concepts that you need to understand. And it's why I've repeated it probably 10 times already in this lesson.

So inside the product you create a schema and in this schema you're essentially defining tables. These tables define how to get from the format of the original source data to a table like structure. So unlike a traditional database where a table is the final structure, in Athena you're defining a way to take the original data and present it in a way that you want which allows you to run queries against these tables. It's almost like a recipe. You're defining how to convert from ingredients to a final meal. It's a method to get from the source data to the structure that you want to be able to query.

So these tables within Athena don't actually contain data like a traditional database product. They contain information, directives on how to convert the source data to be able to query on it. So this schema is used at the time of querying when data is read and this is why it's called schema on read. The data is conceptually streamed through the schema while being queried so it can be queried in a relational style way using normal SQL like queries. And the output can be displayed on the console, saved or output to other AWS tools.

And all the time for this whole process there's no base or constant cost. You just pay for the amount of data consumed by the query and you can even optimize the original data set to reduce the amount of data that has to be used for individual queries. The key thing to understand about Athena going into the exam is that it has no infrastructure. You don't need to think about setting up any database infrastructure in advance. You don't need to think about data manipulation in advance and you don't need to load data in advance. Keep those things in mind when going into the exam. They will help inform you when Athena is the right choice and when it's not.

So Athena is great in situations where loading or transforming of data isn't desired. Where you have data already on S3 in a source or raw format and you need to query it without doing any loading or transformation. In the demo lesson which is coming up next you'll see an example of using a large data set, the open street map data. If you needed to load and transform that prior to use it would massively reduce its utility. A benefit of Athena is how you don't need to do any loading or transformation of data in advance. And this makes it ideal for ad hoc or occasional queries of data in S3. Why? Well because you don't need any servers running in advance and you don't need to think in advance about loading or transformation. You have a business need and immediately run a query.

Athena is also useful if you're a cost-conscious business. It's great because it's servilous. You pay for any data read as part of a query. There are no base costs and no upfront costs. Again, think ad hoc, sporadic and cost effective. Athena is also the preferred solution especially in the exam for any queries which involve AWS service logs because it has native support of VPC flow logs, cloud trail logs, elastic load balancer logs, cost reports and much more. And it can also query data from the Glue Data Catalog and supports web server logs. And again, these are keywords to look for in the exam.

A newer feature of Athena is called Athena Federated Query. Now be really careful with this one because I don't want you being confused. For most situations if you see SQL mentioned or no SQL mentioned or any specific database product then the answer to that question is likely not to be Athena. But Athena now has the capability to query non-S3 data sources. Athena uses data source connectors that run on AWS Lambda to perform federated queries. So a data source connector is basically a piece of code that can translate between a target data source which isn't S3 and Athena. So you can think of a connector as almost like an extension to Athena's querying engine.

So you've got pre-built connectors which exist for data sources like cloud watch logs, DynamoDB, DocumentDB, Amazon RDS and even other JDBC compliant relational data sources such as MySQL, Postgres and many more. So Athena Federated Query really is a feature which is going to massively improve the utility of the product. Now that's all of the theory that you need to be aware of for the product as well as some of the key use cases that you might see in the exam. So at this point go ahead, finish this lesson and then when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about DynamoDB TTL which stands for Time to Live. It's a pretty simple concept to understand fully but really powerful and it's one that you'll need to understand for the exam and in the real world. So let's jump in and I'll try to make this one as brief as possible.

Let's say within DynamoDB that we have this table. I'm only showing three items but let's assume that the table has 3 million. It has a partition key in blue on the left and a sort key in green next to that. And in addition to that it has three attributes, yellow in the middle of the table, then red and then pink. Now for that table there are going to be many partitions which support the operations on that table and here I'm just showing two. One partition which stores any items which use the dark blue partition key value and another one which stores currently the two items with a light blue partition key value.

Now the TTL feature lets you define a time stamp which allows items in a table to be automatically deleted at a certain point in time. You're defining when an item is no longer required so per item you specify a date and a time and at that point the item is marked as expired and then deleted.

Now let's step through how this works. First on a table you need to enable TTL and pick an attribute to be used for the TTL processors. The attribute should then contain a number. It's a value in seconds, the seconds since the epoch which is the first of January 1970. So if you want an item to expire in one week's time you need to find out how many seconds since that date one week from now is and then put that into the attribute that you pick for TTL. And you should do that on all items which you want to be affected by the TTL processors.

So when you configure TTL on a table what it actually does is it configures automated processors which run on every partition of that table. The first process periodically scans all items in a partition comparing the value in the TTL attribute with the current date and time in epoch format. In effect it's checking if the item should still be viewed as valid. Where any value in the TTL attribute is less than the current date and time so when the item is no longer valid that item is set to expired. They aren't deleted yet, they can still be queried and viewed in the table, they're just expired.

Next another automated process which runs periodically and which is independent of the initial one this runs also on all of these partitions. This time it's looking for any items which are set as expired and when it finds any items these items are deleted from the partitions meaning they're removed from the table. They're also removed from any indexes and a delete is also added to any streams configured on the table. Now these delete operations are system events they run in the background and don't cause any performance issues nor do they have a charge.

You can also in addition configure a stream on the actual TTL processors and this creates a 24 hour window of any deletions which are caused by those TTL processors. And this is useful if you want to have any housekeeping processors where you track the TTL events which occur on tables. So potentially things like an undelete function or some kind of table auditing. So this is key to understand delete events are placed into a normal table stream along with any creates or modifies but in addition you can create a dedicated stream which is linked to the TTL processors. So you can get a 24 hour rolling window of just those deletes.

So TTL in summary allows you to define a per item time stamp which determines when an item is no longer needed. It's useful if you store items which lose relevance after a specific time. For example removing user or sensor data after one year of inactivity in an application or retaining sensitive data for a certain amount of time. Maybe you have regulatory or contractual obligations which mean you need to retain data for say one year three years or five years. Then you can configure those within a TTL attribute and DynamoDB will automatically remove items once they're no longer relevant.

Now that's everything I wanted to cover in this lesson so go ahead and complete the lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about the DynamoDB accelerator known as DAX and DAX is an in-memory cache for DynamoDB which substantially improves performance but unlike other caches it's directly integrated with the product itself so it's really easy for an architect to implement without lots of additional planning work so let's jump in and take a look.

Now before I focus on DAX specifically I want to spend a few minutes contrasting how an example flow works using DAX versus a traditional in-memory cache so let's assume that we have an application which uses DynamoDB for its persistent data storage so on the top we've got the traditional in-memory cache and on the bottom we've got DAX so the flow using the generic in-memory cache goes something like this first the application needs to access some data and so it checks the cache now if the cache doesn't have the data this is known as a cache miss and if this happens the application then loads the data directly from the database once it has the data which takes longer than getting it from the cache directly it updates the cache with the new data and then any subsequent reads from that point forward will directly load the data from the cache which is called a cache hit and this will be faster.

Now the problem with this architecture is the lack of integration between the cache and the database let's contrast this with DAX and when using DAX there's extra software involved and this is installed on the application instance it's the DAX SDK or software development kit and this takes away the admin overhead from the application because now DAX and DynamoDB are one and the same from the applications perspective the application makes a single call requesting the data and this is handled by DAX if DAX has the data if it's a cache hit and the data is returned directly if not then DAX handles the rest so it goes to DynamoDB to retrieve the data it gets the data adds it back into its cache and then returns that data to the client and the benefit of this method is that it's one set of API calls using one software development kit.

DAX is designed for DynamoDB and so it's tightly integrated with it it's much less admin overhead than using a generic cache so by using DAX and by integrating all of the different API calls into one SDK it makes it really easy to implement caching into your application.

So now that we know the difference between DAX and generic caches let's focus now on exactly how the DynamoDB accelerator is architected. Now DAX operates from within a VPC and it's designed to be deployed into multiple availability zones in that VPC so like many VPC based computers and services you need to deploy it's across availability zones to ensure that it's highly available. Now DAX is a cluster service where nodes are placed into different availability zones there's a primary node which is the read and write node and this replicates out to other nodes which are the replica nodes and these function as read replicas.

So with this architecture we have an EC2 instance running an application and the DAX SDK and this will communicate with the cluster and at the other side the cluster communicates with DynamoDB. Now DAX actually maintains two different caches first is the item cache and this caches individual items which are retrieved via the get item or batch get item operations so these operate on single items and you need to specify an items partition key and if present it's sort key so the item cache just holds items which are directly retrieved in this way. It also has the query cache which stores collection of items retrieved via query or scan operations but crucially it also stores the parameters used in that original query or scan so it links the parameters that are supplied to that operation with the data that's been returned so it means that whole query or scan operations can be rerun and return the same cached data.

Now DAX is accessed architecturally much like RDS every DAX cluster has an endpoint which is used to load balance across the cluster. If data is retrieved from DAX directly then it's called a cache hit and the results can be returned in microseconds. You might get a response back typically in say 400 microseconds. Any cache misses so when DAX has to consult DynamoDB these are generally returned in single digit milliseconds.

Now in writing data to DynamoDB DAX can use write through caching so the data is written into DAX at the same time as being written into the database. If a cache miss occurs while reading the data is also written to the primary node of the cluster as the data is retrieved and then it's replicated from the primary node to the replica nodes.

So DAX is a really efficient way of interacting with DynamoDB because architecturally it actually abstracts away from DynamoDB you think you're interacting with a single product using a single set of APIs but behind the scenes DAX is handling the process improvement that comes from caching and that's both for read and write operations.

Now before we finish up I just want to step through some important facts and considerations that you'll need for the exam. So DAX is a cluster you've got the primary node which supports write operations and replicas which support read operations. Nodes are designed to implement high availability so if you implement multiple nodes and one of the nodes fails for example the primary node it will have an election and fail over to one of the replicas which will become the new primary node.

Now DAX is an in-memory cache and so it allows for much faster read operations and significantly reduced costs. If you're performing the same set of read operations on the same set of data over and over again then you can achieve substantial performance improvements by implementing DAX and caching those results and in addition because you're not having to constantly go back to DynamoDB time after time for the same data then you generally do achieve significant cost reductions.

In terms of scaling with DAX you can either scale up or scale out so this means using bigger DAX instances or adding additional instances. So you can scale in both directions up and out. Now unlike a lot of caches DAX does support write through which means that if you do write some data to DynamoDB you can write it using the DAX SDK. DAX will handle that data being committed to DynamoDB and also storing that data inside the cache.

Architecturally you do need to know that while DynamoDB is a public AWS service DAX is not it's deployed inside a VPC and so logically any application which is using DAX will also need to be deployed into that VPC.

So DAX is an in-memory cache and it's designed to reduce the response time of read operations by an order of magnitude taking you down from single digit milliseconds using DynamoDB natively all the way through to microseconds if you use DAX. So architecturally if you're reading the same data over and over again then you need to look at whether you should be using an in-memory cache.

Now choosing between DAX and a generic in-memory cache this comes down to how much admin overhead you want to manage because DAX is integrated with DynamoDB because it supports this single SDK for accessing the cache and DynamoDB both together as an abstract entity it's a lot less workload if you are using DynamoDB on its own to implement DAX rather than a generic cache.

So if you've got read heavy or bursty workloads then DAX provides increased throughput and potentially significant cost reductions. So if you find yourself having to apply large RCU values onto a table these can get expensive really quickly and you might be better implementing DAX which will get you better performance and remove that additional cost. So if you find yourself having performance issues during sale periods or have specific tables or items in a table where there are heavy read workloads against that area of data then you can consider using DAX. If you've got a workload which is very read heavy with the same set of data again and again being read then you can consider using DAX. If you've got a type of data layout where a certain type is used more frequently than everything else maybe time series then again you can consider using DAX. If you really care about incredibly low response times again that's another situation where DAX could be advantageous.

Now situations where DAX is not ideal or any applications that require strongly consistent reads. If your application cannot tolerate eventual consistency then DAX is not going to be suitable. If you don't have an application that is latency sensitive if you don't need these really low response times again DAX might not be the right solution. If your application is right heavy and very infrequently uses read operations then again DAX is probably not the right solution.

So generally if you see any questions in the exam which talk about a caching requirement with DynamoDB then you should by default assume it is DAX and only move away from that assumption if you see significant evidence to suggest something else.

With that being said that is everything I wanted to cover inside this lesson so go ahead complete this video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about DynamoDB global tables, something which will form part of your toolkit as a solutions architect for any global database deployments. Now this lesson will be entirely based around architectural theory so let's jump in and get started.

Global tables aren't actually that complex, they provide multi-master replication meaning no single table is viewed as the master and others replicas instead all tables are the same. It's global and allows for read and write replication between all tables that are part of a global table. To implement global tables you create tables in multiple AWS regions and then on one of the tables it doesn't matter which you configure the links between all of the tables. This creates a global table and sets DynamoDB to configure replication between all of the table replicas. So tables become table replicas of a global table. So think of a global table as an entity by itself and supporting that global table are individual DynamoDB tables in different AWS regions configured for multi-master replication.

Now between the tables DynamoDB utilizes last right-of-wins for conflict resolution because it's simple and generally it generates entirely predictable outcomes. So in the event that you've got the same piece of data being written to two different tables at around the same time then DynamoDB will pick the most recent right and it will replicate that to all of the other replica tables that are part of the global table. So whichever is the most recent will overwrite everything else.

Now because it's multi-master it means that you can read and write to any region and the updates are replicated to all other regions generally within a second. Now it's really fast and that matters because it means that it can be used for more demanding applications. In terms of consistency you can perform strongly consistent reads in the same region as data is written to but for anything else it's always eventual consistency. The replication between tables is asynchronous and so if you have a global application it needs to be able to tolerate eventual consistency. If you have a global table and one of the replica tables is in the US and one of them is in London if you're writing to one and reading from the other it will always be eventual consistency and so your application needs to take that into account. If it can't cope with eventual consistency then global tables are going to be problematic.

Now to use global tables you first need to select the AWS regions which will be part of that global table. For example we could use one of the US regions AP Southeast 2 in Australia and the London region. Then in each of those regions you'd create a Dynamo DB table. You would select one of the tables it doesn't matter which but let's use the US in this example and from that table we would add all of the tables into the global table configuration and this would establish the multi master replication between all three tables. So all three tables can support reads and writes.

Now specifically for the exam you don't really need to be aware of the implementation details. For the exam the architecture is what matters so be aware that replication is generally sub second. This depends somewhat on the load on each of the different regions but generally it does occur within a second. Now globally as I mentioned moments ago it's eventually consistent but you can do eventual or strongly consistent reads as long as it's in the same region. The replication is multi master which means that all regions can be used for both read and write operations and finally in terms of what this architecture supports well if you want to implement a globally highly available application or you want to improve the global data performance of an application or you want to add global disaster recovery or business continuity capability to your application then global tables can support all of those requirements.

It's a feature which is really simple to use but it's highly effective and as long as you're aware that the conflict resolution is last right or wins and your application is able to tolerate that then you can use the feature to support a global data layer for your application it's a really good feature to implement as long as your application can tolerate all of the requirements.

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

Welcome back and in this lesson I'm going to be talking about DynamoDB, Streams and Triggers. Both of these are really powerful features which let you implement some powerful and cost-effective architectures using DynamoDB within AWS. Now we've got a fair bit to cover so let's jump in and get started.

A DynamoDB Stream is a time-ordered list of changes to items inside a DynamoDB table. So every time a change occurs to an item in a table, a change is recorded chronologically within a DynamoDB stream. And a stream is actually a 24-hour rolling window of these changes. Behind the scenes it actually uses Kinesis Streams which you've covered earlier in the course.

Now you need to enable streams on a per-table basis and when you do enable streams on a table, any inserts of items, updates on items or item deletions are recorded within the stream. Now you can configure the stream with different views and this is an option on a per-stream basis and the view setting influences exactly what information is added to the stream every time an item change occurs.

Now let's look at this visually because it's much easier to understand. Let's say that we have a table within DynamoDB and this table has one item, the top item. And let's say that that item is updated, changed to be the bottom item. So this represents one item which has changed and the way that it's changed is by having its fourth attribute removed, the one in dark orange. Now if we've enabled streams on this table then any inserts, updates or deletes are recorded including the one update that I've just discussed.

There are four view types that a stream can be configured with. It can be configured with keys only, new image, old image and new and old images. So that's four different options for different view types that a stream can be configured with.

Now given this change to the table on the top left so the removal of its fourth attribute, the one in dark orange, these different view types have the following differences. So with keys only as the name suggests, the stream will only record the partition key and optionally any applicable sort key value for the item which has changed. It would be up to whatever is interrogating the stream to determine exactly what has changed and that would probably require a database read. So in this example where we've removed the fourth attribute, the one in dark orange, the only information that we get using keys only is that the partition key is blue and the sort key is green. We don't see exactly how this item has been manipulated.

The second view type is new image and this actually stores the entire item with the state as it was after the change. So if you wanted to configure some sort of business process which operated on the new updated data, then you would configure this view type. So this view type shows the state of the item after the change. So after the removal of the fourth dark orange attribute. If you wanted to know exactly what had changed, then you couldn't determine that using this view type.

Now if you wanted to know what changed, then one option would be to use the old image type. That way you have a copy of the data as it was before the change and you could check the state of the database, specifically the item in this table, to see exactly what updates had occurred on that data. So by comparing the old image item inside the stream to the item in the database table, you could calculate exactly what had changed.

Another option to be able to determine exactly what has changed is the final view type which is new and old images. So if you have a business process which needs complete visibility of the change, so before and after and have this visibility independent of the actual table, then you can select new and old images. And with this view type, the actual entry in the stream stores both the pre change and the post change state of that item. And that way you can determine the difference without having to consult the database table itself.

Now it's worth noting that all of these types of views work as well with inserted or deleted items. But in some cases, the pre or post change state might be empty. So if you delete an item and you're using the new and old images, then obviously your new state will be completely blank. And if you're inserting an item and use that same view type, then your old state will be blank and your new state will contain the data that you've inserted.

Now streams are powerful in isolation, but where the real power comes from is that streams are actually the foundation for an architecture called database triggers. So these allow for actions to take place in the event of a change in data. So this is an event driven architecture that can respond to any data changes in a table. Now databases like Oracle have supported these for years, but with DynamoDB, they can be implemented in a serverless way.

Now the architectures of triggers simply put is that an item change inside a database table generates an event. That event contains the data that's changed and the exact data depends on the view type. When an item is added to a stream, so when an event is generated, then an action is taken using that data. And the way that this action is implemented within AWS is to combine the capabilities of streams and Lambda.

So you can use streams and Lambda so that a Lambda function is invoked whenever changes occur to a DynamoDB table. And so you'll use Lambda to perform some type of compute operation in response to a data change that causes a stream event. And the Lambda function invocation is actually in this architecture, the trigger. So it's the compute action that occurs based on data change.

So streams and triggers are actually a really powerful architecture. You might see them used in reporting or analytics scenarios. If you want to generate a report in the event of a change of a certain item in a database, maybe stock level changes, or if you want to report on popular items in a stock database, then potentially you can use streams and triggers. They're also really useful for things like data aggregation. So if stock levels are being manipulated or if a voting app is recording votes and you want to perform some kind of aggregation or tally of all those votes, then potentially you can use streams and triggers.

You can also use it for messaging or notifications. For example, if you have a messaging application which allows you to create a group chat, you might use a DynamoDB table to store the chat items that are added to that group. And you could use streams and triggers to send push notifications to all members of that group chat. So rather than having to poll databases which consumes compute resources even if nothing happens, if you're using streams and triggers, you can respond to an event as it happens and only consume the minimum amount of compute required to perform that action.

Streams and triggers are really used for lots of different things inside architectures, but for the associate level solutions architect exam, you just need to know that you use streams and lambda together to implement a trigger architecture for DynamoDB.

So visually this is how triggers are implemented. We've got a table, an item change occurs within a table which has streams enabled. So a stream event is placed onto a DynamoDB stream. We've selected to use the new and old images type. So we've got both the new and the old state of that item. And based on that, that gets sent as an event to a lambda function and that lambda function can perform some compute based on the pre and post change states of that item.

So it's not a hugely complicated architecture, but it is really powerful. So enable streams on a table, configure a lambda function to invoke whenever a change occurs and you've got a really cost effective and powerful serverless implementation of a trigger architecture. And that's what you'll need to understand for the exam.

Now with that being said, that's everything that I wanted to cover in this lesson. go ahead and complete the video and then when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about DynamoDB indexes and there are two types, local secondary indexes known as LSIs and global secondary indexes known as GSIs. Now we've got a lot to cover so let's jump in and get started.

Indexes are a way to improve the efficiency of data retrieval operations within DynamoDB. We've already talked about how query is the most efficient operation within DynamoDB but it suffers from one crucial limitation that it can only work on one partition key value at a time and optionally a single or a range of sort key values. Indexes are a way that you can provide an alternative view on data that's inside a base table. By providing an alternative view you can allow the query operation to work in ways that it couldn't otherwise and there are two types of indexes, local secondary indexes and global secondary indexes. Now local secondary indexes allow you to create a view using a different sort key and global secondary indexes allow a view with a different partition and sort key. And for both of those indexes when you're creating them you have the ability to choose which attributes from the base table are projected into them and choosing what to project is important because it can massively impact how efficient the indexes are for your queries.

Now first I want to focus on local secondary indexes. So again it's an alternative view on base table data and local secondary indexes must be created with the base table itself. So this is critical to know for the exam. You cannot add local secondary indexes after the base table has been created. And so while you're creating the base table you can optionally create a number of local secondary indexes and the current maximum is five local secondary indexes per base table. So just to repeat this again because I want this committed to your memory, local secondary indexes allow for an alternative sort key on the data in the main table. So it's an alternative sort key but the same partition key and local secondary indexes share the capacity with the main table. And so they use the same RCU and WCU values if the main table is using provisioned capacity. Now in terms of the attributes that are projected into a local secondary index the options that you have are to use all of the attributes for the base table. You can choose keys only or you can use include which lets you specifically pick which attributes from the base table are projected into the index.

Now let's take a look at an example visually so that you can understand how this all fits together from an architecture perspective. And the example that I want to use is a weather station. So this table holds data for a number of weather stations and for each weather station there's one record taken each day at the same time. Now if we want to stick to using the query operation then we're limited to querying a single weather station and for a single weather station to either a single day or a range of days. But what if we want to interrogate data based on another attribute say for example the sunny day attribute. So this attribute records whenever the average over a day is classified as a sunny day. Now because this attribute isn't a key in order to perform any operations on it we couldn't use query because query needs to use a single partition key value and optionally select using the sort key we would need to use the scan operation. And we know now from an earlier lesson that the scan operation is incredibly inefficient.

An option that we have to fix this problem is while creating this table we can also create an additional local secondary index using the sunny day attribute as the sort key. So this needs to be created along with the base table so at the same time as you're creating the base table. But if we choose to do that then for a given weather station we're able to easily limit the data that we retrieve to sunny days because we can use the query operation on a single station ID which is still the partition key but then use the query operation to limit specific values in the sort key in this example picking only sunny days. Now what's even better is that indexes are known as sparse indexes and this means that only items from the base table which have a value for the attribute that we define as the new sort key are present in the index. Now this means that if the sunny day attribute is something which is present if it's a sunny day and absent if it's not then the only items in the sunny day local secondary index will be for data which is a sunny day. So we can in some cases take advantage of the fact that indexes are sparse and we can use a scan operation against this local secondary index knowing that we'll only consume the capacity for data that is relevant towards. So we could use a scan operation on this local secondary index knowing that any items in this index are by default for sunny days and so we're only going to be consuming capacity that's relevant for sunny day data.

Now this is a lot more complex than you'll need for the solutions architect associate exam. For the exam all you need to know is that local secondary indexes allow you to create an alternative view on the data that's in a base table by providing an alternative sort key. They use the same partition key and they can only be created along with the base table.

So now let's look at a different type of index a global secondary index. Global secondary indexes are different than local indexes they can be created at any time and so they're much more flexible. There's also a default limit of 20 global secondary indexes per base table so you can have more than them and they let you define a different partition and sort key and they also have their own RCU and WCU capacity values if you're using provisioned capacity for the base table. And just like with local secondary indexes you have the flexibility to choose exactly what attributes are projected into the index from the base table and you have the same options either choosing all attributes keys only or including specific attributes.

So let's look at another example visually to make it easier to understand. So we're using another example of the weather station this time we have the pink attribute which represents any items where there's been an alarm at the same point as taking the data. So an alarm could be something like a system error it could be a bird or other wildlife which has entered the weather station and interfered with the results or anything else that's out of the ordinary. Now if there's a regular access pattern where you need to query this table for any items which have been impacted by the alarm then you couldn't do this normally using a query you'd need to use a scan operation and filter it based on the alarm attribute and this would mean that you're consuming all the capacity for every single item that is read using the scan operation.

Now an option that we have is to create a global secondary index and this allows us to create an alternative view with a different partition key and sort key. In this example we've created a global secondary index which uses the alarm attribute as the partition key and the station ID as the sort key and this means that we can use the efficient query operation for any items showing an alarm and optionally specify one station ID or a range of station IDs to limit the data that we receive for alarms for specific weather stations. So global secondary indexes are super powerful because of this ability to define completely separate partition and sort keys so it truly gives you a way to create an alternative perspective on the data that's in a base table and global secondary indexes are also sparse which means in this example any items which have no alarm attribute would not be included in the index.

For the exam you need to be comfortable with the fact that GSIs allow you to create this different perspective on data with alternative partition and sort keys and for GSIs you can create them after you've created the base table so they don't have that limitation of needing to be created at the same time as the base table which is the case for local secondary indexes. Now one final thing to keep in mind global secondary indexes are always eventually consistent because the data is replicated from the base table to the index asynchronously and so your application needs to be able to handle eventual consistency. If you're using a global secondary index you need to be able to cope with eventual consistency because that's the only option that you have.

Now before we finish up the lesson I just want to talk through some local and global secondary index considerations things that you should be aware of for the exam. So you need to be very careful with what attributes you choose to project into the index. As you now know when you're working with DynamoDB at any time you're reading or writing data you're actually consuming all the capacity for the size of the entire item and so if you project all of the attributes into an index you're also using all the capacity of those attributes so you need to be aware of the capacity that you're using when you project attributes. Now the inverse of this is if you don't project a specific attribute and then you require that attribute when you're querying an index that will still work but it's doing something in the back end a fetch of that data which is actually incredibly inefficient. So you need to plan your indexes in advance and make sure that you project the correct attributes because if you are performing queries on any attributes which are not projected then it gets really expensive.

Now AWS recommend using GSIs as default and only using local secondary indexes when strong consistency is required. So if you need an index and you're in doubt you should use global secondary indexes because they're a lot more flexible and they can be created after the point of when you've created the base table. Now from an architectural perspective and something to keep in mind if you do see any exam questions which mention indexes is that indexes are designed when you have data in a base table and remember you're designing the base table with the partition and sort keys for the primary way that you will access this data. Indexes allow you to create this alternative perspective for any alternative access patterns and so if you have a requirement maybe a different team is looking at the weather station data only looking for alarms maybe it's a security team or a data science team then you can create indexes that allow for these alternative access patterns. Indexes allow you to keep the data in one place but create these perspectives for different types of queries, different teams or different requirements they can all access the same data just using this different perspective.

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

Welcome back. This is part two of this lesson. We're going to continue immediately from the end of part one. So let's get started.

Now DynamoDB can operate using two different consistency modes for read operations. It can be eventually consistent or it can be strongly or also known as immediately consistent. Consistency refers to the process of how when data is updated, so when new data is written to the database and then immediately read, is that read data immediately the same as the recent update, or is it only eventually the same? Eventual consistency is easier to implement from an underlying infrastructure perspective and it scales better. Strong consistency is essential in some types of applications or some types of operations, but it's more costly to achieve and it scales less well than eventual consistency.

So let's look visually at exactly how this works. With DynamoDB, every piece of data is replicated multiple times in separate availability zones, and each one of these points is called a storage node. Out of these three storage nodes in three different availability zones, one of them is elected as the leader, so the leader storage node. This is a dynamic process. So if the leader ever fails, the election will happen again and a new one will be chosen. So in this case, we've got a single item inside a DynamoDB table that's been replicated across three different storage nodes, one in availability zone A, one in availability zone B, and one in availability zone C. All three have the same data, the same item with the same five attributes.

Now let's say in this example that Bob decides to update some data, it's this particular DynamoDB item, and he decides to remove the fourth attribute, the dark orange attribute. So this is the change to the item, the fourth attribute is removed, and when writing this to DynamoDB, the product has a fleet of entities which route connections to the appropriate storage nodes. Writes are always directed at the leader node, so it's this leader node which will receive the update to this item first. So on the leader node, the item will be manipulated and the fourth attribute, the one in dark orange, will be removed. At this point, the leader node is known as consistent. It has the data on it which you just wrote. That's why writes are more expensive in terms of capacity units. Why a write capacity unit is less data than a read capacity unit, because writes always occur on the leader storage node. And so these can't scale as well as reads.

When the leader node has the new data on it, it immediately starts the process of replication. This process usually only takes milliseconds, but it does depend on the individual load which has been placed on these storage nodes, and it assumes the lack of any faults. But let's assume though, for this example, that we have no faults on our storage nodes, and we've replicated this updated item to one additional storage node apart from the leader, so the one in availability zone C. And right now we freeze time. So the situation we have is that the leader storage node contains that updated item, as well as the storage node in availability zone C, but the storage node in availability zone A does not have the updated item. It is not consistent.

So right now with time frozen, let's look at reads. And there are two types of reads which are possible with DynamoDB, eventually consistent reads, and strongly consistent reads. Now I mentioned earlier in this lesson how you can actually perform reads cheaper than having one RCU representing four kilobytes of data. Now the reason for this is that one RCU is actually four kilobytes of data read from DynamoDB every second, but that's using strongly consistent reads. Eventually consistent reads are actually half the price. So you can read double the amount of data for the same number of RCUs.

So let's say that Julie on the top right performs an eventually consistent read of the data. When Julie performs that operation and uses eventual consistency, then DynamoDB directs her at one of the three storage nodes at random. In most cases, all three storage nodes will have the same data. And so there's little difference between eventual and strongly consistent reads. But in this particular edge case, if DynamoDB sent her request at the top storage node, then she would get stale data. Replication occurs in milliseconds, but with eventual consistency, it isn't always guaranteed that you will get the latest data. And in exchange, because eventually consistent reads scale better because any of the individual nodes can be used, you actually get a price reduction. It's 50% of the price for strongly consistent reads. So you get twice as much reads for each individual read capacity unit. In most cases, you will notice no difference, but you need to be aware that there is a small potential that with eventually consistent reads, you might be reading older versions of data. If you access DynamoDB at exactly the wrong time, it is possible that you might get outdated data.

Now, in contrast to strongly consistent read, always uses the leader node. It's always consistent, but because it mandates the use of one particular storage node, the leader node, it's less scalable, and so it costs the normal amount of RCU to perform. So that's why eventually consistent reads are less cost than strongly consistent. But one very important thing to keep in mind is that not every application or access type can tolerate eventual consistency. You need to pick the correct model. If you have a stock database where the stock level is important, or if you're performing medical examinations and the data that's being logged into DynamoDB is critical and you always need the most recent version, then you need to use strongly consistent reads. If your application can tolerate a potential lag and the small chance of outdated data, then you can achieve significant cost savings by using eventually consistent reads.

Now, let's just talk through some calculations of how you can actually determine appropriate values for capacity on a table. Let's look at a scenario and let's assume that you need to store 10 items in DynamoDB every second. So you have 10 devices that are logging data into DynamoDB and on average, they store data once every second. So you've got 10 writes per second. Now, with any type of scenario, you need to determine a number of really important things. You need to understand the average size of an item that's being written to DynamoDB, and you need to understand how many items per second will be written. Now, in some cases, exam questions might try to trick you and say that 60 items will be written per minute, and if you see that type of question, you need to try and calculate how many per second because that's what read and write capacity units use.

Now, once you've got both of those pieces of information, you can calculate the WCU required per item. So to calculate that, you take your item size, in this example, 2.5K, and you divide it by the size of 1 WCU, which is 1K. That gives us 2.5, and then we need to round that up to the next highest whole number, which in this case is three. So we know that for a 2.5K average item size, we're going to consume 3 WCU. And then we need to understand how many of those occur every second, and so we need to multiply that value by the average number of writes per second. So we know that we're going to store 10 items per second. We now know that the WCU required per item is three, and based on that, we can multiply those together to get the required WCU, which in this example is 30. So it's the same calculation every time. Work out the size of an individual item right in WCU, multiply that by the number of writes per second, and that will give you the WCU setting that you require on the table. Remember, a WCU is 1K in size.

Now flipping that round, let's look at reads. If we have a similar example, and we need to retrieve 10 items per second from our database, and we know that the size of an average item is 2.5K, the first thing we need to do is to calculate the RCU that's required per item. And we do that by taking the average item size and dividing that by 4KB, and then rounding that up to the next highest whole number. So in this case, because an RCU allows for four kilobytes of reads, we know that 2.5K is going to fit inside 4K. So every single read is going to be one RCU. So we know that it's one RCU per read. So now we know the number of RCU required per item. We need to know the number per second, the number of operations per second, which is 10, and we multiply those together. So to do strongly consistent reads with this example, we would need 10 RCU. But now you know the concept of eventual consistency. That is half the cost. So we can take this RCU value and divide it by two, and that means that to perform eventually consistent reads of 10 items per second with a 2.5K size, we need five RCU set on the table.

So I've provided two really simple examples, and what I'm going to do is include some links in the lesson description, which will give you additional examples with different sizes of items, different writes per second, and it will give you some practice on how to perform these calculations. And I suggest that you do this as extra work once you've finished all of the content of the course. The only thing that I need you to understand for now is the size of an RCU, the size of a WCU, and exactly how the consistency model works for DynamoDB. That's all of the theory that I wanted to cover in this lesson though. Go ahead, complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about DynamoDB operations, DynamoDB consistency and DynamoDB performance. It's a lot to cover in one lesson so I'll try to be as efficient as possible but let's jump in and get started.

Now DynamoDB allows you to pick between two different capacity modes when you create a table and with some restriction you are able to switch between these modes even after data has been added and these modes are on demand and provisioned. On demand is a mode which is designed when you have an unknown or unpredictable level of load on a DynamoDB table or alternatively when you have a massive priority for as little admin overhead as possible. With on demand you don't have to explicitly set capacity settings it's all handled on your behalf by DynamoDB. You just pay a price per million read and write units but the price that you pay can be as much as five times the price versus using provisioned capacity so it's actually a trade-off. You're reducing the admin overhead it allows you to cope with unknown or unpredictable levels of demand but you are paying more for that privilege.

With provisioned capacity you actually set a capacity value for reads and writes on a per-table basis so RCU stands for read capacity units and WCU stands for write capacity units. Now a critical thing to understand is that every operation on a DynamoDB table consumes at least one unit so one unit of read or write. Now I've added an asterisk here because there is a way to get cheaper reads but I'll introduce this later in this lesson. One RCU allows for one read operation of up to four kilobytes on a table every second. If you perform an operation and it only uses one kilobyte to read an item you still consume one RCU. It rounds up to at least one RCU. But one operation can consume more. An item as you learned earlier in the course can be up to 400 kilobytes in size as a maximum and this would consume 100 RCU to read in one operation. Now a capacity unit is per second so one RCU lets you read one block of data up to four kilobytes every second. For writes one write capacity unit is one kilobyte so it's the same logic but one kilobyte instead of four kilobytes. So you set a certain amount of read and write capacity and that gives you a certain amount of read and write load every second.

As well as that every single table within DynamoDB has a WCU and an RCU burst pool. It calls 300 seconds of the read and write capacity units set on the table. So when setting read and write capacity units you're setting for the sustained average. But try to dip into the burst pool as infrequently as possible because other table modification tasks can use this pool as well. Relying on it too much is pretty dangerous. If you ever deplete the pool and have insufficient capacity set on a table then you will receive a provisioned throughput exceeded exception error and you'll be throttled. And the solution is to wait and retry or increase the capacity settings.

Now there are a number of different types of operations that you can perform on a DynamoDB table and some of the most common ones that are mentioned in the exam are query and scan. So I want to just talk about exactly how these work at a high level before we move on. The query operation in DynamoDB is one way that you can retrieve data from the product. When you're performing a query operation you need to start with the partition key. You have to pick one partition key value. Let's look at an example visually because it will be easier to understand.

So this is a simple DynamoDB table. It stores weather data once per day from a group of weather stations. So the partition key is the sensor ID and the sort key is the day of the week. And we have one new table for every week of every year. And to keep things simple these are the sizes of each item. So item one is 2.5k, item two is 1.5k, item three is 1k and item four is 1.5k. Now the query operation can return zero items, one item or multiple items. But you always have to specify a single value for the partition key. So you can only ever with this example query for one specific weather station. So regardless of whether your table uses a simple primary key with just the partition key or whether it uses a composite primary key which uses both the partition key and the sort key with query you always have the option of just querying with a single value for the partition key.

So in this example if we decided to query for all items for weather station ID of one then we would get two items returned. The item for Monday for weather station ID one and the item for Tuesday for weather station ID one. Now the first item has a size of 2.5k and the second item has a size of 1.5k. So both of these together equal 4k and one RCU allows you to query 4k. So this particular query would use one RCU of capacity. Now with DynamoDB it's always more efficient to return multiple items in a single operation. In this example we could actually perform a query where we provide the partition key value of one as well as a specific value for the sort key. So if we wanted to retrieve both of these items with two separate query operations then we could query for a partition key value of one and a sort key of Monday and a partition key value of one and a sort key of Tuesday as two separate operations. But because every operation consumes at least one RCU then if we ran two separate queries then the same amount of data would consume two RCU. So it's always more efficient to pull back as much data as you need in totality in one single operation.

Now if you only want to retrieve one specific item then you can query for one particular value of the partition key and one particular value of the sort key. In this example we could query for a partition key value of one and a sort key value of Monday. And this would return one single item, the Monday item for Weather Station ID 1 which has a size of 2.5k. But because it's a single operation and it's less than 4k it will be rounded up to the next whole RCU value. So this single item query will cost one RCU and it will retrieve the entire item. Generally with any operations on DynamoDB you always have to operate on the entire item so reading and writing an entire item. And so there is an architectural benefit with the platform to minimizing the size of an item as much as possible because if you have to perform queries which operate on single items as a minimum you are going to consume the capacity that that whole item uses.

Now just to restress the important thing about queries is that you have to query for one particular value of the partition key and when you're querying for that one value you can retrieve all of the items with that one value or you can filter that down based on supplying one sort key value or a range of sort key values. And when you do that using the query operation you're only charged for the capacity of that query operation. So if you pick a particular subset of sort key values you're only charged for the response from that query operation. What you can do with the query operation is specify particular attributes that you want to return. So in this example we might only want to return the yellow attribute and the pink attribute but you are still charged for the entire item. Anything that you filter is discarded but you are still charged for it.

Now if you want to perform a search across an entire table maybe looking for every single weather station entry which indicates good weather you can't do that with the query operation because a query operation can only ever query it based on one particular partition key value. If you want to perform more flexible operations you need to use scan. Scan is the least efficient operation within DynamoDB when you want to get data but it's also the most flexible. Let's use the same example the weather stations. The way that scan works is to move through the table item by item. You can specify any attributes that you want to match. You can show all items for example where a temperature is between two values or retrieve all of the items across all of the weather stations for a given day. For example Monday. But what you need to understand about scan is that it is scanning through the entire table. So the entire table is consumed. So while you can use it to get access to any data that you want the consumed capacity is for all of the items that are read. Even if you filter things even if you return less data than the whole table you consume all of the data that's scanned through. So scan is super flexible but it's also really expensive from a capacity perspective.

So let's quickly look at an example visually. Let's say that you want to scan the weather table looking for all items across all different weather stations looking for any entries which indicate a sunny day. So we're looking for a particular attribute which defines that the yellow column and we want to return all items which have this attribute. Now we can't use a query operation for this because query as I mentioned on the previous screen only allows us to query for one particular value of the partition key. And we need to look across all different weather stations so multiple values for that partition key. So we can't use query but we can use scan. So in this example we're trying to scan for the sunny day attribute, the attribute in yellow and we're looking through the entire table. So this attribute isn't a partition key and it isn't a sort key and we can't use query. But we can use scan. So scan will step through the entire table. So all four items. But because we've specified to the scan operation that we only want items which have this sunny day attribute it doesn't return some items. It doesn't return the ones with the non sunny days. But that data is just discarded. We still consume the entire capacity.

So the scan operation would need to step through every item in this table to determine which ones do have the sunny day attribute and which ones don't. So in this example we actually consume all of the item capacity in the table. So that's 5k plus 4k plus 2k plus 3k. So that's a total of 14k which rounded up to the next highest RCU represents 4rcu of capacity that we've consumed. Even though we're only actually returning 5k plus 4k of data the remaining items which are not valid the ones which don't have sunny days are simply discarded.

Okay so this is the end of part one of this lesson. It was getting a little bit on the long side and so I wanted to add a break. It's an opportunity just to take a rest or grab a coffee. Part two will be continuing immediately from the end of part one. So go ahead, complete the video and when you're ready, join me in part two.

Welcome back. Over the next few lessons, I'm going to be stepping through the architecture, features, and important considerations of the Amazon DynamoDB product. DynamoDB is a no-sequel, wide-column database as a service product within AWS. It's the database product which tends to be used for serverless or web-scale traditional applications inside AWS. And for the exam, it's essential that you understand it fully. Now we have a lot to cover, so let's jump in and get started.

So DynamoDB is a no-sequel database as a service product. It's a public service which means it's accessible anywhere with access to the public endpoints of DynamoDB. And this means the public internet or a VPC with either an internet gateway or a gateway VPC endpoint. DynamoDB is capable of handling simple key value data or data with a structure like the document DB model. Now strictly speaking, DynamoDB is a wide-column key value database. And being a database as a service product means that you have no self-managed servers or infrastructure to worry about. It's not like RDS or Aurora or Aurora serverless which a database server as a service product. With DynamoDB, you actually get the database itself delivered as a service. And this reduces the complexity and admin overhead significantly of providing a data store for your applications.

Now DynamoDB also supports a range of scaling options. You can take full control and choose provisioned capacity and then either manually control performance or allow the system to adjust performance automatically. Or you can use on-demand mode which is a true as a service performance model. So essentially set and forget. Now DynamoDB is highly resilient either across multiple availability zones in a region or optionally DynamoDB allows for global resilience. So a table can be configured to be globally resilient but that is an optional extra. Now within DynamoDB data is replicated across multiple storage nodes by default and so you don't need to explicitly handle it like you do with RDS. Now DynamoDB is really really fast. It's backed by SSD and so it provides single digit millisecond access to your data. It also handles backups. It allows for point-in-time recovery and any data is encrypted at rest. It even supports event-driven integration allowing you to generate events and configure actions when data within a DynamoDB table changes.

So now let's talk about tables within DynamoDB. Tables are actually the base entity inside the DynamoDB product. If I'm being precise which by now you know that I like doing DynamoDB shouldn't really be described as a database as a service product it's more like a database table as a service product. A table within DynamoDB is a grouping of items which all share the same primary key. Items within a table are how you manage your data within that table. So think of an item like a row in a traditional database product. A table can have an infinite number of items within it. There are no limits to the number of items within a table.

Now when you create a table within DynamoDB you have to pick its primary key. Now a primary key can be one of two types. It can either be a simple primary key which is just the partition key known as a pk or it can be a composite primary key which is a combination of the partition key and the sort key which is known as the sk. So every item in the table has to use the same primary key and it has to have a unique value for that primary key. If the primary key is a composite key then the combination of the two parts the pk and the sk need to be unique in that table. Now that's actually the only restriction on data that an item has the unique values for the primary key. Items can have other bits of data aside from the primary key called attributes but every item can be different as long as it has the same primary key then it can have no attributes, all attributes, a mixture of attributes or completely different attributes. An item itself can be a maximum of 400 kilobytes in size and this includes the primary key, the attribute values and the attribute names all total together.

With DynamoDB you can configure a table with provisioned capacity or on-demand capacity. Now capacity is a pretty odd term. When you think about capacity you probably think about space but in DynamoDB capacity means speed adding capacity means adding more speed more performance. Now if you choose to use the on-demand capacity model it means you don't have to worry about it you don't have to set explicit values for capacity on a table you just pay for the operations against the DynamoDB table there's a cost per operation. If you choose provisioned capacity then it means you need to explicitly set the capacity values on a per table basis and there are two terms that you need to understand. The first is write capacity units or wcu and the second is read capacity units known as rcu. One wcu set on a table means that you can write one kilobyte of data per second to that table and one rcu or read capacity unit when set on a table means that you can read four kilobytes per second from that table. Most operations have a minimum consumption so one read of say 100 bytes will consume one rcu as a minimum and I'll be talking more about capacity control later I'm just introducing the terms for now.

Now let's move on and I want to talk about backups inside DynamoDB. There are two types of backups available in the product first is on-demand backups and these are similar to how manual rds snapshots function so there are full backup of the table retained until you manually remove that backup. These on-demand backups can be used to restore data and configuration either to the same region or cross region so if you want to migrate data to another region this is one option you can use a backup to restore a table with or without indexes and you also have the ability to adjust encryption settings as part of the restore. The key thing to remember is that you're responsible for performing the backup and removing the older backups as needed when they're no longer required but DynamoDB does come with another option and this method is called point-in-time recovery it's something that you need to enable on a table by table basis and it's disabled by default. When you enable the feature on a table it results in a continuous stream of backups a record of all the changes to a table over a 35 day window and from that 35 day window you can restore to a new table with a one second granularity so when you enable this option you can create a new table by restoring this backup from any one second interval in that entire 35 day window so it's a really powerful feature but you do need to enable it explicitly on a per table basis.

Now before we finish up this lesson there are some considerations that you need to be aware of and some of these are really important for the exam so if you see any questions in the exam which mention no sequel then you should probably preference DynamoDB so if you see no sequel mentioned in the exam and DynamoDB is one of the options to answer that question with unless you've got a strong reason to answer otherwise you should probably default to DynamoDB. On the other hand if you see any question which mentions relational data or a relational database then the answer is likely to not be DynamoDB. DynamoDB is not suited to relational data it should not be used to implement any form of relational database system it's simply not designed for that and it doesn't include the required features. If you see any mention of key value mentioned in any exam questions and DynamoDB is one possible answer then again you should probably default to that answer unless you've got a strong reason not to.

Now access to DynamoDB is via the console the CLI or the API you don't have sequel or the structured query language when using DynamoDB. If you see any questions or answers which mention SQL or the structured query language then that probably excludes DynamoDB as being a correct answer. Now the billing for DynamoDB is based around a table it's based on the RCU and WCU values that you set on a table as well as the amount of storage required for that table and any additional features that you enable on that table. So it's a true on-demand database product there's no infrastructure costs for running DynamoDB no base costs you essentially pay for only the resources that you consume either storage operations or capacity requirements that you specify on a table and in addition you are able to purchase reserved allocations for capacity so if you do know that you have a requirement for long-term capacity on a DynamoDB table then you can purchase reservations so in return for a longer term commitment you get a cheaper rate but with that being said that's everything I wanted to cover in this lesson so go ahead complete this video and then when you're ready I look forward to you joining me in the next.

Welcome back! In this lesson, I want to talk about a powerful feature of CloudFormation called custom resources. Now, we've got a lot to cover, so let's jump in and get started straight away.

The way that CloudFormation is architected isn't complicated. You define logical resources within a template, and these define what you want CloudFormation to do, so what infrastructure you want it to create. CloudFormation uses these logical resources in a template to create a stack, and this stack creates physical resources. If you update the logical resources by updating and reapplying a template, then the physical resources are updated. If you remove a logical resource from the template and then reapply that template to a stack, then the physical resources are affected in the same way.

CloudFormation doesn't support everything within AWS. It can lag behind in terms of products or features of those products, and there are some things which it just doesn't support or things it never will support. CloudFormation custom resources are the answer to anything that you want to do in CloudFormation that it doesn't support natively. Custom resources are a type of logical resource that allows CloudFormation to do things it doesn't yet support or doesn't natively support, or they allow integration with external systems.

Examples of things that you can do with custom resources might include populating an S3 bucket with objects when you create it or deleting objects from a bucket when that bucket is being deleted. This is something that would normally error. If you try to delete a CloudFormation stack that contains a bucket with objects inside it, by default, it won't allow you to do that, and it will error. Another example is that you might want to request configuration information from an external system as part of setting up an EC2 instance. You can even use custom resources to provision non-AWS resources. So, using custom resources, the functionality of CloudFormation can be extended much beyond what it can support natively.

Now, the architecture of custom resources is simple. CloudFormation begins the process of creating the custom resource, and in doing so, it sends data to an endpoint that you define within that custom resource. This might be a Lambda function, or it could be an SNS topic. Whichever one you pick, it sends an event to this resource. Whenever a custom resource is created, updated, or deleted, CloudFormation sends data to that custom resource. It sends event data, which contains the operation that's happening, as well as any property information. So, the custom resource, for example, a Lambda function, is invoked and provided with that information.

Now, the compute that's backing that custom resource—let's use the example of a Lambda function—can respond to CloudFormation, letting it know of the success or failure, and it can pass back any data. Assuming a Lambda function which backs a custom resource responds with a success code, then everything is assumed to be good. The custom resource is created, and any data generated by that Lambda function is passed back into CloudFormation and made available to anything else within the CloudFormation template. So again, two options for how you can back custom resources are Lambda or an SNS topic.

Now, let's look at this visually because it will help you understand the architecture. Then I'll show you a practical example from the AWS console. So let's consider a scenario where a CloudFormation template is used to create a stack that creates an S3 bucket. Let's look at this without using a custom resource. We start with a CloudFormation template, which is a simple one containing a simple S3 bucket logical resource. Using this template, we create a stack, and this creates a logical resource inside the stack, which in turn creates the corresponding physical resource, the S3 bucket.

At this point, if you deleted the stack, it would delete the logical resource, which would delete the physical resource. If the bucket is empty, everything would work as expected. But let's say that a human gets involved, Gabby, and Gabby makes a manual change by adding additional objects into the bucket. Now we have a problem because the physical resource is out of sync with CloudFormation, and we have an even bigger problem because we have a bucket with objects inside it. If we tried to delete the stack at this point, CloudFormation would attempt to delete the logical resource, which would attempt to delete the physical one. But because the bucket contains objects, the delete operation would fail. This is just a limitation of S3 and CloudFormation. It's the type of situation you might hit when you're dealing with any complex architecture or when you need to do something that CloudFormation just doesn't support. This is one of the situations that custom resources aim to help with.

Let's look at what capabilities custom resources provide us that might help in this situation. So we start off with the same basic components. We've got a CloudFormation template, which creates a stack. This time, the template has more resources than just the S3 bucket. But first, it creates an empty bucket, just like the previous example. However, in addition, it has a custom resource, and that custom resource is supported by a Lambda function. Because this custom resource is backed by a Lambda function, it means that when the custom resource is being created by the stack, the Lambda function is invoked or executed, and it's passed some data.

This data is event data, and this data block contains anything given to the resource as properties. In this example, let's assume that the custom resource is provided with the bucket name of the bucket created by the CloudFormation stack, so the empty bucket. Now, for the sake of example, let's say we've designed this custom resource, this Lambda function, to download some new objects into this empty S3 bucket. This means that we now have a bucket with objects inside it, which is the same problem we had with the previous example.

Now, in addition to the bucket name being provided to this custom resource, the event data also contains details of how the Lambda function—or how the thing that's backing up the custom resource—can respond back to CloudFormation. This is called the response URL. So, the Lambda function, because it completed successfully, sends a response back, a success response, to this response URL. This means the logical resource will be created successfully, and the stack itself will move into a "Create Complete" status, so all is good.

So, we've used a custom resource at this point to download some additional objects into that S3 bucket. Now we have a CloudFormation stack in the "Create Complete" status and an S3 bucket with some objects in it. At this point, let's say that a human comes along, say Gabby again, and Gabby uploads some additional objects to the S3 bucket, such as additional cat images. We still have a bucket with objects, but now it's more objects than the custom resource added earlier. We have the objects added by the custom resource and the three additional cat pictures that Gabby has just manually uploaded.

Now, let's say we're going to do a stack delete operation. We select the stack, right-click on it, and select "Delete Stack." This starts the process of deleting the stack. Now, the stack has two logical resources and two corresponding physical resources: the bucket with objects and the custom resource backed by a Lambda function. In the above example, CloudFormation immediately tried to delete the bucket with objects, which is why it failed. But in this example, because when the custom resource was created, it needed the bucket to already have been created, CloudFormation knows that the custom resource depends on the bucket. There's a dependency. So, when you're deleting a stack, CloudFormation will follow the reverse of that dependency. This means the custom resource will be deleted before the S3 bucket.

What happens now is that CloudFormation starts the deletion of all the resources contained in the stack, but it starts with the custom resource. The way it does this is by sending the message to the Lambda function. The message has a similar structure to when the stack was created: an event data block that contains the fact that the stack is being deleted and still contains the name of the S3 bucket. The Lambda function performs whatever actions are configured for a delete operation, which in this case is to remove all the objects from the S3 bucket. Once this has been completed, once the Lambda function has finished all its operations, it will signal back to CloudFormation that this was successful. Again, this will happen by using the response URL that's contained in the event data.

Once the success response has been completed, the stack will delete the custom resource. Once the custom resource has been deleted, there will be no further dependencies inside the stack, and the stack will go ahead and delete the S3 bucket. This time, this will succeed because the S3 bucket is empty, and because the deletion of the S3 bucket completes successfully, the stack itself can be deleted, and the process completes successfully. By using a custom resource, we can add additional capability to CloudFormation. We can make it download additional objects into an S3 bucket and also have it clean up any objects, including those added by a human being outside of CloudFormation, before the S3 bucket is deleted. By doing it this way, we can avoid any stack deletion issues caused by buckets that contain objects.

This is a simple example of how we can extend the functionality of CloudFormation by using custom resources. With that being said, that's everything I wanted to cover. Go ahead and complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to briefly cover CloudFormation change sets. Now this is a feature which makes it safer to use CloudFormation within a full infrastructure as code environment or when CI/CD processes are being used within your organization. So let's jump in, step through what change sets are and what benefits they provide.

The usual flow that you engage with with CloudFormation goes something like this. You take a template, use it to create a stack which creates physical resources based on the logical resources in the template. That's a create stack operation. Or you delete a stack which deletes the physical resources created by the stack. Or you can take a newer version of a template, maybe it has additional resources or maybe it's a bug fix. In either case you take that new template, apply it to an existing stack and this changes existing physical resources and this is known as an update stack operation.

When a stack update occurs, when logical resources are changed which results in changes to physical resources, that change has one of three effects. We have no interruption and this is where certain changes made to a stack might not impact the operation of the physical resource. The change is just made and that's it. Next is some interruption which might mean something like an EC2 instance rebooting. It's not a damaging event but it can impact service. And finally certain changes might cause a replacement which creates a new copy of that physical resource and the old one is removed. This is disruptive and can result in data loss so it's critical to keep this in mind when making changes to existing CloudFormation stacks.

Now change sets let you apply a new template to a stack but instead of applying the change immediately it creates a change set which is an overview of the changes to be applied to the stack. What makes change sets powerful is that you can create many different change sets for a stack so you can preview different changes with different new versions of the template and when you've reviewed the change set or change sets then you can choose to discard them or you can pick one to apply by executing it on the stack which creates the stack update operation and updates the logical and physical resources managed by that stack.

Now visually the architecture looks like this. Let's use a simple example and don't worry we're going to be stepping through this in the console very shortly. So this example is a CloudFormation template which creates three buckets: catpicks, dogpicks and memes. So we use this to create a stack which creates the three S3 buckets. So far so good. But now let's say that we didn't actually mean to create the memes bucket. We only like animal pictures. Memes are just no good. So we create a new template and we use this to update the stack and because we're not using change sets immediately it deletes one of the S3 buckets: the memes bucket. The memes bucket has been removed from the template, its logical resource. Because of that, it is also removed and that means the physical resource that the stack manages is deleted from your AWS account.

Now using change sets we can improve this. The starting point is the same: we create a stack with the version 1 template. But instead of using the version 2 template to update the stack, instead we create a change set. Now this is a distinct thing, an object which represents the change between the original stack and the new version of the template. We can create one or more of these but when we're satisfied we can execute that change set against the stack and this has the same effect as the top method but we have more control and visibility over the changes, especially with larger and more complex templates.

Okay so I'm going to move across now to my console and demo how this works in practice. If you really want you can also do this in your own environment. I have included the CloudFormation templates within this lesson's folder on the course GitHub repository. But for this one I would suggest just watching. It's probably not something that's worth the effort of implementing yourself. I just want you to be aware of how this looks from the console UI.

Okay so I've switched over to my console and to do this demo lesson I need to be logged in as the IAM admin user of the general AWS account, so that's the management account of the organization. And as always I've got the Northern Virginia region selected. So I'm going to go ahead and move across to the CloudFormation console. So I'll type "cloud formation" in the search box at the top and then click to move to the CloudFormation console. And just before I apply anything, these are the templates which I'm going to be using in this really brief demo lesson. So we've got template one and this is a really simple CloudFormation template which creates three S3 buckets, and then template two which is going to be the one that I update the stack with. This only has two S3 buckets. So the first template creates cat pics, dog pics and memes, and then the second template only has cat pics and dog pics.

So let's move back to the console: create stack, upload a template file, choose file and then depending on the course that you're doing inside the infrastructure-as-code folder or the CloudFormation folder or the deployment folder, the name will vary depending on the course. You should see a change sets folder and in there we've got these two templates: template one and template two. Select template one and click on open. Then I'm going to scroll down and click on next and I'm going to call this stack "change sets", click on next, scroll to the bottom, next again, scroll to the bottom and click on create stack. So this is going to create our three S3 buckets. We can see that it's doing them in parallel: cat pics, dog pics and memes. That should only take a few seconds. There we go. One more refresh and it's moved into create complete.

Now that that's in create complete, if I click on resources we'll be able to see the three logical resources: cat pics, dog pics and memes, and their corresponding physical resources, so the three S3 buckets. Now there's a change sets tab, which if we click on you'll see that there are no current change sets for this stack and we can create a change set from here or we can go to stack actions and then create change set for current stack. So that's what we're going to do. We're going to create a change set. So I'm going to click on create change set. This dialog looks much like the one that you would get if you're just updating a stack without using change sets. So I'm going to replace the current template. I'm going to upload a template file and I'm going to choose template 2. And then once that's loaded click on next, click on next again, scroll down, next again, scroll all the way down and then create the change set.

And we're going to name the change set. So I'm going to call it "change sets - version 2". You can call this anything you want but I always find that it's useful to have the stack name at the start and then some kind of version indication. And if you wanted to type a description you could do that. Let's say "removing memes" and then create the change set. Initially it will show as create pending. I'll hit refresh. It will show as create complete. And now this is a separate entity in its own right. We've created a change set. We've not actually updated the original stack. So if I go back to stacks, we'll still see the "change set" stack. If I click on it and go to resources, all three of the logical and physical resources still exist.

So whilst we've uploaded this new template version and created a change set, we haven't actually done anything with this change set. So to use a change set, let's go and click on the change sets tab and then open up this change set. Again we'll see a visual list of all the changes that CloudFormation has detected between the version of the template the stack's using and this change set. And in this particular case it's telling us that an action of remove is occurring against the logical ID of "memes" and this physical ID. So because we've removed this logical resource from this template, it's telling us that the logical resource will be removed along with the corresponding physical resource.

We can click on this template tab and see an overview of the template that's part of this change set. In this case it's the template without the "memes" logical resource. If I click on the JSON changes button, you'll see a JSON formatted overview of exactly what's happened between the version of the template the stack's using and the version in this change set. It's a list of JSON objects and it's one JSON object per change. So in this case there's only one change which is logical resource ID "memes" and the action is to remove. And this is how you can get a really accurate overview of the changes between the version of the template that the stack's using and the version of the template that's contained within this change set. So it can form part of a really rigorous change management process within your business.

Now just keep in mind at this point I could have the single change set for this stack or I could have 10 change sets. And I can list them all individually. I can delete them all individually. But if I wanted this change set to be applied against the stack, I could do so by clicking on execute. So I'm going to do that. As soon as I click on execute, then it's going to run the update stack operation. And at this point, the changes would be exactly the same as if you just updated the stack, applied a new template and executed that immediately. The template that the stack is using will be changed to the one contained in the change set. The logical resource in this case will be removed and the corresponding physical resource will also be removed. And the end effect of this will be an updated stack. It has an update complete status. And if we go ahead and click on resources, we can see that this memes bucket has been completely removed from this stack. And that's a really simple example of how you can use change sets within CloudFormation.

Now at this point that's everything which I wanted to demonstrate in this lesson. I'm going to go ahead and click on delete and then delete stack. And if you've been following along in your own environment, you need to do the same to return the account into the same state as it was at the start of this lesson. With that being said though, that is everything I wanted to cover. So go ahead, complete this video, and when you're ready I look forward to you joining me in the next.

Welcome back and in this theory lesson I'm going to cover another CloudFormation feature called CFN HUP. Now we have a decent amount to cover so let's just jump in and get started.

Now as a refresher CFN-init is a helper tool which runs on EC2 instances during bootstrapping. The tool loads metadata stored within the logical resource in a CloudFormation stack and it's a desired state configuration tool which applies a desired state to an EC2 instance based on the metadata of that instance's resource. But, and this is important, it's only run once. If you change the CloudFormation template and update the stack then CFN-init isn't rerun so the configuration isn't reapplied.

CFN-HUP is an extra tool which you can install and configure on an EC2 instance so you're responsible for installing and configuring it but this can be handled within the same bootstrapping process as any other configuration when the instance is launched. Now CFN-HUP gets pointed at a logical resource in a stack and it monitors it. It detects changes in the resource’s metadata. This occurs for example when you update the template so when you change the metadata and then perform an update stack operation. When CFN-HUP detects a change then it can run configurable actions and commonly you might rerun CFN-init to reapply the instance’s desired state. So if you change the metadata, update a stack then CFN-HUP will detect this, rerun CFN-init which will apply that change. The end effect is that when you use both of these tools together any update stack operations which change the metadata can also update the EC2 instance's operating system configuration and this is something which isn't normally the case.

Now visually this is how it looks. We have a CloudFormation template which is used to create a stack and the stack creates an EC2 instance. Now the template in this case contains some metadata which is for the EC2 instance's logical resource and let's assume that this is used initially to configure the instance. Maybe to configure WordPress or install some other service or application. Now this is how CFN-HUP interacts in this type of architecture. Let's say that we change the template and then when we change the template we perform an update stack operation because we've previously installed CFN-HUP on the instance. This is periodically checking the metadata for the logical resource for that instance in the stack. When it detects a change we've configured it to run CFN-init and CFN-init then downloads the new metadata for that instance and applies that new configuration. It's a simple but super powerful architecture and you'll be getting practical experience of using this in an upcoming demo lesson.

For now I just wanted you to be aware of two things. Firstly if you update a stack that doesn't automatically rerun any bootstrapping on resources in that stack. So if you want to change the metadata for a resource to include an additional application install that doesn't automatically get applied. If you're using normal user data that's only by default executed once when you launch the instance. If you update a stack and change that it's not automatically reapplied to the instance. So the way that you need to do this is install and configure CFN-HUP as part of the initial bootstrap process. Configure it to monitor the logical resource for that instance and then when any changes are made it can then initiate another CFN-init to apply that desired configuration.

So you're going to experience this practically within an upcoming demo lesson. For now though that's everything so go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about a feature of CloudFormation called CloudFormation init. It's another way that you can provide configuration information to an EC2 instance. So far you've experienced bootstrapping via the user data and this is an alternative. Now let's just jump in and get started as we've got a lot to cover.

CloudFormation init is a simple configuration management system. So far you've used user data to pass scripts into an EC2 instance. Now this isn't a native CloudFormation feature. What you're essentially doing is passing in a script through EC2 using the user data feature which is an EC2 feature into the operating system running on the instance where it's executed. Now CloudFormation init is a native CloudFormation feature. Configuration directives are stored in a CloudFormation template along with the logical resource it applies to an EC2 instance.

So we have an AWS double colon cloud formation double colon init section of a logical resource. This is part of an EC2 instance logical resource and it's here where you can specify directives of things that you want to happen on the instance. The really important distinction that you have to understand is that user data is procedural. It's a set of commands executed one by one on the instance operating system. You're essentially telling the instance operating system how to bootstrap itself. You're giving the instance the how — how you want things to be done.

CloudFormation init on the other hand this is a desired state system. You're defining what you want to occur but leaving it up to the system as to how that occurs and that makes it in many different ways much more powerful, not least of which because it means that it can be cross platform. It can work across different flavors of Linux and in some cases on Linux and Windows running on EC2 instances. Now it's also idempotent meaning if something is already in a certain state running CloudFormation init will leave it in that same state. If Apache is already installed and your CloudFormation init wants Apache installing then nothing will happen. If CloudFormation init defines a config file for a service and declares that that service should be started and if both of those things are already true then nothing will happen. It's much less hassle than having to define within your script's logic as to what should occur if something is already the case.

By using the desired state feature of CloudFormation init it's much easier to design and easier to administer because you just need to define the state that you want instances to be in. Now accessing the CloudFormation init data is done via a helper script called cfn-init which is installed within the EC2 operating systems. This is executed via user data. It's pointed at a logical resource name, generally the logical resource for an EC2 instance that it's running on. It loads the configuration directives and it makes them so.

Now it's probably going to be easier to understand CloudFormation init along with the cfn-init helper tool if we look at it visually. It all starts with a CloudFormation template. This one creates an EC2 instance and you'll see this yourself very soon in a demo lesson. The template has a logical resource within it for an EC2 instance and this has a new special component — metadata, an AWS double colon CloudFormation double colon init, which is where the cfn-init configuration is stored.

Now the cfn-init helper tool is executed from the user data and so like most EC2 logical resources we pass in some user data but note how this user data is very minimal only containing cfn-init which implements the configuration that we define and then cfn-signal which is used to tell CloudFormation when the bootstrapping is complete. So the template is used to create a stack which creates an EC2 instance. The cfn-init line in the user data at the bottom is executed by the instance and this should make sense now — everything in the user data section is executed when the instance is first launched.

Now if you look at the command for cfn-init you'll notice that it specifies a few variables — stack ID and a region. Remember this instance is being created by CloudFormation. These variables are actually replaced for the actual values before it ends up within an EC2 instance. So the region is the actual region that the stack is created in and the stack ID is the actual ID of the stack that we're currently using and these are all passed to the cfn-init helper tool and this allows cfn-init to communicate with the CloudFormation service and receive its configuration and it can do that because the actual values for the region and the stack name — these are all passed in via user data by CloudFormation and once the cfn-init helper tool has this data then it can perform the configuration which has been defined within the logical resource.

Now you're going to experience this in a demo which is coming up slightly later in this section but before we do that I want you to focus on the CloudFormation-init section within the EC2 resource on the left — so under metadata and then under CloudFormation double colon init. We're going to come back to config sets specifically but all of those others are known as config keys. Think of them as containers of configuration directives and each of them contains the same sections. So we have packages which defines which packages to install, groups which allow us to define directives to control local group management on the instance operating system, users which is where we can define directives for local user management, sources which lets us define archives which can be downloaded and extracted, files which allow us to configure files to create on the local operating system, commands which is where we can specify commands that we want to execute, and then finally services which is where we can define services that should be enabled on the operating system.

Now often within CloudFormation-init you'll define one set of config — so one config key containing one set of packages, groups, users, sources, files, commands and services — but you can also extend this. You can define config sets. You can create all of these different config keys and then pick from that list and bundle them into a config set which defines which config keys to use and in what order.

Now if you look at the CFN-init line in the user data at the bottom of your screen we're using one specific config set called WordPress underscore install and this uses all of these config keys defined on the left — so install CFN, software install, configure instance, install WordPress and configure WordPress — but we could have others, maybe ones which upgrade WordPress or install a completely different application. But whatever the configuration we have in the logical resource, we use the CFN-init helper tool, we specify the stack ID, the particular logical resource, the region and then the config set to use — in this case WordPress underscore install.

Now again don't worry if this is a little bit confusing — this is just the theory. We're going to be doing one more theory lesson about CFN-hub which is another helper tool available within cloud provision and once we've done that theory lesson as well you're going to do a demo lesson which uses both CFN-init and CFN-hub. So by the end of that demo lesson you're going to understand how to use both these helper tools — both individually and combined — to provide a really good bootstrapping and configuration system.

Now that's all of the theory that I wanted to cover. In the next lesson, as I've just mentioned, we're going to be covering the theory of CFN-hub. So at this point thanks for watching, go ahead complete this lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to discuss another feature of cloud formation which you will need for the exam so let's jump in and get started.

You know by now that when you create a stack cloud formation creates logical resources based on what's contained in the cloud formation template but for each of those logical resources it also creates a corresponding physical resource within AWS. Now everything which happens inside AWS requires permissions and as you know by now the default permissions within AWS is zero permissions.

Now by default cloud formation uses the permissions of the identity who is creating the stack to create AWS resources. Examples of this might be an iam user interacting with a console UI or using the command line. This means that by default you need the permissions to create, update or delete stacks and permissions to create, update or delete any resources for the stacks that you're creating. So without any other functionality in order to interact with an AWS account using cloud formation you need both permissions to interact with stacks and permissions to interact with AWS resources.

Now for many organizations this is a problem because there are often separate teams who create resources and then others which are allowed to update them or support them. Cloud formation stack roles is a feature which allows cloud formation to assume a role and via assuming that role gain the permissions required to interact with AWS and create, delete or update resources. This allows us to use a form of role separation. One team can create stacks and the permission sets required to implement them and then the identity creating, updating or modifying a stack only needs permissions on that stack and the past role permissions. So an identity that's interacting with a stack using stack roles no longer needs the permissions to interact directly with the resources themselves and this is really powerful. It means an admin user could create a stack with an associated role attached and then a non admin user could be given permissions to interact with that stack using that role without ever having to have the permissions to interact with those resources.

Now this is going to be easier to understand visually so let's have a look at that next.

Now we have two main identities in this example scenario. We have Gabby on the left who is an account administrator for this AWS account and then on the right we have Phil who is a help desk engineer and in the middle we have the AWS account that both of these identities have to interact with. Now normally if we wanted Phil to create any AWS resources then he would need to be allocated those permissions either by assuming a role himself or by having the permissions attached either to his user directly or via any groups he is a member of. Now we want Phil to be able to manage the infrastructure via cloud formation only and either of those options would mean Phil could create the resources directly and this we don't want.

Cloud formation can be a great tool that we can use to control the types of things that can be created, modified or deleted by identities which have lesser permissions. So using stack roles step one would be that Gabby could create an IAM role with the permissions to interact with AWS resources. This role has the permissions to interact with the resources but crucially Phil can't edit the role and he has no permissions to directly assume the role. Phil only has permissions to create, update and delete stacks as well as the permissions to pass the role into cloud formation and that's what he does. He takes a template that Gabby has created earlier and he uses it to create a stack. While doing so he passes the role that Gabby's created into the stack by selecting it within the console UI. This means that the role is attached to the stack and it will be used rather than Phil's own permissions when the stack is performing any resource operations on AWS, meaning that Phil doesn't need the permissions to directly manipulate those resources.

When the stack starts creating it can assume the associated stack role and use the permissions that it gets to create all of the resources within the AWS account so it no longer has to rely on the permissions that Phil has directly associated with his IAM user. Now this is a really simple example but it's an example of role separation. Gabby as an administrator can create things within the AWS account that Phil can use. Gabby herself might not even be allowed to use the things that she creates. Phil on the other hand doesn't have the permissions to create permissions himself he can't edit the role he can only use it and only with cloud formation. When using it he doesn't need the permissions that Gabby has to create resources he can simply pass this role into cloud formation and then that gives cloud formation the permissions that it requires to interact with resources inside the account.

Now in the exam if you see this type of scenario where an identity needs to use cloud formation to do things that they wouldn't otherwise be allowed to do outside of cloud formation then stack roles is a great solution to allow this. You can have one IAM admin user provision an IAM role with the permissions required and then give the identity with the reduced access only the rights to pass that role into cloud formation and then the permissions required to interact with stacks in cloud formation and with the combination of those two things the user Phil in this case can perform actions on the AWS account in a safe and controlled way that he otherwise wouldn't have the permissions to do.

Now that's everything that I wanted to cover in this lesson stack roles is not a complicated feature but it's a powerful one and it's one that you'll need to be fully comfortable with for the exam. With that being said thanks for watching go ahead complete the video and when you're ready I'll look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk briefly about a feature of CloudFormation called deletion policies.

Now this is a pretty simple feature to understand but it's one that you'll be using extensively if you're deploying larger production systems into AWS using CloudFormation. So let's jump in and get started.

So what is a deletion policy? Well if you delete a logical resource from within a CloudFormation template and then apply that template to an existing stack or if you delete a stack entirely then the default behavior of CloudFormation is to delete the corresponding physical resource. Now with certain types of resources this can cause data loss. If you're deleting RDS databases or EC2 instances with attached EBS volumes then deleting these physical resources can actually delete data that lives on those resources.

Now a deletion policy is something that you can define on each resource within a CloudFormation template and depending on the type of resource you're able to specify a certain action which CloudFormation should take when that physical resource is being deleted. Now the default is that CloudFormation will delete a physical resource when the corresponding logical resource is deleted. You can also specify retain and that simply means that CloudFormation will not delete the physical resource if the corresponding logical resource is deleted. So if every logical resource within a CloudFormation template is set to retain then when you delete the stack none of the physical resources will be removed. They're retained inside the AWS account.

Now for a smaller subset of supported resources you can specify the snapshot option for the deletion policy. Supported resources include EBS volumes, ElastiCache, Neptune, RDS and Redshift and when you specify the snapshot option for any of these type of resources then before the physical resource is deleted a snapshot of that resource is taken. So for example if you have an EBS volume defined within a CloudFormation template using the snapshot deletion policy if you delete that logical resource and then reapply it to a stack CloudFormation will delete the physical resource but not before it's taken a snapshot and these snapshots continue past the stack lifetime. So if you delete a stack and you have snapshots selected then these snapshots are your responsibility to clean up. You have to clean them up otherwise they'll continue to incur costs because they're essentially storage within AWS and as with any snapshots that comes with an associated cost.

Now one really important aspect of this to understand is that deletion policies only apply to delete style operations. Now what this means is if you have a logical resource in a template and you remove it and then apply that to a stack or if you delete the stack then that's a deletion operation and in that case then the deletion policy will apply but it's possible that you can subtly change a logical resource in a template and then reapply that to the stack and that will cause the physical resource to be replaced which is essentially the same as a delete and then a recreate. Now a deletion policy will not apply in this case and if a resource is replaced then any data on that original resource will be lost and so it's important that you understand that this applies only to deletion operations it does not apply to change astrological resources which cause replacement of physical resources.

So this is how it looks visually at the top we create a stack which creates an EC2 instance an EBS volume and an RDS instance on the left this is what happens when we delete that stack so this is the default process that happens with cloud formation and all of the physical resources are removed from the account. In the middle we have the same scenario but when the retain deletion policy is used in this case all of our three resources the instance the EBS volume and the RDS instance they're all retained they remain untouched in the account after the stack has been deleted. Now on the right we have the snapshot option and it's important to note that snapshot is not supported for EC2 instances so we can't choose this option for EC2 but for resources which do support it so an EBS volume or an RDS instance the result will be that an EBS snapshot or an RDS snapshot remain after the stack has been deleted so you will be responsible for managing these snapshots if you want to delete them after a certain period of time that will be entirely your responsibility.

Now this is all of the theory that I wanted to talk about in this lesson I'm not going to cover it in any more depth because this is something that you'll get experience of yourself as you're doing the demo lessons in any of my courses for now though I just wanted to introduce you to the theory and I wanted to make sure that you're aware that the snapshot option is not supported on all AWS resource types so that's really critical to understand. At this point though thanks for watching go ahead and complete this video and then when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be covering stack sets. And stack sets are a feature of CloudFormation which allows you to create, update or delete infrastructure across many regions potentially in many AWS accounts. At a high level stack sets allow you to use CloudFormation to deploy and manage infrastructure across many accounts and regions in those accounts. Rather than having to authenticate to each account individually and switch to each region you can let CloudFormation do all of the hard work on your behalf.

Now let's cover the key concepts first before we look at the architecture visually. First we have stack sets themselves. Now think of stack sets as containers and these containers are applied to an admin account. I don't want you to think of the admin account as anything special. We just refer to it as an admin account when we're talking about stack sets to distinguish the account where a stack set is applied from all of the other accounts where CloudFormation creates resources. So again stack sets are containers and stack sets contain stack instances. Now these aren't the same thing as stacks. You can think of stack instances as references. So references to actual stacks running in specific regions in specific AWS accounts. So stack instances reference one particular stack in one particular region in one particular AWS account and a stack set can contain many stack instances.

Now the reason that stack instances are treated separately from stacks is that if a stack fails to create for any reason then the stack instance will remain to keep a record of what happens. So why is stack failed to create? So think of a stack instance as a container for an individual stack. So to summarize stack sets are applied in an admin account. Stack sets reference many stack instances and stack instances are containers for individual stacks which run in a particular region in a particular account. Now stack instances and stacks are created within target accounts. Now target accounts are just normal AWS accounts that we refer to as target accounts because these are the accounts that stack sets target to deploy resources into. So a stack set architecture consists of a stack set in an admin account referencing stack instances and stacks which are in the target accounts and regions that you choose.

Now each cloud formation stack created by stack sets is just a normal cloud formation stack. It runs in one region of one account and the way that all of this multi-account multi-region architecture is created on our behalf by stack sets is by using either self- managed roles or service managed roles and service managed roles are where we use cloud formation in conjunction with AWS organizations so all of the roles get created on your behalf by the product behind the scenes. So you can either use service managed security where everything's handled by the products for you or you can go ahead and manually create roles and then use self-managed roles to get the permissions so that cloud formation stack sets can create infrastructure across many different accounts in many different regions.

Now visually stack sets look like this so using a stack set starts off in an admin account and this is an AWS account and this is the one that's on the left of your screen. It's in this account that we create our stack set and we'll call this the bucket atron because we need a lot of S3 buckets for storing some cat related images. Now an important thing to be aware of is that a template used to create a stack set it's just a normal template it's nothing special. For this example let's assume that we have a very simple template which creates a single S3 bucket. Using stack sets we also have some other accounts these are called the target accounts in this example we have two different AWS accounts and in each of these accounts we've got two regions it doesn't matter which ones so let's just call them region 1 and region 2.

Now I mentioned on the previous screen that permissions for stack sets either come in the form of self-managed IAM roles or via service managed permissions as part of an AWS organization which the target accounts are members of. Cloud formation is essentially in either case assuming a role to interact with all of these target accounts. Now as part of the stack set creation you indicate which organizational units or accounts you want to use as targets you give the regions and then cloud formation begins interacting with those accounts it uses roles for permissions. Now what it's doing is creating stack instances within each region that you pick within each target account that you select as part of creating the stack set. Stack instances remember are just containers they're things that record what happens in each stack that's created by stack sets in each region in each account that you select.

So once we're at this point once we've created the stack set once cloud formation has used the IAM roles to integrate with each of the target accounts that you've selected and once the stack instances have been created then the stacks themselves are actually created. One per region in each target account that you've selected as part of creating at the stack set and this stack creation process in turn creates the resources which are defined within the template. Now with this example without using stack sets we have two regions and two accounts so this makes a total of four stacks which would need to be created for the desired infrastructure. Now what if instead of two regions we used them all and instead of two accounts maybe we have 50. Then the effort reduction provided by stack sets starts to become a little bit more obvious.

So what kind of things can stack sets be used for? Let's look at that next with some other key concepts that you need to be aware of for both the exam and real-world usage. Now there are a few terms that you need to be aware of. The first is concurrent accounts so this is an option that you can set when creating a stack set and this defines how many individual AWS accounts can be used at the same time. So if you're deploying a stack set which is deploying resources into say 10 different accounts and you define a concurrent account value of two then only two accounts can be deployed into at any one time which means that over 10 accounts you'll be doing five sets of two. So the more concurrent accounts that you set in theory the faster the resources will be deployed as part of a stack set.

We've also got the term failure tolerance and failure tolerance is the amount of individual deployments which can fail before the stack set itself is viewed as failed. So you need to decide this value carefully especially for larger infrastructure deployment and management. Next we've got the term retain stacks so what you're able to do is remove stack instances from a stack set and by default it will delete any of the stacks that are in the target accounts but you can set it so that you can remove stack instances from different AWS accounts and different OUs and different regions and it will retain any of the cloud formation stacks within those regions within those accounts. So by default it will delete the actual stacks but you can set it to retain them.

Now the types of scenarios you might use stack sets for might include enabling AWS config across a large range of accounts. You might want to use stack sets to create AWS config rules for things like multi-factor authentication, elastic IPs or EBS encryption or you might want to use stack sets to create IAM roles that are used for cross account access at scale so instead of having to create them in individual accounts one by one you can define a cloud formation template to create an IAM role and then deploy it as part of a stack set.

Okay now at this point that's everything that I wanted to cover from a theory perspective in this lesson. Immediately following this lesson is a demo where you're going to get the chance to experience stack sets within your own environment but for now that's everything that I wanted to cover so go ahead and complete this video and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to continue on from the last lesson where I stepped through nested stacks only this time I want to talk about cross stack references which are similar but used in a very different set of architectural scenarios. So let's jump in and get started.

In the last lesson I talked about this architecture. I talked about how nested stacks could be used to get past the cloud formation resources per stack limit. I talked about how if you wanted to reuse templates for modular parts of architecture, for example creating a standard VPC template once and then reusing it, then nested stacks were ideal. And I talked about how if you wanted to simplify the process of creating large infrastructure using cloud formation you could do it by using nested stacks because a single root stack could create any nested stacks which it needed.

Now the limitation of nested stacks was that if you reused a particular template, say the VPC template, you would only reuse the code not the actual VPC that it creates. If you implemented 10 root stacks each of which was identical then you'd have 10 application stacks, 10 active directory stacks and 10 VPC stacks which included 10 VPCs. Now in some cases we want to consume a shared component, for example the VPC, for lots of different implementations. The problem is the isolation which is a design feature of cloud formation.

Let's say that you have a stack which is a well-structured and secured VPC and you want this to be a shared VPC usable by other application stacks in the same region and the same account. The issue is that stacks are by design self-contained and isolated. There's a logical boundary around each stack which means that things in one stack can't be by default referenced in another. In this example if we were deploying EC2 instances into AppStack 1 and AppStack 2 they couldn't natively reference the subnets created by the shared VPC stack. Now you could manually add the VPC ID and the subnet IDs into AppStack 1 and AppStack 2 but that means they're static parameters, they're not references and this is where cross stack references come in handy if you want one stack to be able to reference the resources created in another in order to reuse those actual resources.

Now to understand the benefit of cross stack references first understand that because of the isolation of stacks normally the outputs of stacks are only visible from the user interface or the command line. You can't use the built-in ref function of cloud formation to reference anything from one stack in another. The exception to this as I detailed in the previous lesson is that root stacks can reference the outputs of nested stacks but that architecture as you also learned means that the stacks are linked in terms of their lifecycle. Sometimes like when you want to create a shared VPC architecture you actually want a situation where a VPC might have a long running lifecycle and applications which use that specific VPC they might have a short lifecycle so you don't want to define all of those as part of the same nested stack.

An example of this imagine you work for a software development company each time a new version of your application is committed to a github repository you want to use cloud formation to create a VPC run the application in the VPC and operate a set of tests before tearing it all down. Now you could create an isolated VPC each time using a nested stack architecture but if you wanted to save costs you could use the same shared VPC the same set of NAT gateways and the same set of subnets to do this outputs of a template can be exported. An export is defined within an output of a stack it takes that output and adds it under an exported name to a list of exports in one region of your account so the export name has to be unique.

So for a shared VPC design some examples of what you might choose to export might be VPC ID, subnet IDs, side arrangers, security group IDs anything which you could expect to use elsewhere so external to that shared VPC stack. To repeat though the export name needs to be unique inside one region of your account. To use the export inside another stack instead of using the ref function which is how you reference other resources in the same stack you use the import value function you provide import value with the export name and it returns the value exported in that other stack so that's how you can use exports from one stack in another.

So let's have a look visually at how this works. Architecturally we start with a single AWS account running in one particular region in this example US East 1. Inside this region we have a VPC stack and we want this to be a shared services VPC which can be used by other stacks. Step one is inside that stack make sure that anything we want to use is added as an output for example the VPC ID. So this is an example of the output section for this particular stack we've got shared VPC ID as an output and then we use the reference function to reference the actual VPC logical resource that's created inside this stack.

Now this means this output will be visible from the command line or the console UI but to use this value in any other stack in this region of the account we need to use the export directive to export that value to a list within one region of your account and this is the exports list and this operates per region per account so this is only visible inside your account in one specific region. Every region inside your account has its own list of exports everyone else's accounts and all of the regions in those accounts each of those has their own dedicated list of exports so within the exports list any of the exports need to be unique so we can only have one export called shared VPC ID within that region of that account.

Now once a value is in the exports list it can be referenced in other stacks using the import value function this function replaces the ref function and remember the ref function is what you can use to reference other logical resources inside a single stack the import value function when used in a stack allows you to reference values which are exported from other stacks and added to the exports list. Now this only works in the same region as a stack is being applied in cross region or cross account isn't supported for cross stack references so essentially the process is that you need to create an output in one stack export the value for that output into the exports list and then use the import value function to import that exported value into each stack that you want to use it in and that's how you can create shared services by using cross stack references.

Now there are a number of situations where you would choose to use cross stack references for example when you're implementing service oriented architectures i.e. when you need to provide services from one stack to another another example is if you have a churn of short lived applications which all consume from a shared services VPC then you don't want them to be in the same stack or as part of a nested stack if you have things which have different life cycles long versus short then you want to separate them into different stacks and use cross stack references if you want to reuse a stack so reuse the resources created by a stack rather than reusing a template then cross stack references are ideal for the exam I want you to be clear that a template is not a stack or vice versa a template is used to create one or more stacks each stack is unique if you want to reuse a template then you can choose to use nested stacks which allow you to use the same template that you've created once in many distinct architectures a VPC template for example might be used as part of an email system a financial system or for the implementation of hundreds of different isolated client environments that's if you want to reuse a template and each time you reuse that template it creates its own distinct infrastructure but if you want to reuse an actual stack so the resources inside a stack as with this example of a shared VPC then you should use cross stack references rather than nested stacks so cross stack references allow you to reuse actual resources nested stacks allow you to reuse templates they're very different things I hope by this point it makes sense understanding the differences for the exam is essential and if you pick the wrong one in a real-world situation the results can be less than ideal at this point though that's everything that I wanted to cover so go ahead and complete this lesson and when you're ready I look forward to you joining me in the next.

Welcome back. In the next two lessons I want to cover two features of Cloud Formation. In this lesson I'm going to be covering Cloud Formation nested stacks and in the lesson following I'll cover cross stack references. Now we've got a lot to cover so let's jump in and get started.

Most simple projects and deployments which use Cloud Formation will generally utilize a single Cloud Formation stack and a Cloud Formation stack is isolated meaning it contains all of the AWS resources that the project needs. These might be things such as a VPC, DynamoDB, S3, maybe EC2 and Lambda, SNS, SQS and maybe even a directory service. Now there's nothing wrong with having a Cloud Formation stack built in this way. It's isolated, the resources inside it are created together, they're updated together and eventually they're deleted together. The idea is that all of the resources within a Cloud Formation stack share a life cycle. Stacks make it simple to package everything up into one collection of resources.

Now designing Cloud Formation in this way where everything's contained in one single stack is fine as long as you don't hit any of the limits that might impact your project. There are a few things that you need to be aware of. The first is that there is a limit of 500 resources per stack and for larger deployments this could be a problem. Another issue with isolated stacks is that you can't easily reuse resources. If you had a stack like this one which created a VPC it's not practical to reference that VPC in other stacks which might also want to use it. Stacks are by design isolated by default. You can use the ref function to reference resources from other resources in the same stack but you can't use this to reference resources in other stacks.

So stacks are isolated. You have to treat them as self-contained groupings of infrastructure which share the same life cycle. So you create a stack that creates all of the resources, you update a stack that updates all of the resources and eventually you delete the stack and that deletes all of the resources. Everything shares the same life cycle.

At the professional level or just for any projects which are complex you'll tend to use a multi-stack architecture. So you'll implement your project using multiple stacks and there are two ways to architect a multi-stack project. Nested stacks and cross stack references and choosing between them is what I want you to be fully comfortable with for the exam and in this lesson we're going to be starting by looking at nested stacks. So let's look at that architecture next.

Nested stacks technically are pretty simple to understand. You start with one stack which is referred to as the root stack. In this example this stack is both the root and the parent stack. A root stack is the stack which gets created first. So this is the thing that you create either manually through the console UI or the command line or using some form of automation. So the root stack is the only component of a nested stack which gets created manually by an entity either a human or a software process. Now a parent stack is the parent of any stacks which it immediately creates. So complex nested stack structures can actually have multiple levels. A root stack can create several nested stacks and each of those can in turn create additional nested stacks. So a parent stack is just a way that we can refer to anything which has its own nested stacks. So in this case this stack is going to be a root stack and a parent stack.

Now a root stack can have parameters just like a normal stack and also have outputs also just like a normal stack and that's because a root stack is just a normal stack. There's nothing special about nested stacks. Inside all stacks you have logical resources and examples of these that you've seen so far include S3 buckets, a virtual private cloud or VPC and maybe even a DynamoDB table. Now you can also have a cloud formation stack as a logical resource and you define it using the type of AWS double colon cloud formation double colon stack and this is a logical resource just like any other only it creates a stack of its own. So you have to give the nested stack a URL to the cloud formation template which will be used to create it.

So that template will contain its own resources it's just a normal cloud formation template as I've just mentioned it could even contain its own nested stack. So in this case HTTPS colon forward slash forward slash some URL dot com forward slash template dot yaml is the URL to a template which will be used to create this nested stack the stack that's called VPC stack. Now you can also provide nested stack resources with some parameters in this example we're creating a nested stack called VPC stack and if the template for VPC stack had three parameters so param one, param two, param three then we would need to provide values into that stack as it gets created. For every parameter that the template has for this nested stack we need to provide a value as we create it if not the stack creation process will fail.

So in this particular case the template dot yaml file that's used for VPC stack has three parameters param one, two and three and when we're creating it as a nested stack we need to supply parameters for those values that are used to create that stack. Now the exception to this is if the VPC stack template had default values for its parameters if it has default values then we wouldn't have to provide those when creating it as a nested stack but it's best practice to populate the VPC stack logical resource with parameters for everything which is parameterized within the template that's used to create that stack.

So in this case we have the root stack it currently has one logical resource VPC stack this creates a nested stack resource and we're passing in these three parameter values. So when the VPC stack nested stack finishes creating then the logical VPC stack resource within the root stack moves into a create complete status and any outputs of that nested stack are returned to the root stack and these can be referenced using the logical resource name of the nested stack so VPC stack and then dot outputs and then the actual output name of the nested stack. So you can only reference outputs when using nested stacks you can't directly reference logical resources created in any of the nested stacks you can only reference the outputs that you make visible when creating the nested stack.

Now we might also have other nested stacks contained within the root stack and because these are also logical resources they too would be created but they might have dependencies either ones which cloud formation calculates or one where we use the depends on directive to explicitly inform cloud formation that there is a dependency between different stacks for example we might have an active directory nested stack called AD stack which depends on the VPC stack whether it's a self-managed active directory or one provided by directory service it will need to run from a VPC and so it will depend on that VPC and that VPC is getting created within the VPC stack nested stack.

Now the root stack can take the outputs from one nested stack and give them as parameters to another examples of this might be the VPC ID or the subnet IDs of the resources created inside the VPC stack. Once the AD stack finishes creating it too might have outputs which are then returned to the root stack then we might create another nested stack perhaps an application stack and this might depend on the AD stack maybe it uses active directory for user authentication and once complete this application stack can also provide its outputs back to the root stack maybe this is a login URL for the application itself as each of the nested stacks finished provisioning the resource in the root stack will be marked as create complete and once all of the logical resources for the nested stacks are complete then the root stack itself will be marked as create complete.

Now there are two really important aspects to nested stacks that you need to understand in order to pick between nested stacks and cross stack references which I'll be talking about in the next lesson. First by breaking up solutions into modular templates it means that these templates can be reused in this example we have VPC stack which is probably something that can be used again and again for different deployments if you upload the template somewhere then many nested stack architectures can use that template and crucially this is reusing the code or the template for a stack it's not reusing the same stack itself so we're not reusing the VPC that's being created by VPC stack what it means is that we can reuse the template that created VPC stack so by uploading the template for the VPC stack other nested stacks can reuse this same YAML template but if you do reuse the same VPC template in another stack it will create a separate VPC the benefit is the ability to reuse the same templates you're not reusing the same stacks now the AD stack template can also probably be used for different projects which use Active Directory but again every time that this particular template is reused it will create a different Active Directory you're reusing the code not the actual resources this isn't the same when we use cross stack references which I'll be covering in the next lesson because then you're actually reusing resources that are created by a stack when using nested stacks you're reusing the template not the actual stack so you generally use nested stacks when you've created individual building blocks so modular templates and you can reuse each of these templates to form part of a single solution which is life cycle linked so you might be able to reuse the template which creates a VPC on lots of different nested stacks but crucially it would always create a dedicated VPC you would not be using the same VPC in the same stack you would be recreating a new stack and new resources each and every time now nested stacks are generally used when all of the infrastructure that you're creating is forming part of the same solution when it's life cycle linked in this example the application needs Active Directory which needs a VPC it's unlikely that one will exist without the other you aren't going to want to switch out Active Directory for another Active Directory or the VPC for another VPC it's likely that these will all be created together operate together and maybe someday be deleted together now nested stacks do allow for a few main benefits before we finish this lesson I just want to summarize them use nested stacks when you want to overcome the resource limit of using a single stack if you have five stacks together as a nested stack you can have 2,500 resources use nested stacks when you're modularizing your templates that way you can create a VPC template once and use it for many implementations but remember if you use nested stacks and each one of those projects will create its own physical VPC with nested stacks you're only reusing the template so the code you're not reusing resources themselves use nested stacks when you want to make stack installations easier this is because you can apply a root stack and have that root stack automatically orchestrate the application of many nested stacks the one single decision point between using nested stacks and cross stack references is only use nested stacks when everything is life cycle linked when everything in the stack structure needs to be created with each other updated with each other and eventually deleted with each other if you're anticipating needing one part long term but not others then nested stacks are the wrong choice if you imagine needing to use the same actual VPC across multiple implementations then cross stack references are probably better suited and we'll talk about that in the next lesson if you want to make frequent changes to one part of an application and not others then it's probably better to have individual non nested stacks and utilize cross stack references which we'll talk about next okay so that's everything I wanted to cover about nested stacks in the next lesson I'll be comparing this to cross stack references so go ahead and complete this lesson and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about a feature of Cloud Formation called Depends On. And Depends On allows you to establish formal dependencies between resources within Cloud Formation Templates. Now to explain what this is and why it's required, I'm going to step through a few key points and then we're going to look at it visually.

Now when you use a Cloud Formation template to create a Cloud Formation stack, Cloud Formation tries to be efficient. And the way that it attempts to be efficient is to do things in parallel. So when it's creating, updating or deleting resources, it's attempting to do this where possible in parallel. So for example when using one of my demos, you might notice that many resources inside the template are being created at the same time. Now while it's doing this, it's trying to determine a dependency order. So for example, it wants to create the VPC first, then create subnets inside that VPC and then create EC2 instances which run in subnets, which run inside a VPC. So it tries to determine a dependency order or a dependency tree automatically within the Cloud Formation stack. Now one of the ways that it does this is by using references or functions. So if an EC2 instance references a subnet and a subnet references a VPC, then it knows that it needs to create the VPC first, then the subnet and then the EC2 instance.

Now the Depends on feature simply lets you explicitly define any dependencies between resources. So you can formally define that resources B and C depend on resource A and that means that Cloud Formation will not attempt to provision either of those resources until resource A is in a create complete state. Now in most cases, this built in dependency mapping will work and you won't encounter any issues. For example, you might see in many of my demos or advanced demos that if the user data that's defined for an EC2 instance references an Aurora cluster, then it's going to wait until that Aurora cluster has been created before creating the EC2 instance. So it tends to work in 99% of cases, but Depends on is a really useful way that lets you explicitly define this dependency relationship. So let's take a look at visually at how that works.

So let's say that we start with two Cloud Formation logical resources in a template. Let's say a VPC and an Internet Gateway. Now these are different resources and there's no link between the two. You can create an Internet Gateway without having a VPC and you can create a VPC without having an Internet Gateway. So there's no implicit or explicit dependency between either of them. Neither of them require the other to exist. But consider this, we have an Internet Gateway attachment. This attaches an Internet Gateway to a VPC. So logically it requires both of them. You can see here in orange at the top that we reference the VPC and in blue at the bottom we reference the Internet Gateway. This creates implicit dependencies. The Internet Gateway attachment depends on both the VPC and the Internet Gateway resources. Now it's implicit because we haven't actually formally stated this dependency. It's just assumed by Cloud Formation because the Internet Gateway attachment logical resource references the other two.

We can't reference a resource until it's in a create complete state. So until the VPC and the Internet Gateway resources are fully created, they can't be successfully referenced. And so the Internet Gateway attachment can't be created because it references those other two resources until those other two resources move into a create complete state. So this implicit dependency feature works in most cases. In most cases we can allow Cloud Formation to determine this dependency for us. But there are some exceptions and one very common one which always seems to impact me when creating demos and one which always tends to feature in exams, hint hint, is this one.

This is that we want to create an elastic IP. So if you're creating an elastic IP and you want to associate it with a VPC that you're creating in the same template. So let's say that you're associating it with an EC2 instance running in a subnet inside a VPC. Then it actually requires an attached Internet Gateway. Otherwise you'll encounter issues. You might find that when creating stacks using templates sometimes it works or sometimes it doesn't. You might find when deleting stacks sometimes it works or sometimes it doesn't. Without formally declaring this relationship whether you can create an elastic IP depends on the random order that Cloud Formation creates these resources. So if the elastic IP attempts to create before the Internet Gateway attachment has been created then you will get an error. If you're deleting a stack and Cloud Formation attempts to delete the Internet Gateway attachment before deleting the elastic IP then you're also going to get an error.

Now what you can do to avoid all of these types of issues is to explicitly define a dependency and this is done using depends on as with this example. So we use the depends on key value. For the key we use depends on and for the value we specify the resource which this resource formally depends on. And so this creates an explicit dependency. The elastic IP will only be created after the Internet Gateway attachment has been completed and the elastic IP will be deleted before the Internet Gateway attachment is deleted. So using depends on establishes this formal or explicit dependency which ensures that resources are created, updated and deleted in the correct order. And this is something that's really essential to understand about Cloud Formation to avoid errors when creating larger templates or when studying an exam with an exam question in this area.

So it's definitely something that you need to understand going into any of the AWS exams and also if you're creating larger Cloud Formation templates. Now it depends on you can either specify a single resource as with this example or you can specify a list of resources if you want to create multiple dependencies. So keep that in mind. And again if you're working through any of my demos or advanced demos it's definitely worth the time to look through the underlying Cloud Formation templates and identify where I've put any depends on statements because that will help you understand exactly how this works for production and for exam questions.

At this point though that's everything I wanted to cover so thanks for watching. Go ahead complete this video and when you're ready I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover CloudFormation conditions. Now these are a useful feature of CloudFormation which allows a stack to react to certain conditions and change infrastructure which is deployed or specific configuration of that infrastructure based on those conditions. Now it's a simple feature but it provides a lot of flexibility for architects, developers or engineers. So let's jump in and step through exactly how it works and what features it provides.

So CloudFormation conditions are declared within an optional section of the template, the conditions section. Now you can define many conditions within the conditions section of the template and the end effect is that each condition is evaluated to be true or false. And these are processed before logical resources which are defined within a template, a processed by CloudFormation and physical resources are created to mirror those logical resources. So essentially the conditions section of a template is evaluated first and then based on those conditions any logical resources which use those conditions that influences what physical resources are created and how they're created. So these conditions use other intrinsic functions so AND = IF NOT AND OR and it uses these intrinsic functions to evaluate one or more things and then the result of those functions determines whether the condition itself is true or false. Any logical resources within a template can have a condition associated with them and the condition that's associated with them defines whether they're created or not. So if a condition that's associated with a resource is true then that logical resource is created. If a condition that's associated with a resource is false that resource is not created.

Now an example is you could have a parameter value on a template which accepted a number. Let's say 1, 2 or 3 and then we could create three conditions within a template. Let's say 1AZ, 2AZ or 3AZ and each of these conditions would use intrinsic functions to evaluate whether the parameter value was 1, 2 or 3. Now we could have many duplicate sets of resources defined within the CloudFormation template and certain of those resources would only be created if 2AZ was true and certain resources would only be created if 3AZ were true. We could also have conditions which react to the environment type parameter of a template. So based on whether the template was prod or dev we could control the size of instances created by a CloudFormation stack. So these are just two relatively common ways that conditions are used within a CloudFormation stack and a CloudFormation template.

Now let's take a look at how this looks visually and I'm going to step through a pretty simple example. So we have three major component parts. First we have a template parameter. In this example, EnvType. An EnvType can be dev or prod and it represents what the template is being used for. So development activities or production usage. Then also within the template we have a condition defined inside the conditions block of the template and this uses the equals intrinsic function to check if the value of the EnvType parameter is prod and if it is then this condition is prod is set to true. Finally conditions are used within resources of the template. In this case the word pressed to myEIP and myEIP2 resources they all reference this condition. And just before anyone provides feedback for anyone with a really keen eye these templates are not complete. So let's just refer to them as pseudo CloudFormation. They're cut down to only show what matters for this lesson.

The flow through this architecture would start with our developer Bob who would decide on a value of dev or prod for the EnvType parameter when applying it. So this would set that parameter value. Now the template as I've just mentioned has the conditions block which is evaluated first by CloudFormation before even considering the resources. So this evaluates to true or false. If the EnvType parameter in the template is prod then this condition evaluates to true otherwise it's false. Now the next stage is that the processing of the resources within the stack begins when processing the resources for any resources which use the isProd condition they're only created if the condition that they reference is true. So in this example if the isProd condition is false then only the wordpress resource is created. Because all of the other three have the condition which if it's false will cause those resources not to be created. Now if the isProd condition was true then wordpress2 would also be created so we'd have two EC2 instances and each of those would also be allocated with an elastic IP. So myEIP and myEIP2.

So just to reiterate this if a logical resource does not have a condition then it's created regardless. If a logical resource does reference a condition then that logical resource is only used so a physical resource is only created if that condition evaluates to true. If it evaluates to false then no physical resource is created for that corresponding logical resource. Now when you step through the flow of using these conditions they aren't actually that difficult to understand. You define a condition, you set it to true or false using one of the intrinsic functions and then you use that condition within resources in the template.

Now conditions can also be nested so you could have an isProd condition. You could also have another condition such as createS3 bucket and if this was true it would create the S3 bucket. And then you could have a condition which controls if a bucket policy is applied to the bucket and you could configure it so that that bucket policy would only be applied if a bucket is created and if that stack is a production stack. So you can nest conditions together and make a condition that evaluates to true only if two other conditions also evaluate to true and this nesting is done by using these intrinsic functions.

Now I'll be showing you lots of different examples of conditions in my demos and advanced demos that you'll find through all of my courses. So always make a habit as you do the demos to review the cloud formation templates which are used. So seeing these through practical examples will help improve your understanding. With that you'll be able to read templates and with more and more practice you'll find that writing them becomes much easier.

At this point though that's everything that I wanted to cover in this theory lesson about cloud formation conditions. Thanks for watching. Go ahead and complete this video and when you're ready I look forward to you joining me in the next.

Welcome back and in this video I want to talk about cloud formation outputs and outputs are optional within a template. Many don't have them but they're useful in providing status information or showing how to access services which are created by a cloud formation stack. Now this is going to be a really quick video so let's jump in and get started.

So the output section of a template is entirely optional. You can implement perfectly valid cloud formation templates without using an output section but if you do decide to include an output section then you can create outputs within that section. Essentially you can declare values inside this section which will be visible as outputs when using the CLI, they'll be visible as outputs when using the console UI and and this is a really important point they will be accessible from a parent stack when using nesting and these outputs can be exported allowing cross stack references.

Now outputs are not a complex topic and so I don't want to dwell too much on how they work because you'll be getting some practical experience in an upcoming demo video. Visually though this is how it might look if you're declaring a simple output. So in this example we're provisioning an EC2 instance which is running WordPress and this is an output within that template. So what we're doing is defining an output called WordPress URL and then we're defining two key value pairs description and value. So description is something which is visible from the CLI console UI and is passed back to the parent stack when nested stacks are being used. So you can always access the description and it's best practice to provide a description which makes this useful to anyone who might not have seen the template.

Now the second part is the value and the value is important. The value determines exactly what you want to be exposed by the cloud formation stack once the stack is in a create complete state. So in this case what we're actually doing is creating a value by joining two other things together. So we're using the join intrinsic function which I've covered in a different video and we're joining the literal string of HTTPS colon forward slash forward slash and the logical resource attribute of DNS name and this is how we can create a URL for accessing the service that's created by this cloud formation template. So we're using the join function to generate a simple string from two different things from HTTPS colon slash slash which is a literal string and then the attribute of the instance which is created elsewhere in this template. So the output will be HTTPS colon slash slash and then the DNS name of the instance and this will provide a method for anyone who's implementing this template to be able to access the service.

So that's everything I wanted to cover about cloud formation outputs. They're not all that complicated you'll be getting some practical experience in using them in an upcoming demo video and when I talk about cross stack references you'll see how we can extend this by exporting a particular output or set of outputs but at this point I want to keep things simple and that's everything that you need to be aware of when it comes to cloud formation outputs. So go ahead complete this video and when you're ready I look forward to you joining me in the next.

Welcome back and in this video I want to talk about CloudFormation mappings. And in keeping with the theme from the last few videos, this is also a feature of CloudFormation which makes it easier to design portable templates. Now this is going to be a fairly brief video so let's jump in and get started.

CloudFormation templates can contain a mappings object. Remember at a top level a YAML or JSON template is just a collection of top-level key value pairs. Now resources is one, parameters is one and now I'm introducing mappings as another. The mappings object can contain many mapping logical resources and each of these maps keys to values allowing information lookup. So you might use mappings to map the environment for example production to a particular database configuration or a specific SSH key. Now these mappings can have one level of lookup so you can provide a key and get a value back or they can have top and second level keys. A common example is a mapping of AMI IDs based on the top level key of region and the second level key of architecture.

Mappings use another intrinsic function which I haven't introduced yet called find in map and an example which I'll show next is the common use case which I just talked about using find in map to retrieve a given Amazon machine image ID for a particular region and a particular architecture. Now at this point the key thing to remember about mappings is that they help you, you guessed it, improve template portability. They let you store some data which can be used to influence how the template behaves for a given input. So let's have a look at a simplified example visually on the next screen.

Now this is an example of one mapping which is called region map which is in the mappings part of a cloud formation template and this is an example of the find in map function that you will use to lookup data using the mapping. Now to use a mapping it's actually pretty simple. First we have to use this find in map function and we need to specify a number of pieces of information to this find in map function. The first thing that we need to specify is the name of the mapping that we're going to use in this case region map. So this allows the intrinsic function find in map to query a particular mapping in the mappings area of the cloud formation template.

Now the next part this is mandatory we always need to provide at least one top level key. In this case we need to provide an item that we will use to lookup information from the mapping. Now in this case we're using a pseudo parameter. A WS double colon region will always resolve to the region that this template is being applied in to create a stack. So in this case let's assume that it's US - East - 1. Now the mapping to use and this top level key are the only mandatory parts of find in map and if we only provided these two then it would retrieve the entire object below US - East - 1 on this example. But in this case we're going to provide a second level key, HVM 64. And if we provide this as well it will perform a second level of lookup. Meaning in this case we will retrieve the AMI ID for US - East - 1 using the HVM 64 architecture.

So this is a simple example but it's a fairly common scenario where you use the mappings area of a template to store an AMI lookup table that you can use to retrieve a particular suitable AMI for a given AWS region and a given architecture. Now you could change this, you could use a particular AMI for a particular region and a particular application or a particular environment type. But you can perform one or two level lookups using find in map. Now again in a future video you're going to get the chance to experience this yourself in a demo video but for now I just wanted to introduce the theory, the architecture behind mappings.

So that's everything I wanted to cover in this video so go ahead, complete the video and when you're ready I look forward to you joining me in the next.

Welcome back and in this video I want to cover CloudFormation intrinsic functions. Up until this point everything that you've defined within a CloudFormation template has either been static or accepted using parameters. While intrinsic functions allow you to gain access to data at runtime, your template can take actions based on how things are when the template is being used to create a stack and that's really powerful. In this lesson I want to cover the theory of intrinsic functions but don't worry you'll be getting the chance to use them practically in an upcoming demo video so let's jump in and get started.

Now I want to quickly step through the functions that we're going to be looking at over the remaining videos of this CloudFormation series and then we can look at some of them visually and technically step through how they work. So first we're going to be looking at the ref and get attribute function or get at and these both allow you to reference a value from one logical resource or parameter in another one. If you create a VPC in a template and you want to make sure that another resource such as a subnet goes inside that VPC then you can reference the VPC within other logical resources. Next we've got join and split and these as the name suggests allow you to join strings together or split them up. An example usage might be is if you create an EC2 instance which is given a public IP version for DNS name then you can use the join function to create a web URL that anyone can use to access that resource. Next is get azs which can be used to get a list of availability zones for a given AWS region and the select function which allows you to select one element from that list and these two are commonly used together to pick an availability zone from the list of availability zones in one particular region.

Next are a set of conditional logic functions if and equals not and or and these can be used to provision resources based on conditional checks. So for example if a certain parameter is set to prod then deploy big instances. If it's dev then deploy smaller ones. Next is base64 and sub. Many parts of AWS accept input using base64 encoding. For example if you're providing EC2 with some user data for automated builds then you need to provide this using base64. So the base64 function accepts non-encoded text and its outputs base64 encoded text that you can then provide to that resource. Sub allows you to substitute things within text based on runtime information. So you might be passing build information into EC2 and you want to provide a value from the template parameters in which case sub can help you do that. And then next we've got sider which lets you build sider blocks for networking. It's a way to automatically configure the network ranges subnet used within a cloud formation template. Now there are others such as import value, find in map and transform and I'll be covering these in dedicated videos later in this series. Each one of these functions can be used in isolation or used together to implement some pretty advanced logic within templates.

Now let's take a look at how these work visually and technically and once again don't worry you will be getting the chance to use all of these practically in upcoming demo video. Two of the most common intrinsic functions within cloud formation are ref and get at meaning get attribute. It's important that you understand how these are used and the differences between the two. So let's use this as an example. A template with a logical resource which we're going to use to create a stack and this creates a physical resource in this case a t3.micro EC2 instance. Now every parameter and logical resource within cloud formation has a main value which it returns so for example the main value returned by an EC2 instance is its physical resource ID. The main value for a parameter logically enough is its value and the ref function can be used as the name suggests to reference this main value of a parameter or a logical resource. Now if you look at the cloud formation simplified example at the bottom left you will see next to image ID we're referencing latest AMI ID which is a parameter and that's how we can use parameters with logical resources by referencing them.

We can also use ref with logical resources as I just described so when an EC2 instance is created once it reaches a create complete state then it makes available a range of data. The primary value its physical ID can be accessed using the ref intrinsic function. Now there are also secondary values depending on the type of resource that you're deploying and these can be accessed using the get at function. With this function you provide the logical resource name and the name of an attribute and examples of this free EC2 might be the public IP address or the public DNS name of the instance. Ref and get at are critical. They're used in almost all cloud formation templates to access logical resource attributes, template parameters, pseudo parameters and much more. They'll be the key to evolving the non-portable template that you created in the previous demo video through to being a portable template so it's really important that you understand how both of these work.

Next I want to talk about the get azs function and the select function. Now these are often used together which is why I've included them on the same example. Get azs is an environmental awareness function. Let's say that we're deploying a template into US East 1 and let's assume this region has 6 azs, US East 1A, 1B, 1C, 1D, 1E and 1F. Now if you wanted to launch an EC2 instance into one of these azs you would need to know its name. Basically you would need to know a list of names for all of the valid azs in that region and then you would need to pick one. Remember from the previous demo video we're trying to ensure that our templates are portable so hard coding, availability zone names is a bad practice. What you can do is use the get azs function and with this you can either explicitly specify a region, you can use the region pseudo parameter or you can leave it blank and then it will use the region currently being used to create the stack. What it will do is return a list of availability zones within that region.

There is a little nuance here though under normal circumstances it should return a list of all the azs in that region but what it actually does is to return a list of all azs within that region where the default VPC has subnets in that az. Now normally these are one and the same but if you have a default VPC where you've deleted subnets then the list that you're going to get back is not going to have all available azs. So if you don't have a default VPC or if you have the default VPC in its form where it does have subnets for all azs in that region then it will return a list of all available azs within that region. But if you have a badly configured default VPC then you might get some inconsistent results. But having this dynamic list of availability zones is really powerful because then you can use the select function to select a numbered one from that list. Now select accepts a list and an index starting at zero which returns the first object in that list. So it allows you to dynamically refer to azs in the current region without explicitly stating their identifiers which makes templates much more portable. It's one part of ensuring that templates can be applied to all regions without having issues and it's something that you're going to get experience of very soon in the next demo video.

Now I'm going to start moving through the rest of these much faster because some of these intrinsic functions are much more situational and you're going to get experience of them as we move through this series of videos. Next we have the join function and the split function. Now split accepts a single string value and a delimiter pipe in this example and it outputs a list where each object in the list is part of the original split. So in this example we provide split with a single string, ruffle pipe, truffles pipe, penny pipe, winky and we get as an output a list where each object in that list is one of those cat names which can be referenced individually. Now join is the reverse of this. You provide a delimiter and a list of values and the join function joins them together to make a string. In this case we're creating a web URL for a WordPress EC2 instance by combining https// and the DNS name of the instance and note how that's obtained with the get at function which I've just covered.

Okay so moving on, next we have base64 and sub. Now this is an example of user data which I'm going to be covering soon. Essentially it's a script that you provide to instances which allow them to perform auto configuration. Now this user data needs to be provided using base64 encoded text but as you can see this isn't the case. It's simply using plain text. The base64 function accepts normal text and it encodes it and then passes the output which is base64 into an instance which is the format that that instance needs. So if you're operating with any AWS resources which require base64 then you can use this function, provide the function with some normal text and it will output the base64 encoded text that you need. Now the substitute or sub function allows you to do replacements on variables. So for example this is a variable. This is the instance ID attribute of the instance logical resource. By putting it in this format so dollar, curly bracket, variable name, close curly bracket the sub function will replace it with the actual runtime value, the instance ID.

Now there are some restrictions. You can't do self references. So in this case this user data could only reference the instance ID of another instance. This example is actually an invalid one which I wanted to show you visually. The formatting is correct but it actually shows a self reference. How can we pass in an attribute of a physical instance before the physical instance is created? So this is not valid but during an upcoming demo video I'm going to be covering how to use these effectively and you're going to get plenty of practical experience of using the sub function within your own cloud formation templates. Now the format of using things in substitutions is either the left one for a parameter, the middle one for the primary value of a resource and this is like using the ref function and the right is the format for using attributes. The logical resource name and then the attribute name and again don't worry you're going to get plenty of practical experience of using this in an upcoming demo video.

The last function I want to talk about is actually a really cool feature of cloud formation which makes networking much easier. So when you're creating VPCs you have to provide a side arrange for the VPC to use. Inside that side arrange you've historically had to manually assign rangers for the sub nets inside that VPC. With this function you can use it to reference the side arrange in this example of a VPC. You can tell it how many sub nets you want to allocate and then finally you can tell it the size of those sub nets and from that it will output a list of side arrangers which you can use within sub nets within a VPC and you can combine this with the select function to allocate those to sub nets individually. So in both of these examples sub net one and sub net two what we're doing is we're using the side function, we're passing it the side arrange of the VPC, we're telling it we want 16 ranges in total and we're giving it the size for those ranges. Both of them output a list of possible ranges to use and we're selecting the first one so index zero for sub net one and the second one so index one for sub net two. And this is an example of how we can assign side arrangers to sub nets in a more automated way. It assists again in making templates more portable by auto assigning things. Now it does have its limitations, it's all based on the parent VPC side arrange and it can't allocate or unallocate ranges but luckily I'm going to show you some really cool techniques how you can fix that in later videos of this series.

Now at this point that's everything I wanted to cover, I wanted to quickly go through some common intrinsic functions that you might use while you're creating cloud formation templates. Now very soon there's going to be another demo video where you're going to get some practical experience to all of the theoretical concepts that I've been talking about in this block of theory videos. So don't worry we start with a theory, we make sure that you're entirely comfortable with that and then you'll get the opportunity to practice that in a demo video. Now that's everything that I wanted to cover in this video so as always please go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this video I want to talk about template and pseudo parameters, two types of parameters which can be used within CloudFormation templates and which can influence logical resources within those templates. Now we've got a lot to cover so let's jump in and get started.

Parameters both template and pseudo parameters allow input. They let external sources provide input into CloudFormation. For template parameters this means that the human or automated process can provide input via the console, CLI or API when a stack is created or updated. An example of this might be the size of the instance or the environment that the template is for, so for example dev, test or prod.

Now parameters are defined inside a template along with the resources and the values for those parameters can be referenced within logical resources also within that template which allows them to influence the physical resources and/or the configuration of those physical resources when a template is used with a stack to provision AWS resources. For every parameter that you define in a template you can provide configuration for that specific parameter. You can define defaults for it so if no value is explicitly provided then that default applies. You can define allowed values so maybe a list of instance types which are valid for the template. You can define restrictions such as the minimum and maximum length or even allowed patterns. You can also define the parameter as using no echo which is useful for passwords where you don't want the input to be visible when it's being typed. And then finally each parameter can have a type. You have simple ones like string, number or list but you also have AWS specific ones which allow you to specify a VPC from a list or subnets from a list and some of these can be populated so from the console UI perspective they're interactive based on the region and the account that you're applying the template within.

Now you're going to be getting some practical experience of working with parameters in a future demo video. For now I just want you to have a basic awareness.

Now visually parameter architecture looks like this. Parameters start by being defined within a cloud formation template and let's use this as an example. I've defined two parameters here so instance type which is a string and it has a default of t3.micro together with a set of three allowed values. I've also provided a description which makes it easier to use from the console UI and then second we have instance AMI ID which is a normal string type parameter with no allowed values so this is simple free text.

Now this example is part of a wider template which includes an EC2 logical resource so if we load this into cloud formation via the console UI then this is what we might see a user interface presentation of those parameters. At this stage we enter values or we accept the default values and we move through the process of creating the stack. Conceptually this means that the template defines things based on the resources declared within it and the interactive values provided via the parameters so both of these are combined and are used to create the stack. It means that the stack creates physical resources based both on the logical resources and the effect on them which the parameters have. In this case based on the parameter values we would create an instance with one of three sizes and use a certain Amazon machine image.

Now most of this applies to both template and pseudo parameters. The thing unique to template parameters is that the personal process provides the values into cloud formation either explicitly or by implicitly accepting the defaults. Pseudo parameters can be treated in the same way but they're provided by AWS so let's have a look at that visually.

Now we start off with a familiar architecture a cloud formation template is used to create a cloud formation stack. The template could be using the template parameters I've just been talking about. You don't have to pick one type over the other. Template and pseudo parameters can be used in a complementary way. With pseudo parameters what happens is that AWS make available parameters which can be referenced and these exist even if you don't define them in the parameters section of the template. So conceptually think of these as being injected by AWS into the template and stack.

Now an example of a pseudo parameter is AWS double colon region and the value of this parameter always matches whichever region a template is being applied in to create a stack. In this example US - East - 1. Other pseudo parameters include AWS double colon stack ID which matches the unique ID of the stack, AWS double colon stack name which matches the name on the stack and AWS double colon account ID which is populated with the account ID of the account that the stack is being created in. So pseudo parameters think of them like template parameters but instead of being populated by a human or a process when creating the stack they're populated by AWS.

Now both types of parameters are useful in ensuring that a template is portable and can adjust based on input from the person or process creating the stack. Static templates are much less flexible and this functionality goes a long way to removing the negative aspects of static templates. From a best practice perspective you should aim to minimize the number of parameters which you have which require explicit input. Now this means wherever possible using defaults and where possible getting values from AWS rather than whoever is implementing the stack.

In the videos which follow as well as learning more about the features of cloud formation which help with template portability you're going to get the chance to experiment with all of those features in some demos. I'm introducing the theory first and then you'll get the chance to experience it yourself. Now with that being said that's everything that I wanted to cover in this video so go ahead and complete the video and when you're ready I look forward to you joining me in the next.

Welcome back and in this video I want to cover two things which are at the core of CloudFormation as a product - physical resources and logical resources. In covering both of those you're also going to be learning about templates and stacks, so this will be a good video to cover the basics of CloudFormation. Now we've got a lot to cover so let's jump in and get started.

CloudFormation begins with a template which is a document written in either YAML or JSON, both of which you should now have an awareness of. Defined within a CloudFormation template are logical resources. Think of logical resources as what you want to create but not how you want them created. When using CloudFormation you focus on the what and let CloudFormation deal with the how.

CloudFormation templates can be used to create CloudFormation stacks. A template can be used to create one stack, a hundred stacks or twenty stacks in different regions. The idea is that one template defines what resources you want, and defining good templates means a template can be used many times in many accounts in many regions. We refer to that as a portable template.

The initial job of a stack is to create physical resources based on the logical resources defined within the template. For every logical resource in a template when a stack is created a physical resource is also created. If a stack's template is updated in some way and then the stack itself is updated the physical resources are also changed. The stack keeps the logical and physical resources in sync. If a stack is deleted then normally the physical resources are also deleted. So think about CloudFormation as a product which looks at a template specifically the logical resources within a template, and then it creates, modifies or deletes physical resources as required.

So visually it looks like this. This is a CloudFormation template and this one has been written using YAML. The template contains logical resources. In this example instance is the name of the logical resource and this is the type, so AWS double colon EC2 double colon instance. Now logical resources are generally going to have properties which are used by CloudFormation when configuring the actual physical resources. In this example this sets the Amazon machine image to use, the type of the instance and the SSH key pair to use when connecting to the instance.

So the collection of logical resources and other things which I'll be covering in future videos is called a CloudFormation template. This template can be used to create one or many CloudFormation stacks, and a stack when created also creates physical resources based on the logical resources. This means because we've set the AMI to use in the template and the SSH key to use these will be used when creating the physical resource, in this case an EC2 instance. So this physical EC2 instance is a representation of the logical resource defined in the CloudFormation template.

Now the stack will also react to template changes to update or delete physical resources as required. Once a logical resource defined inside the CloudFormation template moves into a create complete state, meaning that the physical resource has been created, then the logical resource can be referenced by other logical resources to retrieve various physical configuration elements or IDs, for example in this case the physical machine ID of the EC2 instance.

So in summary logical resources are contained inside CloudFormation templates. CloudFormation templates are used to create CloudFormation stacks and the stacks job is to create, update or delete physical resources based on what's contained in that template. CloudFormation as a product aims to keep the two in sync, so physical and logical resources.

When you use a template to create a stack, CloudFormation will scan the template and create a stack with logical resources inside and then create physical resources which match those logical resources. If you update the template then you can use it to update that same stack. When you do that the stack's logical resources will change, either new logical resources will be added or existing ones are updated or deleted and CloudFormation will perform the same actions on the physical resources. So adding new ones, updating existing ones or removing physical resources entirely. If you delete a stack its logical resources are also deleted which causes it to delete the matching physical resources.

CloudFormation is a really powerful tool which you'll be using extensively in the real world and this is the same whether you're a solutions architect, a developer or an engineer. I use CloudFormation constantly in all of the AWS courses that I create and so by taking the courses you'll be gaining a lot of practical and theory understanding of how CloudFormation works.

Now if you're taking any of my courses with my CloudFormation mini deep dive then you'll be learning even more by talking about every important aspect of CloudFormation that's relevant for the course that you're taking as well as giving you plenty of practical examples. CloudFormation lets you automate infrastructure. Imagine that you host WordPress blogs. You can use one template to create one, ten, a hundred or more deployments rather than having to create a hundred individual sites.

CloudFormation can also be used as part of change management. You can store templates in source code repositories, add changes and get approval before applying them. Or they can be used to just quickly spin up one-off deployments and if you're taking any of my AWS courses you'll be seeing that I'll be using CloudFormation extensively as part of any of the practical demo lessons in the course. We'll be using templates to spin up any of the infrastructure that will support the demo lesson that you're going to be taking.

Now that's all of the theory that I wanted to cover about physical and logical resources within CloudFormation. It is a fairly theoretical topic but you need to understand what a physical resource is, what a logical resource is and how the two relate together as far as they're used within CloudFormation. Now at this point that's everything that I wanted you to cover in this video so go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk briefly about Amazon Guard Duty. Now this is something which you only need detailed knowledge of for the security specialty stream of training. Now I'll try to keep this lesson as efficient as possible so let's jump in and get started.

Now it's important at the outset that you know what Guard Duty is and what makes it special. So it's a security service but specifically it's a continuous security monitoring service. This means once enabled it's running all the time trying to protect your account and resources from any security issues. Now the way that it works is that it can be integrated with supported data sources and I'll talk about this more on the next screen. It's constantly reviewing those data sources for anything occurring within the account and it also uses artificial intelligence and machine learning plus threat intelligent feeds.

Now the aim of the product is to identify any unexpected or unauthorized activity on the account. Guard Duty is doing this in an intelligent way so you aren't having to identify things you usually do or define what normal activity is. It attempts to learn this on its own and using threat intelligence feeds it tries to spot odd or worrying activity as it occurs on the account. Now you can influence this so white listing IPs and influencing what it sees as okay behavior but the whole point of the product is that on the whole it learns patterns of what happens normally within any managed accounts.

Now if it finds something which logically is called a finding then it can be configured to notify somebody or initiate an event driven process of protection and/or remediation. This might be a lambda function performing some kind of remediation or an event driven workflow via cloud watch events but Guard Duty can be part of an automatic event driven security response and that's really cool. What's even more awesome is that it actually supports multiple accounts via a master and member account architecture. When you enable Guard Duty you're essentially making the account that you enable it in the master Guard Duty account and then you can invite other AWS accounts and if they accept they become member Guard Duty accounts meaning the product supports a single location for managing multiple AWS accounts.

Now architecturally the product looks like this. First we have Guard Duty and Guard Duty receives logs from supported data sources. At the time of creating this lesson this includes DNS logs from Route 53 showing DNS requests, VPC flow logs showing traffic metadata for any traffic flowing through a VPC, cloud trail event logs showing any API calls within the account, cloud trail management events which cover any control plane level events and then finally cloud trail S3 data events which cover any interactions with objects within S3. Now all of those are ingested together with various threat intelligent feeds and are used to generate findings which show any unusual or unexpected behavior.

These findings can be sent to cloud watch events now known as event bridge which can be used to handle event driven notification and automatic remediation. So event bridge can use S&S for notifications to any team members or external security management systems or it can invoke Lambda functions which can interact with AWS APIs, products and services to help automatically remediate any security issues maybe to add an explicit deny rule to a network ACL if there's a potential intrusion.

Now that's pretty much all you need to know for the exam and to get started using the product in the real world. Now thanks for watching go ahead and complete this lesson and then when you're ready I'll look forward to you joining me in the next.

Welcome back and in this video I'm going to be talking about Amazon Inspector. Now this is a service which is really simple to use and it only features in a relatively minor way on most of the AWS exams. So this is a fundamental video. If appropriate for the course that you're taking, I'll be going into much more detail in separate videos. For this video you just need to have a basic awareness of what this product does and how to use it effectively.

Now nearly all of my lessons contain visuals because I find this helps students to learn better. But in this case Inspector is just one of those services which is easy to understand but very detailed in terms of what it does. And unfortunately this means it's going to be a text heavy lesson. So let's jump in and get started.

Amazon Inspector is a product designed to check EC2 instances, the operating systems running on those instances as well as container workloads for any vulnerabilities or deviations against best practice. The idea is to run an assessment of varying lengths, say 15 minutes, 1, 8 or 12 hours and even 1 day and identify any unusual traffic or configurations which put applications on the instances, the instances themselves or containers at risk. Now at the end of this process the product will provide you with a review of findings ordered by severity. In the exam if you see anything about a security report then think Inspector. But remember it's checking instances, their operating systems, containers and any other networking components involved.

Now Inspector can work with two main types of assessments. A network assessment can be conducted without using an Inspector agent but adding an agent provides additional richer information. It can also run a network and/or host assessment which does use an agent. The host assessment looks at OS level vulnerabilities and this needs access to inside of the instance, so the instance OS and this requires an agent.

With Inspector rules packages determine what is checked. The first package, network reachability which can be done with no agent or with an agent for additional rich information. This checks how an instance or group of instances is exposed to public networks, so it checks end-to-end reachability. So EC2, application load balancers, Direct Connect, elastic load balancers, network interfaces, internet gateways, access control lists, route tables, security groups. It even checks subnet and VPC configuration and even exposure from virtual private gateways and any VPC peering.

The network reachability rules package returns the following types of findings. First, for recognized ports, so well-known ports, it confirms if the port is recognized with a listener, i.e. is it exposed to the public networks and is the operating system listening on that port, or recognized port no listener where it's exposed to the internet but with nothing listening, or if you don't use an agent, a recognized port which is exposed but there is no agent to check if the operating system is listening, and this is why using an agent always adds more information versus no agent. Now lastly, it can identify any unrecognized ports which are exposed with listeners.

So for the exam, this is what the network reachability rules package does. You might see that term, you need to know what it does, or it might request you to suggest a product which can do this type of analysis and then question whether an agent is required. And so these are all key points to understand.

We also have rules packages which do require an agent, so host assessments, and all of these are really, really important to remember for the exam. These are pure keywords, so easy to remember but massively important. First, there is the common vulnerabilities and exposures or CVE package, and CVE is a database of known cyber security vulnerabilities, each of which is assigned a CVE number, and this package checks against those. If you see CVE in the exam, think Inspector. And a report will include any CVE IDs for anything found on the instances or containers.

Next, we have the Center for Internet Security or CIS Benchmarks. The formal definition is the CIS Security Benchmark Program provides well-defined, unbiased, consensus-based industry best practices to help organizations assess and improve their security. This rules package checks against that. So again, if you see CIS as an exam question, think Inspector.

Then finally, we have Security Best Practices for Inspector, which is just a collection of best practices provided by Amazon, including things like disabling root login over SSH, using only modern version numbers for SSH, password complexity checks, and permissions on certain folders. Again, if you see anything of this nature in the exam, think Inspector.

And that really is everything that you need to know at this fundamental level for this product. Again, if you're studying for a particular exam which requires more information, I will have additional videos covering everything else in depth. This is just a fundamental 101 level lesson.

Now, you'll know by now I do hate teaching based on just keywords, but this is one of those outliers where you don't really need to know all of the details. But I don't want you dropping exam marks because you don't know any of these really valuable keywords. And again, I'm just going to repeat this one more time. If applicable for the course that you're studying, I'll be covering Inspector in much more detail in other dedicated lessons.

For now, though, that is everything I wanted to cover. So go ahead and complete this video. And when you're ready, I'll look forward to you joining me in the next.

Welcome to this lesson where we're going to be covering Amazon Macie. Now we have a lot to cover so let's jump in and get started.

So what is Macie? Well, it's a data security and data privacy service. You'll understand now the architecture of the simple storage service known as S3. It's one of AWS's most popular services and it can host huge quantities of large or small objects at scale. It can also be made public and for some time it's been a constant source of risk within organizations because of the fact that data can be leaked if the service is misconfigured. So Macie is a service which can be used to discover, monitor and protect data which is stored within S3 buckets.

It's critical if an organization wants to control the security of its data that it needs to have an awareness of where that data is and what exactly it contains. So once enabled and pointed at buckets within your AWS account or AWS accounts, Macie can get to work discovering data and this might mean data which is classed as personally identifiable information or PII or personal health information known as PHI as well as financial data and many other types of data. Now these high level categories include a huge range of data which you personally will have day to day familiarity with. Things like AWS access keys, SSH keys, PGP keys or bank account numbers, credit card numbers or expiry dates, health insurance numbers, birth dates, drivers license numbers, national insurance numbers, passport numbers, addresses and much more. It's the first job of Macie to identify and inventory this data. So by using Macie you'll know what you have, what it contains and where it is.

Now the way that it does this is using data identifiers. Think of these like rules which your objects and their contents are assessed against and there are two types of data identifiers. Managed data identifiers and custom data identifiers. Now managed data identifiers are built into the product. They use a combination of criteria and techniques including machine learning and pattern matching to analyse the data that you specify. They're designed to detect sensitive data types for many countries and regions including multiple types of personally identifiable information, personal health information and financial data. And this type of identifier can be used to detect almost all common types of sensitive data that you might need to manage within your organisation.

Now you can also build custom data identifiers for your business. These are proprietary so you can look for specific data which your business needs to identify and control. An example you might use a regular expression known as a reg X to search for certain patterns of specific text within your business. Maybe employee IDs or performance reports. With Macy you create discovery jobs which use these identifiers and look for anything matching on buckets. If anything is found these jobs generate findings and you can view these findings interactively or they can be used as part of integrations with other AWS services. For example security hub or finding events can be generated and passed into EventBridge and then they can be used for automatic event driven remediation. So it's a super powerful architecture.

Now one final thing which you need to understand before we review the architecture visually is that Macy uses a multi account architecture. One account is the administrator account and that can be used to manage Macy within member accounts. And this multi account structure can be done either using AWS organisations or by explicitly inviting accounts. And once invited buckets across all accounts within the Macy organisation can be evaluated in the same way.

Now let's just take a second to review the architecture visually. We start with one or more S3 buckets and then the Macy service itself and then we create a discover job. And within the discover job we can specify which buckets we want to analyse which means detecting and classifying data within those buckets. The discovery job has a schedule so this controls when it runs and how frequently it runs and then the job uses a combination of managed data identifiers and custom data identifiers. And these are the things which actually identify and classify the types of data that Macy is locating. So it's these things which are the important part of the whole process.

Now as an output to the discovery job findings are generated and these can be viewed either using the console interactively or and this is the more common use case. They can be used with a vent bridge in the form of event findings generation which can then be delivered to other AWS services. And this is commonly used for integration or for event driven remediation in this example where a Lambda function can receive the event and can perform some kind of automatic fix based on the finding. So at a high level that's how the architecture looks.

And before we finish up with this lesson I want to explore a number of other important elements of the service and we're going to start with looking in more detail at the managed and custom data identifiers. To discover sensitive data within Amazon Macy you create and run data discovery jobs. A data discovery job analyzes objects within S3 buckets to determine whether the objects contain sensitive data. And the way that it does this is via data identifiers.

First we have managed data identifiers and these are created and managed by AWS. And as I mentioned earlier in this lesson they can be used to identify a growing list of sensitive data types. Now I've included a link attached to this lesson which details the full range of data which is matched by this type of identifier. But it's things like various credentials, financial data, credit cards, bank details and more. Things like health data or anything personally identifying such as addresses, passports, drivers licenses and much much more. It's a pretty comprehensive list so it's worth checking out the link that's included with this lesson which gives a full overview.

In addition to this anyone can create custom data identifiers. Now the foundation of these are regular expressions which define a pattern to match within data. This one for instance matches any data which contains the letters A through to Z and then a dash and then eight digits. Anything that you can define using regular expressions you can match using custom data identifiers. And these are generally used for data patterns which are custom to your organization as with this example of an employee ID. You can optionally add keywords to custom data identifiers which must occur within a definable proximity to the pattern matched by the regular expressions. And this definable distance is called the maximum match distance. And then finally you can also include ignore words. So if the regex match is something but an ignore word is there in addition it's ignored and doesn't match. So keywords, maximum match distance and ignore words are all refiners. They help you start with a regex pattern but influence how something is classified based on those refinements.

So these identifiers run in addition to built in checks that Macy performs and then findings are generated. And Macy will produce two types of findings. Policy findings and sensitive data findings. Macy generates policy findings when the policies or settings for an S3 bucket are changed in a way that reduces the security of the bucket or its objects but crucially after Macy is enabled. For example if the default encryption on a bucket was enabled when you enabled Macy and then default encryption is later disabled on that bucket then this is highlighted as a policy finding. So that's an example of a policy finding.

Macy generates the other type of finding which is a sensitive data finding when it discovers sensitive data in S3 objects that you configure it to analyze. And it determines what is sensitive data based on the jobs and identifiers which you configure and which I've just stepped through. So some examples of policy findings are S3 block public access disabled which is triggered if the block public access settings on a bucket are disabled. Another is S3 bucket encryption disabled which is triggered logically when encryption on a bucket is disabled. Another is S3 bucket public which is triggered when a bucket policy or ACL changes are made which make a bucket public and another is S3 bucket shared externally and this is triggered when a bucket policy or ACL allows an AWS account other than those within the Macy organization access to this bucket. So these are all policy changes which Macy decides reduce the security of a bucket or objects in that bucket and so trigger policy findings.

So these are called policy findings and there are more of these and I've included a link attached to this lesson which details all of them and that's really worth a look through just to become familiar with all of the different things that Macy can identify. Now examples of sensitive data findings include these and it's worth pointing out that there are many more of them. Again I've included a comprehensive list which is attached to this lesson but for now let's just focus on these important examples.

First we have S3 object credentials and this matches any exposed SSH keys or AWS access keys that Macy can locate. We've also got S3 object custom identifier and this matches anything defined within custom data identifiers. We have S3 object financial which matches credit card numbers or bank account numbers and much more. We have S3 object multiple which occurs when more than one thing is identified. We have S3 object personal which covers personally identifiable information such as full names, mailing addresses, personal health information such as health insurance or medical identification numbers or combinations of those. Now this isn't an exhaustive list. Again I've included a link attached to this lesson which gives you a full overview.

And that at a high level is Macy. It's a useful tool which you'll need to understand for the exam. If you see any questions regarding the classification of data within S3 so identifying data, discovering data or reacting to sensitive data automatically then Macy is probably the product to use.

Now that's everything I wanted to cover within this theory lesson. If you're doing any of my courses where practical knowledge of Macy is required then there's going to be a demo lesson immediately following this one. If not then this theory is all that you'll need. So at this point this is the end of the lesson. Thanks for watching. Go ahead and complete this video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about AWS config. Now let's just jump in and get started because we've got a lot to cover.

AWS config is an interesting service because people often misunderstand what it does. This is especially important within exam situations where you don't have the benefit of Google and have to make architectural decisions quickly.

Now AWS config has two main jobs. Its primary function is to record changes over time on resources within an AWS account. Once enabled, the configuration of every resource in the account is monitored. Every time a resource's configuration changes, a configuration item is created which stores the configuration of that resource at a specific point in time. The information which is stored is the configuration of the resource, the relationship to other resources and who makes any changes. So for example, if you had a security group attached to an instance and you added a rule to that security group, then it would track the pre-change state, the post-change state, the fact that you changed it and the fact that it was attached to that EC2 instance.

Now this makes AWS config great for auditing changes and for checking if resources are compliant with standards defined by your organization. The most important thing to understand about AWS config is that it doesn't prevent changes happening. It's not a permissions product or a protection product. Even if you define standards for resources, it can check compliance against those standards but it doesn't prevent you from breaching those standards and creating non-compliant resources. An example of compliance might be a certain set of allowed ports within security groups. You can add additional ports exposing an instance to a certain amount of risk. Now AWS config won't stop you but that non-compliance, that additional port will be identified.

Now config is a regional service so when enabled it monitors changes within a particular AWS region in a particular AWS account but it can be configured for cross-region and cross-account aggregation. It can also generate notifications via SNS and it can generate events via EventBridge and Lambda when resources change in terms of their compliance state so while AWS config won't prevent you changing something it can be used for automatic remediation.

Now the product stores all of the configuration data and changes in a consistent format within the S3 config bucket and the product allows you to access that data so all of the configuration history of all of the resources and you can interact with them directly from that bucket or using the AWS config APIs.

Now there are two sides to AWS config, the features which are standard and the parts of the product which are optional. Now the standard part is on the left and the optional part is on the right. So starting on the left we have some account resources and we have AWS config. To use the product we have to enable it and this enables the recorder functionality and this takes config information of all the resources and stores them in an S3 bucket, the config bucket and this is all part of the standard functionality provided by the product.

Now you could just enable all of this functionality and leave this as it is. This would allow you to record and review all changes to resources over time. Every time a change happens a configuration item would be generated and all of these for all resources would be stored in a standard format in the config bucket.

But we can do a lot more with the product and this is where the real power of AWS config comes from because we can use config rules. Now config rules are either AWS managed ones or you can define your own which uses Lambda. What happens is that these rules evaluate resources against a defined standard. Resources based on these rules are either compliant or non-compliant based on if they meet criteria specified within the config rule. Now custom rules use Lambda to evaluate if resources match criteria. The Lambda function does the evaluation using whatever things that you can code and then returns information back to AWS config.

AWS config can then notify or work with other products for automatic remediation. For example, it can use SNS to send either a stream of changes or compliance notifications and these will either go to human operators or other applications to deal with. In addition though you can integrate AWS config with EventBridge. So for any changes in the state of config rules whenever anything becomes compliant or non-compliant this event can be sent to EventBridge and then EventBridge can be used to invoke Lambda functions to perform automatic remediation of any changes. So to fix the problems automatically.

Now this isn't strictly part of AWS config. You're essentially using EventBridge to send any events from AWS config to targets to perform this automatic remediation. You can also fix these type of config changes using SSM. So AWS config can integrate with systems manager and apply fixes to remediate any issues. But Lambda can be more flexible for account level things whereas SSM can be effective for anything relating to the configuration of instances.

Now that's all of the theory that I wanted to cover in this lesson. Go ahead and complete this lesson and then when you're ready I look forward to you joining me in the next lesson.

Welcome back and in this lesson I want to talk about CloudHSM. Now this is a product which is similar to KMS in terms of the functionality which it provides, in that it's an appliance which creates, manages and secures cryptographic material or keys. Now there are a few key differences and you need to know these differences because it will help you decide on when to use KMS and when to use CloudHSM. And you might face an exam question where you need to select between these two. So let's jump in and get started.

Now I promised you at the start of the course I wouldn't use facts and figures in lessons unless absolutely required. You shouldn't have to remember lots of different facts and figures unless they influence the architecture. Now this unfortunately is going to be one of the lessons where I do have to introduce some keywords that you simply need to remember. Because in this lesson the detail, the difference between CloudHSM and KMS really matters.

Now let's start by quickly talking about KMS. KMS is the key management service within AWS. So it's used essentially for encryption within AWS and it integrates with other AWS products. So it can generate keys, it can manage keys, other AWS services integrate with it for their encryption. But it has one security concern, at least if you operate in a really demanding security environment. And that's that it's a shared service. While your part of KMS is isolated, under the covers you're using a service which other accounts within AWS also use. What's more, while the permissions within AWS are strict, AWS do have a certain level of access to the KMS product. They manage the hardware and the software of the systems which provide the KMS product to you as a customer.

Now behind the scenes KMS uses what's called a HSM which stands for Hardware Security Module. And these are actually industry standard pieces of hardware which are designed to manage keys and perform cryptographic operations. Now you can actually run your own HSM on-premise. Cloud HSM is essentially a true single tenant HSM that's hosted within the AWS cloud. So if you hear the term HSM mentioned, it could refer to both Cloud HSM which is hosted by AWS or an on-premise HSM device.

Now specifically focusing on Cloud HSM, AWS provision it and they're responsible for hardware maintenance. But they have no access to the part of the unit where the keys are stored and managed. It's actually a physically tamper resistant piece of hardware. So it's not something that they can gain access to. Generally if you as the customer lose access to a HSM, that's it, game over. You can reprovision them but there's no easy way to recover data.

Now there's actually a well-known standard for these cryptographic modules. It's called the Federal Information Processing Standard Publication 140-2. You can easily determine the capability of any HSM modules based on their compliance with this standard. And I've included a link in the lesson description with additional information. But Cloud HSM is FIPS 140-2 Level 3 compliant and it's the Level 3 which really matters in the context of this lesson. KMS in comparison is overall 140-2 Level 2 compliant and some of the areas of the KMS product are also compliant with Level 3.

Now this matters. This is really important. If you see an exam question or if you're in a real world production situation which requires 140-2 Level 3 overall, then you have to use Cloud HSM or your own on-premises HSM device. And that's a fact that you really need to remember for the exam.

Another important distinction between KMS and Cloud HSM is how you access the product. With KMS, all operations are performed with AWS standard APIs and all permissions are also controlled with IAM permissions. Now Cloud HSM isn't so integrated with AWS and this is by design. With Cloud HSM, you access it with industry standard APIs. Now examples of this are PKCS 11, the JCE extensions or the CryptoNG extensions. And I've highlighted the keywords that you should try to build up an association with Cloud HSM. So if you see any of these keywords listed in the exam or in production situations, then you know you need a HSM appliance, either on-premise or Cloud HSM hosted by AWS.

Now it used to be that there was no real overlap between Cloud HSM and KMS. They were completely different. But more recently, you can use a feature of KMS called a custom key store. And this custom key store can actually use Cloud HSM to provide this functionality, which means that you get many of the benefits with Cloud HSM together with the integration with AWS. So when you're facing any exam questions, you still should be able to look for these keywords to distinguish between situations when you use KMS versus Cloud HSM.

Now just to summarize before we move on from this screen, I want you to focus on doing your best to remember all of the three key points that are highlighted with the exam power-up icon. If you can remember those, then you should be in a really good position to determine whether to use KMS or Cloud HSM within exam questions. Now I want to look at the architecture of Cloud HSM as a product, and I think it's best that we do that visually.

Now architecturally, Cloud HSMs are not actually deployed inside a VPC that you control. They're deployed into an AWS managed Cloud HSM VPC that you have no visibility of. So architecturally, this is how that looks. So on the left, we've got a customer managed VPC. On the right, we've got the Cloud HSM VPC that's managed by AWS. We're using two availability zones, and inside the customer managed VPC, we've gone ahead and created two private subnets, one in availability zone A and one in availability zone B.

Now inside the Cloud HSM VPC, to achieve high availability, you need to deploy multiple HSMs and configure them as a cluster. So a HSM by default is not a highly available device. It's a physical network device that runs within one availability zone. So in order to provide a fully highly available system, we need to create a cluster and have at least two HSMs in that cluster, one of them in every availability zone that you use within a VPC.

Now once HSM devices are configured to be in a cluster, then they replicate any keys, any policies, or any other important configuration between all of the HSM devices in that cluster. So that's managed by default, by the appliances themselves. That's not something that you need to configure. So the HSMs operate from this AWS managed VPC, but they're injected into your customer managed VPC via elastic network interfaces. So you get one elastic network interface for every HSM that's inside the cluster injected into your VPC. Once these interfaces have been injected into your customer managed VPC, then any services which are also inside that VPC can utilize the HSM cluster by using these interfaces. And if you want to achieve true high availability, then logically instances will need to be configured to low balance across all of the different interfaces.

Now also in order to utilize the cloud HSM devices, then a client needs to be installed on the EC2 instances, which are going to be configured to access the cloud HSM. So this is a background process known as the cloud HSM client. And this needs to be installed on the EC2 instance in order for it to access the HSM appliances. And then once the cloud HSM client is installed, then you can utilize industry standard API's such as PK, CS11, JCE and crypto NG to access the HSM cluster.

Now a really important thing to understand about cloud HSM, because this is a distinguishing factor between it and KMS, is that while AWS do provision the HSM, they're actually partitioned and they're tamper resistant. So AWS have no access to the area of the HSM appliances which store the keys. Only you can control these. You manage them, you're responsible for them. Now AWS can perform things like software updates and other maintenance tasks, but these don't take place on the area of the HSM which is used to perform cryptographic operations. Only you as an administrator or anyone that you delegate that to has the ability to interact with the secure area of the HSM devices.

Now before we finish this lesson, there are a few more things that I want to cover. So these are points that I think you should be aware of. So some of these are use cases, some of these are limitations that will help you select between using cloud HSM and using something like KMS.

So first, by default there's no native integration between cloud HSM and any AWS products. So one example of this is that you can't use cloud HSM in conjunction with S3 server-side encryption. That's not a capability that it has. Cloud HSM is not accessed using AWS standard APIs at least by default and so you can't integrate it directly with any AWS services. Now you could, for example, use cloud HSM to perform client-side encryption. So if you've got an encryption library on a particular local machine and you want to encrypt objects before you upload them to S3, then you can use it to perform that encryption on the object before you upload it to the S3 service. But this is not integrated with S3. You're just using it to perform encryption on the objects before you provide them to S3.

Now a cloud HSM can also be used to offload SSL or TLS processing from web servers. And if you do that, then the web servers can benefit from A, not having to perform those cryptographic operations, but also the cloud HSM is a custom designed piece of hardware that accelerates those processes. So it's much more economical and efficient to have a cloud HSM device performing those cryptographic operations versus doing it on a general purpose EC2 instance. So that's something that a cloud HSM can do for you, but KMS natively cannot.

Now other products that you might use inside AWS can also benefit from cloud HSM, products which are able to interact using these industry standard APIs. And this includes products like Oracle databases. So they can utilize cloud HSM for performing transparent data encryption or TDE. So this is a method that Oracle has for encrypting data that it manages on your behalf. And it can utilize a cloud HSM device to perform the encryption operations and to manage the keys. Now this does mean that because a cloud HSM device is something that's entirely managed by you, you're the only entity that initially starts off with access to be able to interact with the encryption materials. So the keys, it means that if you use a cloud HSM and integrate it with an Oracle database, then you're doing so in a way which means that AWS have no ability to decrypt that data. And so if you're operating in a highly restricted regulatory environment where you really need to use strong encryption and verify exactly who has the ability to perform encryption operations, then generally cloud HSM is an ideal product to support that.

And then lastly in a similar way, cloud HSM can also be used to protect the private keys for a certificate authority. So if you're running your own certificate authority, you can utilize cloud HSM to manage the private keys for that certificate authority.

Now just to summarize at this point, the overall theme is that for anything which isn't specific to AWS, for anything which expects to have access to a hardware security module using industry standard APIs, then the ideal product for that is cloud HSM. For anything that uses standards for anything that has to integrate with products which aren't AWS, then cloud HSM is ideal. For anything which does require AWS integration, then natively cloud HSM isn't suitable. If FIPS 140-2 Level 3 is mentioned, then it's cloud HSM. If integration with AWS is mentioned, then it's probably going to be KMS. If you need to utilize industry standard encryption APIs, then it's likely to be cloud HSM.

Now that's everything that we need to cover. I just wanted you to be able to handle any curveball HSM style questions that you might encounter in the exam. So thanks for watching, go ahead and complete this video and then when you're ready, I'll look forward to you joining me in the next one.

Welcome back and in this lesson I want to talk about AWS Shield, which is an essential tool to protect any internet connected environment from distributed denial of service attacks. Now it's important for the exam, but especially so for the real world. So let's jump in and get started. So AWS Shield actually comes in two forms, Shield Standard and Shield Advanced. Both of them provide protection against DDoS attacks, but there's a huge difference in their respective capabilities. First, Shield Standard is free for AWS customers, whereas Shield Advanced is a commercial extra product, which comes with additional costs and benefits, which I'll detail later in this lesson. The product protects against three different types or layers of DDoS attack. Now I've covered these in the DDoS lesson in the technical fundamental section of the course, but as a reminder, these categories are Network Volumetric Attacks, so these are things which operate at layer three of the OSI 7 layer model, and these are designed to simply overwhelm the system being attacked, so to direct as much raw network data at a target as possible. Next, we have Network Protocol Attacks, such as SYNFLUDS, and these operate at layer four of the OSI model. Now there are various types of protocol attack, but one common one is to generate a huge number of connections from a spoofed IP address and then just leave these connections open, so never terminating them, and while the CPU memory and data resources of the target will be fine, its ability to service real connections will be impacted by the huge volume of fake ones. To understand this, imagine a call centre where people call up and just leave the phone line silent. The operators won't be doing anything, but there won't be capacity for new calls to be answered. Now Network Protocol Attacks can also be combined with volumetric attacks, but by default, you should view these as two different things. Lastly, we have Application Layer Attacks, which operate at layer seven, for example, Web Request Floods. Imagine you have a part of your web app which allows searchers. Think of something like this which lets you search for every cat image in the world ever. From the perspective of the attacker, this uses almost no resources to run. It can be done hundreds, thousands or millions of times per second. But from the perspective of the system being attacked, this might take two to three seconds to return data, maybe even more. And so it's possible to de-doss a system by using the application as intended, where certain parts of the application are cheap to request, but expensive to deliver the result. So those are the types of things which SHIELD protects against. Now I want to spend a little time delving deeper into the capabilities of SHIELD Standard and Advanced, together with the differences. And I want to focus on when you might pick one versus the other. So let's start with SHIELD Standard. SHIELD Standard, as I mentioned earlier, is free for all AWS customers, so you benefit from its protection automatically without you having to do anything. The protection is at the perimeter of the network, which can either be in your region, meaning as data flows into a VPC, or it can be at the edge of the AWS network if you use CloudFront or Global Accelerator. SHIELD Standard protects against common network or transport layer attacks. So that's attacks at layer three or four of the OSI seven layer model. Now you get the best protection if you use Route 53, CloudFront or Global Accelerator. Now SHIELD Standard doesn't provide much in the way of proactive capability or any form of explicit configurable protection. It's just there working away in the background. Now that's the foundation, the baseline of the product. Now let's look at what extra things SHIELD Advanced offers. So SHIELD Advanced, as a starting point, is a commercial product. In fact, it costs $3,000 per month per organization. Now this is important, it's not per AWS account. If you have multiple accounts where you're wanting the advanced level of protection that SHIELD Advanced offers, then just make sure they're in the same AWS organization and you can share the one single investment. Now the cost while it is per month is part of a one year commitment. So at 3K per month, this means $36,000 per calendar year. And there's also a charge for data out for using the product. Now SHIELD Advanced protects more than standard. It covers CloudFront, Route 53, Global Accelerator, anything associated with elastic IPs, for example EC2. It also covers application, classic and network load balances. It's a comprehensive set of DDoS protections for your network perimeter. Now what's really important to understand as a concept is that the protections offered by SHIELD Advanced are not automatic. You need to explicitly enable protections, either in SHIELD Advanced or as part of AWS Firewall Manager when using SHIELD Advanced policies. It's an explicit act, remember that. You might find a question on the exam where you need to answer whether these protections require explicit configuration or they happen in the background. Now SHIELD Advanced offers two other really important benefits and it's important to understand that these are not technical functionality differences, but they're important nonetheless. First you get cost protection. And this means that if you as a customer incur any costs for any attacks which should be mitigated by AWS SHIELD Advanced, but aren't, then you're protected against those costs. And an example of this might be EC2 scaling events caused by excessive load. Now there are restrictions, it needs to be something SHIELD Advanced should cover and you should have enabled the coverage on that resource. Now I've included a link attached to this video which covers this particular feature in much more detail. You don't need to understand the detail for the exam, but for the real world it's good knowledge to have. Now the other benefit is a proactive style of management as well as access to the AWS SHIELD Response Team known as SRT. With proactive management, the SHIELD Response Team contacts you directly when the availability or performance of your application is affected because of a possible attack. And this provides the quickest level of response. It allows the SHIELD Response Team to begin troubleshooting even before they've established contact with you, the customer. Now to use this you need to provide your contact details in advance and enable the feature. And when you do, the SHIELD Response Team will contact you when any attacks are detected. You can also contact the SHIELD Response Team to log support tickets. And the SLA for this depends on your support plan. It might be one hour or 15 minutes. These are all things that you need to think about and decide upon up front. Now let's step through some of the technical ways in which SHIELD Advanced helps us. The first unique feature of SHIELD Advanced is the integration with the web application firewall. SHIELD Advanced uses the web application firewall to implement its protection against layer 7 attacks. And if you have a SHIELD Advanced subscription, this includes basic WAF fees to implement these protections. This is one of the differences in feature benefits which SHIELD Advanced provides over SHIELD Standard. And so it's an important one to keep in mind. Another benefit that SHIELD Advanced provides is advanced real-time metrics and reports for DDoS events and attacks. And these can be accessed via the SHIELD Advanced Console or APIs and via CloudWatch. Now, if you have a business need for SHIELD Advanced, if you can justify the cost, you're also going to have a need for this enhanced level of visibility. So this is another one to keep in mind. You also have health-based detection and this is using Route 53 health checks to implement application-specific health checks. Now, this allows you to reduce any false positives detected by AWS SHIELD. And it's used alone or in combination with the proactive engagement team to provide faster detection and mitigation of any issues. Health-based detection is actually a requirement for using the proactive engagement team. Again, another important thing to remember. Now, lastly, you also have protection groups and you can use protection groups to create groupings of resources which SHIELD Advanced protects. You can define the criteria for membership in a protection group so any new resources are automatically included. And with these groups, you gain the ability to manage protection at a group level versus a resource level which can significantly decrease the admin overhead of using the product. Now, at this point, that's everything I wanted to cover about AWS SHIELD at a high level. If the topic that you're studying requires any additional detail, there will be additional deep dive lessons. If not, don't worry, this is everything that you need to know. But at this point, that's the end of this video. So go ahead and complete the video and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this video I want to talk about the web application firewall known as WAF. Now this is a key part of the AWS network and network security product set so let's jump in and get started. Now WAF is AWS's implementation of a layer 7 or application layer firewall which we talked about in a previous video. That means a firewall which is capable of understanding layer 7 protocols such as HTTP and HTTPS. Before I talk in detail about the features of the product I want to visually step through how a WAF architecture might look. Now the example I'll be using is relatively complex. They can range from fairly simple through to this type of example which is relatively complex involving event-driven security response. So we start with an AWS environment and we decide to use a web application firewall which protects web resources which supports WAF and these include CloudFront, application load balancers, AppSync and API Gateway. Now WAF is the product but the actual unit of configuration within the product is known as the web access control list known as web ACL and it's this which is used by WAF and also associated with the various supported services. So you would associate a web ACL with a CloudFront distribution and this would result in the CloudFront distribution being protected by WAF. So WAF can protect global services such as CloudFront but also regional resources such as application load balancers, API gateways and AppSync and you need to configure this when you create the web ACL essentially creating it in a region rather than globally as is the case for CloudFront. Now within a web ACL you have rule groups and rules and I'll be talking more about how this is architected later in this video. At a high level this might be things like AWS managed rules or simple allow or deny lists. It might cover things like SQL injections or cross-site scripting attacks, HTTP floods or might relate to things like IP reputation and even protect against known botnets. It's these rule groups and rules which control how the WAF product reacts to incoming traffic allowing connections from valid users while hopefully blocking those from bots and other attackers against your web resources. Now this alone would be a super useful product which offers significant security benefits but when we combine this with other AWS products and architectures it can be even more useful. You can obviously update the web ACLs manually based on human identified security events or risks but you could also do simple automated things such as using event bridge and scheduled rules to pass various publicly maintained IP lists to block known bad actors. Now WAF does output logs and logging can be directed at S3 directly at cloud watch logs or kinesis firehose. Now importantly if you want to react to logs quickly you shouldn't directly use S3 as these are delivered directly approximately every five minutes. Firehose can be configured to put the logging data into any of its supported destinations including S3 and then all of these destinations can be integrated with an event driven security response architecture so using a combination of products such as S3 events, Lambda, Athena and EventBridge you can extract and identify intelligence to act on and then use this intelligence to update web ACLs to improve the security of the platform in a way which doesn't require humans. So this type of architecture is based on taking basic WAF and creating a feedback loop to take data, identify actionable intelligence and then automate changes based on that intelligence. And now that you have a visual idea about how a WAF implementation might look let's look at the raw features and how everything fits together. I mentioned earlier in this video that the web access control list or web ACL is the main unit of configuration within WAF. A web ACL is what controls if traffic is allowed or blocked. The starting point of a web ACL is a default action which will either allow or block any traffic which isn't matched by the ACL. Which one of these you pick depends on if you're using WAF to explicitly protect against certain exploits or if you want to only allow known good traffic through to your web resources. Additionally a web ACL is created for either cloud front which is a global service or a regional service such as an application load balancer, API gateway or AppSync. If you create a web ACL designed for a regional service then you have to define a region for the web ACL which matches the region that your services are located in. Now web ACLs on their own don't do anything you have to add rule groups or rules and these are processed in order. This order can be changed so you can move rules and rule groups around. Now I'm going to talk about rule groups and rules in a second but conceptually rules have a certain compute requirement based on their complexity. Web access control lists have a limit of how much compute requirements rules contained within them can use. An AWS have a concept called web ACL capacity units or WCU and this is not to be confused with DynamoDB WCU which is right capacity units. Web ACL capacity units are an indication at the complexity of rules and a web ACL has a default maximum of 1500 WCU that can be increased with a support ticket. Web ACLs are the things which are associated with resources so you associate a web ACL for example with a cloudfront distribution and this association can take some time it depends on the service. Cloudfront for example needs to update the distribution and then push this out to edge locations so this can take a fair bit of time. Adjusting a web ACL which is already associated to resources is quicker so keep that in mind. Now this is web ACLs at a high level these are the things which contain rules or rule groups and the things which are associated with resources. Importantly the relationship is currently that a resource can have one web ACL but one web ACL can be associated with many resources. Now also because of the global nature of cloudfront you can't associate a cloudfront web ACL with a regional resource or vice versa and web ACLs can currently not be used with AWS outposts. Okay let's move on and talk about rule groups. Rule groups as the name suggests are groups of rules they contain rules. They're used by web ACLs they're a feature which allows grouped admin of rules. They don't themselves have any default actions they're added to web ACLs and the web ACLs have the default action for anything not matched by rules either within groups or added directly to that web ACL. Now rule groups are either managed by AWS or a marketplace vendor, yours so managed by you or service owned for example SHIELD or firewall manager owned groups. AWS managed rule groups are mostly available for free for AWS WAF customers. The AWS WAF bot control and fraud control account takeover protection rule groups do have additional fees and I'll be talking about this later in the video where I talk about pricing. Now any rule groups obtained via the marketplace also generally have a subscription attached to them so you need to keep this in mind. Rule groups can be reused within many web ACLs. They're a separate entity and a web ACL can reference one or more rule groups. When you create a rule group you define upfront the WCU capacity and the default maximum is the same 1500 WCU. This indicates the amount of resources the rule group uses with its rules and it helps inform anyone using the rule group when they're building a web ACL. So now that we've talked about rule groups which are essentially an admin or contain a concept and rule groups can be referenced from web ACLs let's talk in more detail about the rules themselves. Now within WAF rules have a simple enough structure. We've got type, statement and action. The type of rule determines at a high level how it works. The statement consists of one or more things which match traffic or not and the action is what WAF does if a match occurs. Now rules are one of two types. We've got regular and rate based. Regular rules are designed to match if something occurs. Rate based are designed to match if something occurs at a certain rate. An example of this might be that you might have a rule to allow SSH connections from a certain IP address and this is an example of a regular rule but you might want another rule which allows you to do something if anyone attempted to connect via SSH save 5,000 times in a five-minute period because this would suggest a brute force attack. So you need to understand the differences between regular and rate based rules. Then you have the statement of a rule and this is the main part of a rule. It defines what the rule checks for. For regular rules think of this as a what. What does the rule match against? Examples might be incoming TCP port 80 or incoming SSH or it might be requests which have a certain HTTP header. For rate based rules it's slightly different. You're either going to be applying a rate limit on the number of connections for a source IP address or you're going to be applying a rate limit to connections which come from an IP address which also match certain criteria. So for example you might want a rule to apply if a client makes 5,000 connections over a five-minute period or you might only want this to apply if 5,000 connections to SSH are made within a five-minute period. Now in terms of criteria you can match against things like origin country, IP address, label and I'll talk more about this in a second. Headers, cookies, query parameters, your IPath, query string, the body of a request or the HTTP method. Now for the body it's important to understand that WAF is only checking the first 8,192 bytes. Again remember this one for the exam. Now depending on the criteria that you select from this list you can then choose how to match. Examples include exact matches, starts with, ends with, contains and much more. You can even match using regular expressions. Now you can also have more than one statement. Rules can have a single statement but also multiple and if you do have multiple you can choose whether to use and/or not conditions so you can define a pretty complex set of evaluation conditions. Now next we have the rule action and for regular rules these can allow block count or run a capture. For rate-based rules you can block count or run a capture. Allow and block obviously affect whether traffic is allowed. Count just counts the number of requests and records that data and capture runs a capture on the request so if a valid response is received it treats it as a count records it and continues processing and if the capture fails it's blocked and processing stops. Now it makes sense that allow is not valid for rate-based rules since conceptually you want to do something if a rate is above a certain value and it doesn't make sense that that something is allow. So remember with rate-based rules you're essentially wanting to perform an action if a rate is above a certain level. So remember with rate-based rules you only have block count and capture you don't have allow. Now you can also add custom responses as an optional extra. If your action is block then this can be a custom response or a custom header. For allows counts and capture this can be a custom header only. This custom header means your application itself can react to traffic which has been matched and custom headers are prefixed with x-amzn-waf- and the header is used so that your application can react in some way to traffic which has been affected by a rule. Now optionally labels can also be added. Labels are internal to WAF but what it allows is multi-stage flows where one rule can add a label and whether another rule runs can be based on the label being present or not. Labels as I just mentioned are internal to WAF only and they can be referenced from other rules within a single web ACL. They don't persist outside of that. Now importantly using labels relies on WAF not stopping processing and this is an important thing to understand with allow and block actions if a rule matches no further action occurs. Processing for that bit of traffic on that web ACL is stopped. For count and capture actions processing continues and this is where you typically use labels in follow-up rules which react in different ways based on that label being present. Now let's finish up by talking about pricing. With WAF you're charged a monthly price for every web ACL. Now currently this is $5 per month and I've put an asterisk next to this because this is subject to change so don't be surprised if this specific value is different when you're watching this lesson. Now also remember that web ACLs can be reused across different supported products and this is a monthly price per web ACL. There's also a charge per rule on a web ACL and this is a monthly charge currently $1 per month but again this is subject to change and also you're going to be charged another monthly fee for every rule group or managed rule group that you add to your web ACL. You've also got a charge for every request processed by a web ACL. Now again currently this is $0.6 per month for every 1 million requests. Now this charge is per web ACL so although you're only charged the single fee per web ACL and this can be reused across different products logically the more products that you use a web ACL on the higher the number of requests so this particular part of the pricing architecture will increase the more usage a web ACL has. Now if you need to understand this in detail I do suggest using the AWS pricing calculator and I've linked this attached to this video. This makes it really easy to just enter some values and see the true breakdown of using the WAF product. Now in addition to these costs there are also optional security features which can be enabled on your web ACL and these are in the area of intelligent threat mitigation and these come with additional fees. So first we have bot control and this comes with a monthly fee as well as a request based fee so this is a charge for every 1 million requests and again these are both subject to change they're accurate at the moment but don't be surprised if these prices are different when you're watching this video. Next we have captures and there's a price per 1000 challenge attempts and again this is subject to change. Next the fraud control and account takeover has a monthly charge and then a charge for every 1000 login attempts analyzed and lastly of course any marketplace rule groups that you choose to utilize will come with extra costs and these are all things that you need to keep in mind. So that's the architecture and feature overview of the WAF product. Now elsewhere in the course if appropriate there's going to be a demo where you can get experience of working with WAF in a practical sense. If you don't need practical knowledge for the particular thing that you're studying then this is all the information that you require. At this point though that's all of the theory that I want to discuss so go ahead and complete the video and when you're ready I look forward to you joining me in the next.

Welcome back, and in this video, I want to talk in general about application layer firewalls, also known as layer 7 firewalls, named after the layer of the OSI model that they operate at. I want to keep this video pretty generic and will talk about how AWS implements this within their product set in a separate video. So let's just jump in and get started.

Before I talk about the high-level architecture and features of layer 7 firewalls, let's quickly refresh our knowledge of layers 3, 4, and 5. We start with a layer 3 and 4 firewall, which is helping to secure the Categorum application—now accessed by millions of people globally because it's that amazing. Because this is a layer 3 and 4 firewall, it sees packets and segments, IP addresses, and ports. It sees two flows of communication: requests from the laptop to the server, and then responses from the server back to the laptop. However, because this firewall is limited to layers 3 and 4 only, these are viewed as separate and unrelated streams of data—request and response—even though they’re part of the same communication from a human perspective.

If we enhance the firewall by adding session capability, then the same communication between the laptop and server can be viewed as one. The firewall understands that the request and the response are part of the same session. This small difference reduces administrative overhead—allowing for one rule instead of two—and also lets you implement more contextual security, where you can treat response traffic in the context that it’s a response to an original request, rather than just arbitrary traffic in the same direction.

Now, this next point is really important: in both cases, these firewalls don't understand anything above the layer at which they operate. The top firewall operates at layers 3 and 4, so it understands layers 1 through 4. The bottom firewall does this as well but additionally understands layer 5. What this means is that both firewalls can see IP addresses, ports, and flags, and the bottom one can also understand sessions. However, neither of them can understand the data that flows above this—they have no visibility into layer 7, such as HTTP. They can't see headers or any other data transferred over HTTP. To them, layer 7 traffic is opaque—a cat image is the same as a dog image or malware—and this is a significant limitation that exposes the systems we're protecting to a wide range of attacks.

Layer 7 firewalls fix many of these limitations. Let’s consider the same architecture: a client on the left and a server or application on the right that we’re trying to protect. In the middle, we have a layer 7 firewall, and to help remember it, let’s add a smart robot to represent its capabilities. With this firewall, we still have the same flow of packets and segments, and a layer 7 firewall can understand all the lower layers—but it adds additional capabilities.

Consider this example where the Categor application is connected using an HTTPS connection, which is encrypted HTTP, and HTTP is the layer 7 protocol. The first important thing to realize is that layer 7 firewalls understand various layer 7 protocols. In this example, we're focusing on HTTP, so the firewall understands how that protocol transfers data: its architecture, headers, data, hosts, and all other components happening at or below layer 7. This means it can identify normal or abnormal elements of a layer 7 connection and protect against various protocol-specific attacks or weaknesses.

In the HTTPS connection to the Categor server, the HTTPS connection would be terminated at the layer 7 firewall. While the client believes it is connecting directly to the server, the firewall strips away the HTTPS tunnel, leaving plain HTTP, which it can analyze. Then, a new HTTPS connection is created between the layer 7 firewall and the backend server. From the server and client perspectives, this process is transparent. The crucial part is that, between the original and the new HTTPS connections, the firewall sees the unencrypted HTTP traffic in plain text. Because the firewall understands the layer 7 protocol, it can inspect, block, replace, or tag the data within that protocol stream.

This inspection might involve protecting the integrity of the Categor application by logically allowing cat pictures while rejecting dog images or labeling sheep images as spam. You might choose to be inclusive and only block truly dangerous content such as malware or exploits. Because the firewall understands one or more application protocols, you can allow or block content with great precision. You can even replace content—for instance, adult images might be replaced with kitten pictures or baby animals. Moreover, you can block specific applications like Facebook or prevent business data from being uploaded to services such as Dropbox.

The key thing to understand is that a layer 7 firewall retains all the capabilities of layers 3, 4, and 5 firewalls, but adds the ability to react to layer 7 elements. This includes DNS names, connection rates, content, headers—anything that exists in the specific layer 7 protocol that the firewall understands. Some layer 7 firewalls only support HTTP, while others might support SMTP, the protocol used for email delivery. The limit is defined only by what the firewall software is built to handle.

That’s everything I wanted to cover at a high level. Coming up in future videos, I’ll discuss how AWS implements layer 7 firewall capability within its product set. For now, though, this high-level understanding is the main focus of this video. So go ahead and complete the video, and when you're ready, I’ll look forward to you joining me in the next.

Welcome back.

In this lesson, I want to introduce the AWS Secrets Manager. It's often one that gets confused with the SSM Parameter Store. Inside the Parameter Store, you can create secure strings which allow you to store passwords, so logically, it's confusing. So when should you use the Parameter Store versus the Secrets Manager? Let’s take a look at that and make sure that you're 100 percent comfortable with selecting between both of these products for the exam.

For Secrets Manager, the functionality that the product provides and the way that it's architected are both pretty easy to understand. For the exam though, the main thing to lock in is when you should use Secrets Manager versus Parameter Store. It shares functionality with Parameter Store, and that’s the starting point. Don’t worry too much if for certain scenarios, you can’t really pick between them, because for some things, you can use either and achieve the same result.

Secrets Manager, as the name suggests, is designed specifically for secrets—things like passwords and API keys. So in the exam, if you see those keywords—API keys or passwords—then you should default to Secrets Manager. It’s usable from the console, the CLI, the API, and software development kits. It’s actually designed architecturally to be integrated inside other applications, and that’s one of the most common use cases: that Secrets Manager is integrated with other applications.

Another key differentiator of Secrets Manager is that it supports the automatic rotation of secrets using Lambda. A Lambda function is invoked periodically and is used to update the secrets. For certain AWS products such as RDS, Secrets Manager supports direct integration. This means that, as well as being able to periodically change a secret stored inside Secrets Manager, the product can also ensure that any authentication built into that product, such as RDS, is also changed and kept synchronized. So if Lambda is invoked and rotates a secret, then the password inside an RDS instance can also be changed. This integration is only supported for a certain limited set of products, and RDS is one of those.

In the exam, if you see any mention of rotating secrets—especially with RDS—then it's almost certain that Secrets Manager is the right answer. At a fundamental level, just like with Parameter Store, Secrets Manager lets you store secrets. But this product is specifically designed and focuses on the storage and rotation of these secrets. The secrets are kept safe, encrypted at rest, and the product integrates with IAM so you can use IAM permissions to control access. It rotates secrets, and clients can use Secrets Manager to access them and then communicate with, say, a database in a safe and secure way.

Let’s have a look visually at an example architecture involving Secrets Manager. I want to use an example of a web application that allows you to share funny images showing happy things—so you guessed it, we’re talking about Categor. Categor uses the Secrets Manager SDK. The SDK is part of the application and is used to retrieve database credentials. It uses IAM credentials for authorization—generally a role, though it might also use access keys, even though this is less ideal. These credentials interact with Secrets Manager to retrieve the database secrets, which the application then uses to securely access the database.

Now, all of this functionality could also be provided using the SSM Parameter Store. It has the capability to store secure strings, and we could use those encrypted strings to store any database connectivity information. What sets Secrets Manager apart is that it can periodically invoke a Lambda function to rotate credentials. The Lambda function will need permissions to do this, which it gets from an execution role. These permissions allow it to update the secret stored within Secrets Manager and, if you're using supported products such as RDS, also update the authentication information inside RDS to keep it in sync with Secrets Manager.

So if you're using a supported integrated product, then everything is managed end to end by Secrets Manager. It handles the rotation of credentials, updates the products using those credentials, and as long as the application keeps checking in with Secrets Manager, it can always ensure access to the most updated versions of the secrets. It’s also worth mentioning that secrets are secured using KMS. This means there’s no risk of leakage via physical access to AWS hardware, and KMS ensures role separation—so you need permissions to both KMS and Secrets Manager in order to access and decrypt secrets.

With a specific focus on the exam, if you suspect Secrets Manager might be involved, you need to perform keyword analysis. Determine whether the question mentions anything about secrets or rotation, and especially look for product mentions such as RDS. If any of those are present, then it’s almost certain that Secrets Manager is the correct answer.

The key differentiating point between Secrets Manager and Parameter Store usually comes down to whether the scenario explicitly mentions secrets, rotation, or integration with specific products—particularly RDS. Most exam questions won’t present both options; you’ll generally have to choose between them based on the context. But if both are present in the answer choices, then look for keywords related to rotation, integration, or secrets. If you see any of those, Secrets Manager is likely the right answer.

If you need to store anything besides secrets—such as hierarchical configuration information, maybe configuration for the CloudWatch agent—that kind of use case tends to point you toward Parameter Store. If it’s just secrets, if rotation is involved, or if product integration is mentioned, then go with Secrets Manager.

With that being said, that’s everything I wanted to cover in this architectural theory lesson. Go ahead, complete the video, and then when you’re ready, I’ll look forward to you joining me in the next.

Welcome to this video where I'm going to very briefly talk about AWS Transfer Family. This will be an introduction video, and if the topic you're studying requires any additional information, either theory or practical, then there will be follow-up videos. If not, then this is all that you need to know. I want to keep this video as brief as possible, so let's jump in and get started.

AWS Transfer Family is a product that provides a managed file transfer service, allowing you to transfer files to or from S3 and EFS. The reason it's managed is that it provides managed servers which support various protocols. This product allows you to upload and download data to and from EFS and S3 using protocols other than the two native protocols. If you need to access S3 or EFS and not use them natively, then Transfer Family is the product that allows this. It allows you to interact with both of these services using a number of common protocols.

The first protocol is FTP, or File Transfer Protocol, which is unencrypted and has been around for decades. Due to its lack of encryption, its usage is relatively niche. The next is FTP-S, or File Transfer Protocol Secure, which is FTP with TLS encryption, adding additional layers of functionality to FTP. Then we have SFTP, or Secure Shell File Transfer Protocol, which is file transfer running over the top of SSH. Lastly, we have AS2, or Applicability Statement 2, a protocol used for transferring structured business-to-business data. While this is relatively niche, it was added to the product because it's common in certain industries, particularly for workflows with compliance requirements related to data protection and security. AS2 might be used in industries for supply chain logistics, payment workflows, or business-to-business transactions and integrations with enterprise resource planning (ERP) and customer relationship management (CRM) systems. Using AS2 is something you'll typically do in specific situations, and you'll know if you need this protocol. FTP, FTP-S, and SFTP are much more common and are found in a wide variety of industries.

Transfer Family also supports a wide variety of identity providers. The service can have built-in identities, you can use AWS's Directory Service, or you can use custom identity providers, utilizing Lambda or API Gateway. A really important feature of Transfer Family is the Managed File Transfer Workflows (MFTW), which you can think of as a serverless file workflow engine. When files are uploaded to the product, you can define a workflow for what happens to that file as it gets uploaded, such as notification or tagging. This can be especially effective if you need to integrate Transfer Family into other process-based workflows within your business.

With Transfer Family, you gain access to all of these different file transfer protocols via a Transfer Family server within AWS, without needing to manage any server infrastructure. If you need to interact with S3 or EFS using existing workflows where you can't change your applications, then you can use Transfer Family. Now let's take a look visually at the architecture of the product. At a high level, this is how Transfer Family works: we have an AWS environment, and inside, we have S3 and EFS. We want to grant access to either or both of these to an external user, for example, a medical user who wants to use the SFTP protocol.

To do this, we'd configure Transfer Family and create servers that are enabled for one or more protocols. These servers are configured to communicate with the backend storage resources using IAM roles for permissions. Once configured, our user can access these resources, potentially using a custom DNS name and a protocol that they support, rather than the native S3 or EFS access methods. Transfer Family also supports a range of authentication methods, including built-in identities, AWS's Directory Service, or a custom identity store.

That's how the service works from a high-level architecture perspective. But there is additional information that you'll need for real-world applications and the AWS exams, where this product features. Let's now explore how we can connect to the service over different networking architectures. Within Transfer Family, you create servers, which act as the front-end access points to your storage. These servers present the supporting backend storage (S3 and EFS) via one or more supported protocols, such as SFTP, FTPS, FTP, and AS2. How you access these depends on how you configure the service's endpoints, with three options available: Public, VPC with Internet access, and VPC internal only.

For the Public endpoint, the endpoint runs in the AWS public zone, making it accessible from the public internet. This means there is nothing to configure in terms of networking, and no worries about VPCs or other networking components. However, it comes with some limitations: the only supported protocol is SFTP, the endpoint has a dynamic IP managed by AWS (so DNS should be used to access it), and you can't control access using features like network access control lists or security groups.

Next, the endpoint types that run in a VPC share some similarities. Both run inside a VPC, but the VPC Internet type allows you to use SFTP, FTPS, and AS2. The internal-only VPC endpoint type allows the use of SFTP, FTPS, FTP, and AS2. FTP, being unencrypted, is best suited for internal use and should not run over the public internet. Both VPC endpoint types can be accessed from connected business networks, such as Direct Connect and VPNs, so anything with connectivity to the VPC can access the service as if it were inside the VPC. Additionally, Transfer Family provides static IPs for both types, and both can be secured using network access control lists or security groups, providing a security benefit compared to the public endpoint type.

The main difference is that the VPC Internet type is allocated with an elastic IP, which is static and accessible both over the public internet and within the VPC, as well as from corporate networks. This provides a more secure and flexible option compared to the public endpoint type.

To summarize, this is the foundational knowledge you need. If your course requires more theory or practical knowledge, follow-up videos will be provided. Otherwise, this covers everything you'll need to understand for now. A few final points: AWS Transfer Family is multi-AZ, and the cost is based on the provisioned server per hour and the data transferred. There are no upfront costs, and you only pay for what you use. For FTP and FTPS, only directory service or custom identity providers are supported, and for FTP, it can only be used internally within a VPC. FTP cannot be used with the public or VPC Internet endpoint types. As for AS2, it requires a VPC Internet or internal-only endpoint type and cannot use the public endpoint type.

You would use this product if you need access to S3 or EFS through existing protocols, especially when integrating it into your existing workflows where the protocol cannot be changed, or you might use the Managed File Transfer Workflow feature to create new workflows. As mentioned earlier, this is the core knowledge needed for AWS exams that feature this product. If you require further information, additional theory or practical videos will follow this one. But for now, that's everything I want to cover in this video. Complete the 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 another file system provided by FSX, which is FSX for Lustre. This is a file system designed for various high-performance computing workloads. It is important for the exam that you understand exactly what it provides and how it’s architected. We have a lot to cover, so let’s jump in and take a look.

In the exam, you won’t need to know about Lustre in detail. It’s one of those relatively niche products, but you'll need to distinguish between scenarios when you might use products such as FSX for Windows versus FSX for Lustre. FSX for Windows is a Windows-native file system that is accessed over SMB. It’s used for Windows-native environments within AWS. FSX for Lustre, on the other hand, is a managed implementation of the Lustre file system, which is designed specifically for high-performance computing. It supports Linux-based instances running in AWS, and as a key concept to track for the exam, it also supports POSIX-style permissions for file systems. Lustre is designed for use cases such as machine learning, big data, or financial modeling—anything that needs to process large amounts of data with a high level of performance.

FSX for Lustre can scale to hundreds of gigabytes per second of throughput, offering sub-millisecond latency when accessing that storage. This is the level of performance required for high-performance computing across many clients or instances. FSX for Lustre can be provisioned using two different deployment types. If you have a need for the absolute best performance for short-term workloads, then you can pick the Scratch deployment. Scratch is optimized for really high-end performance, but it doesn’t provide much in the way of resilience or high availability. If you need a persistent file system or high availability for your workload, then you can choose the persistent option. This option is great for longer-term storage, offering high availability, but it’s important to note that it provides high availability within only one availability zone.

Lustre is a single availability zone file system because it needs to deliver high-end performance. Therefore, the high availability provided by the persistent deployment type is only within one availability zone, and it also offers self-healing. If any hardware fails as part of the file system, it will be automatically replaced by AWS. This is the deployment type to choose if you need resilience and high availability for the data running on the file system. While you won’t need to know this level of detail for the exam, I’ve included a link attached to this lesson that details the differences between Scratch and persistent deployments in more detail. I find it useful to at least know the high-level differences between these two deployment types.

As with FSX for Windows, FSX for Lustre is available over a VPN or Direct Connect from on-premises locations. Of course, you will need a substantial amount of bandwidth to benefit from the Lustre performance, but it is available as an option. Now, it's important for the exam that you have an understanding of how FSX for Lustre works, so let’s have a look at that next. Before we dive into the architecture of FSX for Lustre, I want to conceptually talk about what FSX for Lustre means. What do you actually do when you use this file system? The product focuses on a managed file system that you create, which is accessible from within a VPC and anything connected to that VPC via private networking. So, in terms of connectivity, it’s much like EFS or FSX for Windows in that sense—you can access it from the VPC or anything connected to it with private networking.

The file system is where the data lives, where it's being analyzed or processed by your applications. When you create a file system, you can associate it with a repository, and in this case, the repository is an S3 bucket. If you do this when the file system is created, the objects within the S3 bucket are visible in the file system. However, at this stage, they’re not actually stored within the Lustre file system. When the data is first accessed by any clients connected to the Lustre file system, it is lazy-loaded into the file system from the S3 repository. After that first load, it remains within the file system. So, it’s important to understand that while objects initially appear to be within the file system when using an S3 repository, they’re only truly present in the file system when they’re first accessed. There isn’t actually any built-in synchronization. Conceptually, the Lustre file system is separate, and it can use an S3 repository as a foundation.

You can sync any changes made in the file system back to the S3 repository using the HSM underscore archive command. What I want you to understand conceptually is that the Lustre file system is completely separate. It can be configured to lazy-load data from S3 and write it back, but it’s not automatically in sync. The Lustre file system is where the processing of data occurs.

Now that I’ve covered the conceptual elements, let’s take a look at how the product is architected. Before doing that, there are a few key points to discuss. Lustre splits data up when storing it on disks. There are different types or elements to the data stored within the file system. The first is the metadata, which includes things like file names, timestamps, and permissions. This is stored on metadata targets (MSTs), and the Lustre file system has one of these. Then, we have the data itself, which is split across multiple object storage targets (OSTs). Each of these is 1.17 TIB in size. By splitting the data across these OSTs, Lustre achieves its high performance levels.

The performance provided by the product is a baseline performance level based on the size of the file system. The size of the file system starts with a minimum of 1.2 TIB, and you can add in increments of 2.4 TIB. For the Scratch deployment type, you get a baseline performance of 200 megabytes per second per TIB of storage. For the persistent deployment type, there are three baseline performance levels: 50, 100, and 200 megabytes per second per TIB of storage. For both deployment types, you can burst up to 1300 megabytes per second per TIB of storage. This is based on a credit system, where you earn credits when you're using a performance level below your baseline and consume these credits when you burst above the baseline. It shares many characteristics with EBS volumes, but at a much higher scale and with more parallel architecture.

Let’s look at this architecture visually. Any FSx architecture uses a client-managed VPC—something that you design and implement. Inside this client-managed VPC, there are some clients, typically Linux EC2 instances with the Lustre software installed so they can read and interact with the Lustre file system. At the other end of the architecture, you create a Lustre file system and optionally an S3 repository for that file system. Depending on the size of storage that you configure within Lustre, the product deploys a number of storage servers. These servers handle the storage requests placed against the file system, and each one provides an in-memory cache to allow faster access to frequently used data.

At a high level, the more storage you provision, the more servers and the more aggregate throughput and IOPS that FSx for Lustre can deliver into your VPC. This performance is delivered into your VPC using a single elastic network interface (ENI). Lustre runs from one availability zone, so you’ll have one ENI within your client-managed VPC, which is used to access the product. From a performance perspective, any writes to Lustre will go through the ENI and be written directly to disk. This depends on the disk throughput and IO characteristics. Likewise, if data is read directly from disk, it’s based on the performance characteristics of the underlying disks. For frequently accessed data, it can use in-memory caching, and at that point, it’s based on the performance characteristics of the networking connecting the clients to the Lustre servers.

At a high level, this is the architecture that the FSx for Lustre product uses. Now, let’s look at some key points that you need to be aware of for the product. When you're creating an FSx for Lustre file system, you get to create it using one of two deployment types. I mentioned these earlier in this lesson. The first one is Scratch, which is designed for when you want pure performance. If you’re deploying short-term or temporary workloads, and all you care about is pure performance, the Scratch deployment type is the way to go. However, it’s crucial to understand that this doesn’t provide any high availability or replication. If there’s a hardware failure, any data stored on that hardware is lost and not available to the file system. This doesn’t mean other data is at risk, as any other data continues to be available as part of the Lustre file system, but you need to understand from a file system planning perspective that larger file systems generally mean more servers, more disks, and a higher chance of failure.

Choosing the persistent deployment type means you have replication, but this is only within a single availability zone. All hardware and data are replicated within a single availability zone, which protects you against hardware failure but not against the failure of an entire availability zone. Using the persistent deployment type means the product will auto-heal any hardware failure, and data won’t be lost, but remember, this is only within one availability zone. If an entire availability zone fails, data could be lost because hardware isn’t recoverable outside of that zone. However, with both deployment types, you can use the backup functionality of the product to back up that data to S3, and you can perform manual or automatic backups. Automatic backups have anywhere from zero to 35 days of retention, with zero meaning that automatic backups are disabled.

At a high level, this is how the FSx for Lustre product works. It’s similar to FSx for Windows and EFS in terms of architecture. It uses elastic network interfaces injected into a VPC, which can be accessed from the VPC or from any other network connected to that VPC using private networking. For the exam, if you see Windows or SMB mentioned, it’s FSx for Windows and not FSx for Lustre. If you see any mention of Lustre, high-performance computing, POSIX, machine learning, big data, or similar scenarios, it’s FSx for Lustre. If you see machine learning or SageMaker and need a high-performance file system, it could be FSx for Lustre.

With that being said, that’s everything I wanted to cover in this lesson. Go ahead and complete the lesson, and when you're ready, I’ll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover the FSx products, specifically FSx for Windows File Server. FSx is a shared file system product, but it handles the implementation in a very different way than, say, EFS, which we've covered earlier in the course. FSx for Windows File Server is one of the core components of the range of services that AWS provides to support Windows environments in AWS. For a fair amount of AWS history, its support of Windows environments was pretty bad; it just didn't seem to be a priority. Now this changed with FSx for Windows File Server, which provides fully managed native Windows File Servers or, more specifically, file shares. You're provided with file shares as your unit of consumption. The servers themselves are hidden, which is similar to how RDS is architected, but instead of databases, you get file shares.

Now, it's a product designed for integration with Windows environments. It's a native Windows file system; it's not an emulated file server. It can integrate with either managed Active Directory or self-managed Active Directory, and this can be running inside AWS or on-premises. This is a critical feature for enterprises who already have their own Active Directory provision. It is a resilient and highly available system, and it can be deployed in either single or multi-AZ mode. Picking between the two controls the network interfaces available and used to access the product. It uses elastic network interfaces inside the VPC. The backend, even in single AZ mode, uses replication within that availability zone to ensure that it's resilient to hardware failure. However, if you pick multi-AZ, then you get a fully multi-AZ, highly available solution.

It can also perform a full range of different types of backups, which include both client-side and AWS-side features. I'll talk about that later in the lesson. From an AWS side, it can perform both automatic and on-demand backups. Now, file systems that are created inside the FSx product are accessible within a VPC. But also, and this is how more complex environments are supported, they can be accessed over peering connections, VPN connections, and even accessed over physical direct connects. So if you're a large enterprise with a dedicated private link into a VPC, you can access FSx file systems over Direct Connect.

Now, in the exam, when you’re faced with any questions that talk about shared file systems, you need to be looking to identify any Windows-related keywords. Look for things like native Windows file systems, look for things like Active Directory or Directory Service integration, and look for any of the more advanced features, which I’ll talk about over the remainder of this lesson. Essentially, your job in the exam is to pick when to use FSx versus EFS because these are both network shared file systems that you’ll find on the exam. Generally, EFS tends to be used for shared file systems for Linux EC2 instances as well as Linux on-premises servers, whereas FSx is dedicated to Windows environments, so that's the main distinction between these two different services.

So let's have a look visually at how a typical implementation of FSx for Windows File Server might look for an organization like Animals for Life. We start with a familiar architecture. We have a VPC on the left and a corporate network on the right, and these networks are connected with Direct Connect or VPN, with some on-premises staff members. Inside the VPC, we have two availability zones (A and B), and in each of those availability zones, we have two different private subnets. FSx uses Active Directory for its user store, so logically, we start with a directory, which can either be a managed directory delivered as a service from AWS or something that is on-premises.

Now, this is important: FSx can integrate with both, and it doesn’t actually need an Active Directory service defined inside the Directory Services product. Instead, it can connect directly to Active Directory running on-premises. This is critical to understand because it means it can integrate with a completely normal implementation of Active Directory that most large enterprises already have. As I already mentioned, FSx can be deployed either in single AZ or multi-AZ mode, and in both of those, it needs to be connected to some form of directory for its user store. Once deployed, you can create a network share using FSx, and this can be accessed in the normal way using the double backslash, DNS name, and share notation that you'll be familiar with if you use Windows environments. For example, a file system ID dot animalsforlife.org, followed by a slash and "cat pics." In this example, "cat pics" is the actual share.

Using this access path, the file system can be accessed from other AWS services that use Windows-based storage. An example of this is Workspaces, which is a virtual desktop service similar to Citrix available inside AWS. When you deploy Workspaces into a VPC, not only does it require a directory service to function, but for any shared file system needs, it can also use FSx. The most important thing to remember about FSx is that it is a native Windows file system. It supports things like deduplication, the distributed file system (DFS), which is a way Windows can group file shares together and scale out for a more managed file share structure at scale. It supports at-rest encryption using KMS, and it also lets you enforce encryption in transit. Shares are accessed using the SMB protocol, which is standard in Windows environments, and FSx even allows for volume shadow copies. In this context, volume shadow copies allow users to see multiple file versions and initiate restores from the client side.

So that’s really important to understand: if you’re utilizing an FSx share from a Windows environment, you can right-click on a file or folder, view previous versions, and initiate file-level restores without having to use AWS or engage with a system administrator. That’s something that’s provided along with the FSx product as long as it’s integrated with Windows environments—you get that capability. Now, from a performance perspective, FSx is highly performant. The performance delivered can range from anywhere from 8 megabytes per second to 2 gigabytes per second. It can deliver hundreds of thousands of IOPS and less than one millisecond latency, so it can scale up to whatever performance requirements your organization has.

Now, for the exam, you don't need to be aware of the implementation details. I’m trying to focus really on the topics and services that you need for the exam in this course. So when things do occur, I want to teach you more information than you may require for the exam, but there are a lot of topics or features of different services that you only require a high-level overview of, and this is one of those topics. So, what I want to do now is go through some keywords or features that you should be on the lookout for when you see any exam questions that you think might be related to FSx.

The first of these is DFS, a Windows feature that allows users to perform file and folder-level restores. This is one of the features that's provided and is unique to FSx, meaning that if you have any users of Workspaces and they use files and folders on an FSx share, they can right-click, view previous versions, and restore from a user-driven perspective without having to engage a system administrator. Another thing to be aware of is that FSx provides native Windows file systems that are accessible over SMB. If you see SMB mentioned in the exam, it’s probably going to be FSx as the default correct answer. Remember, the EFS file system uses the NFS protocol and is only accessible from Linux EC2 instances or Linux on-premises servers. If you see any mention of SMB, then you can be almost certain that it’s a Windows environment question and involves FSx.

Another key feature provided by FSx is that it uses the Windows permission model, so if you're used to managing permissions for folders or files on Windows file systems, you'll be used to exactly how FSx handles permissions. This is provided natively by the product specifically to support Windows environments in AWS. Next is that the product supports DFS, the distributed file system. If you see that mentioned, either its full name or DFS, then you know that this is going to be related to FSx. DFS is a way that you can natively scale out file systems inside Windows environments. You can either group file shares together in one enterprise-wide structure or use DFS for replication or scaling out performance. It’s a really capable distributed file system.

Now, if you see any questions that talk about the provision of a native Windows file server, but where the admin overhead of running a self-managed EC2 instance running something like Windows Server is not ideal, then you know that it's going to be FSx. FSx provides you with the ability to provision a native Windows file server with file shares but without the admin overhead of managing that server yourself. Lastly, the product is unique in the sense that it delivers these file shares, which can also be integrated with either directory service or your own active directory directly. These are really important things to remember for the exam, and they’ll help you select between other products and FSx.

Again, I don’t expect you to get many questions on FSx. I do know of at least one or two unique questions in the exam, but even if it only gets you that one extra mark, it can be the difference between a pass and a fail. So try your best to remember all the key features I’ve explained throughout this lesson. But at that point, that is everything I wanted to cover in this theory-only lesson. Go ahead, complete this video, and then when you're ready, I look forward to you joining me in the next.

Welcome back! In this lesson, I want to talk about an AWS service which you will use in the real world as a solutions architect, and it's also one that starts to feature more and more in the exam. The product I’m referring to is AWS DataSync. We’ve got a lot to cover, so let’s jump in and get started.

AWS DataSync currently tends to feature in the exam in a very light way. You might be lucky and not even have a question on it, but I do know that it features in at least two unique questions that I’m aware of. So, you do need to be aware of what it is, what it does, and the type of situations where you might use it.

DataSync is a data transfer service that allows you to move data into or out of AWS. Historically, many of the transfer tasks involving AWS have either been manual uploads or downloads or have used a physical device like the Snowball or Snowball Edge series of transfer devices. DataSync, however, is a service that manages this process end-to-end.

DataSync tends to be used for workloads like data migrations into AWS, or when you need to transfer data into AWS for processing and then back out again, or when you need to archive data into AWS to take advantage of cost-effective storage. It can even be used as part of disaster recovery or business continuity planning.

As a product, it’s designed to work at huge scales. Each agent—and I’ll introduce the concept of an agent later in this lesson—can handle 10 gigabits per second of data transfer, and each job—I'll also introduce the concept of jobs within this lesson—can handle 50 million files. This is obviously huge scale. Very few transfer jobs will require that level of capacity or performance, but in addition to that scale, it also handles the transfer of metadata such as permissions and timestamps, which are both essential for complex data structure migrations.

And finally, and this is a huge benefit for some scenarios, DataSync includes built-in data validation. Imagine if you're transferring huge numbers of medical records or scans into AWS. You need to make sure that the data, as it arrives in AWS, matches the original data, and DataSync includes this functionality by default.

Now, in terms of the key features of the product, it is really scalable. Each agent can handle 10 gigabits per second of data transfer, which equates to around 100 terabytes per day, and you can add additional agents assuming you have the bandwidth to support it. You can use bandwidth limiters to avoid the saturation of internet links, thus reducing the customer impact of transferring the data. The product supports incremental and scheduled transfers, and it supports compression and encryption.

If you're transferring huge amounts of data and have concerns over liability issues, DataSync also supports automatic recovery from transit errors. It handles integration with AWS services such as S3, EFS, and FSX for Windows servers. For some services, it supports service-to-service transfer, such as moving data from EFS to EFS inside AWS, even across regions. Best of all, it’s a pay-as-you-use service, so there is a per-gigabyte cost for any data that's moved by the product.

Let’s quickly look at the architecture visually to help you understand exactly how it gets used. This is going to be useful for the exam. In this example architecture, we have a corporate on-premises environment on the left and an AWS region on the right. The business premises have an existing SAN or NAS storage device with data that we want to move into AWS. To facilitate this, we install the DataSync agent on the business’s on-premises VMware platform. This agent is capable of communicating with the NAS or SAN using either the NFS or SMB protocols. Most SANs, NASs, or other storage devices support either one or both of these protocols. So, the DataSync agent is capable of integrating with nearly all local on-premises storage.

Once DataSync is configured, the agent communicates with the DataSync endpoint running within AWS, and from there, it can store the data in a number of different types of locations. Examples include various S3 storage classes or VPC resources such as Elastic File System (EFS) or FSX for Windows Server. You can configure a schedule for the transfer, targeting or avoiding certain time periods. If you have any link-speed performance issues, you can set a bandwidth limit to throttle the rate at which DataSync syncs the data between your on-premises environment and AWS.

For the exam, you just need to understand the architecture. You won’t need to be aware of the implementation details. So, at a very high level, be aware that you need to have the DataSync agent installed locally within your on-premises environment. Be aware that it communicates over NFS or SMB with on-premises storage and then transfers that data through to AWS. It can recover from failures, it can use schedules, and it can throttle the bandwidth between on-premises and AWS. From there, it can store data into S3, the Elastic File System, or FSX for Windows Servers.

If you see any questions in the exam that discuss the reliable transfer of large quantities of data, that needs to integrate with EFS, FSX, or S3, and supports bidirectional transfer, incremental transfer, and scheduled transfer, then it’s likely to be AWS DataSync that’s the right answer.

Now, let’s finish up by reviewing the main architectural components of the DataSync product. First, we have the task. A task within DataSync is essentially a job. A job defines what is being synced, how quickly, any schedules that need to be used, and any bandwidth throttling that needs to take place. It also defines the two locations that are involved in that job—where the data is being copied from and where it is being copied to.

Next, we have the agent. As I’ve already mentioned, this is the software used to read or write to on-premises data stores. It uses NFS or SMB and is used to pull data off that store and move it into AWS, or vice versa.

Lastly, we’ve got a location. Every task has two locations—the from location and the to location. Examples of valid locations are network file systems or NFS, server message block or SMB—both of these are very common corporate data transfer protocols. NFS is typically used with Linux or Unix systems, and SMB is very popular in Windows environments. Other valid locations include AWS storage services such as EFS, FSX, and Amazon S3.

That’s all the information you need for the exam. I just wanted to introduce the service because, as I mentioned at the start, I am aware that there are at least two questions involving this product on the new version of the exam. I want to make sure that you go into that exam understanding the high-level architecture, so if you do see DataSync mentioned, you can at least identify whether it’s an appropriate use of that technology or not.

You’ll find that those questions aren’t asking you to interpret different features of DataSync. You’ll be asked to select between DataSync and another product or method of getting data into AWS. So, in this lesson, I focused on exactly when you would use DataSync. If you need to use an electronic method and Snowball or Snowball Edge aren’t appropriate, if you need something that can transfer data in and out of AWS, if the product needs to support schedules, bandwidth throttling, automatic retries, compression, and can handle huge-scale transfers with various AWS and traditional file transfer protocols, then it’s likely DataSync that you need to pick.

With that being said, that’s everything you need to know for any DataSync questions on the exam. Go ahead and complete this video, and when you’re ready, I look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover the AWS Directory Service. This is another service which I think is often overlooked and undervalued. It provides a managed directory, a store of users, objects, and other configuration. Now, it's delivered as a managed service, and it has a few versions and lots of use cases. So we do have a lot to cover in this architecture lesson. Let’s jump in and take a look.

Before we start, I want to talk about directories in general. What are they, and what do they do? Well, directories store identity and asset-related information. So things like users, groups, computer objects, server objects, and file shares. They hold all of these objects in a structure that is hierarchical, like an inverted tree. This is often referred to as a domain. But regardless of its name, it's essentially an inverted tree structure that holds identity-related objects.

Now, multiple directories, each of which provides a tree structure, can be grouped together into what's called a forest. Directories are commonly used within larger corporate Windows environments. You can join devices to a directory, such as laptops, desktops, and servers. Directories provide centralized management and authentication, which means you can sign in to multiple devices with the same username and password. It allows corporate IT staff to centrally manage all of the identity and asset information in one single data store.

One of the most common types of directory in large corporate environments is Active Directory by Microsoft, known as Microsoft Active Directory Domain Services (ADDS). But there are alternatives. Another common one is SAMBA, which is an open-source implementation of Active Directory. It’s designed to provide an alternative, but it only provides partial compatibility with Active Directory. This is something you need to be aware of when it comes to picking the mode that the directory service will be operating in.

Now, let's look at Directory Service specifically. Directory Service is an AWS implementation of a directory, the equivalent of Active Directory, as RDS is to databases. Using it means you have no admin overhead of running your own directory service, and that admin overhead is often significant. Directory Service runs within a VPC; it's a private service. So to use it for services, those services either need to be within that VPC, or you need to configure private connectivity to that VPC.

It provides high availability by deploying into multiple subnets in multiple availability zones within AWS. Now, there are certain AWS services, such as EC2, that can optionally use a directory. For example, Windows EC2 instances can be configured to join the directory, allowing you to use identities inside that directory to log in to the EC2 instance. You can also configure a directory for centralized management to various Windows features running on Windows EC2 instances.

Certain services within AWS require a directory. An example is Amazon Workspaces, which is a virtual desktop product where you can get a virtual operating system on which to run applications. If you've ever used Citrix or something similar, Amazon Workspaces is AWS's version of this. But it needs a directory, and that directory needs to be registered with AWS, so it requires the Directory Service product. To join EC2 instances to a domain via the AWS tools, you also need to have a registered directory inside AWS.

The Directory Service product is an AWS-supported and registered directory service within AWS that other AWS products can utilize for identity and management purposes. When you create a directory, you'll be doing so with a number of different architectures in mind. It might be an isolated directory, meaning inside AWS only and independent of any other directory that you might have, or it can be integrated with an existing on-premises directory, almost like a partner directory. Alternatively, you can use the Directory Service in what's called connector mode, which proxies connections back to your on-premises system. This essentially allows you to use your existing on-premises directory with AWS services that require a registered directory service.

I want to quickly step through each of these different architectures visually before we finish up. For the exam, you only need to have an awareness of the architecture, and I find that by looking at it visually, it helps keep it in your memory for when you sit the exam. Let’s do that next and step through each of the different modes that the Directory Service can run in.

First, we’ll look at the Directory Service running in simple AD mode. This is the cheapest and simplest way that the product can run inside a VPC. We start with a VPC and say we want to run Amazon Workspaces within this VPC. These Workspaces will be used by some Animals for Life users. Since Workspaces as a product requires a directory service, when you log into a workspace, you're not logging into a local user; you're logging in using a user of that directory. Therefore, it needs some type of directory registered within AWS, and one option is deploying the Directory Service in simple AD mode.

Simple AD is an open-source directory based on SAMBA4, providing as much compatibility with Microsoft Active Directory as possible but in a lightweight way. If you see any mention of open-source or SAMBA4, think simple AD. You can create users and other objects within simple AD, and it can integrate with Workspaces. Simple AD can operate in two different sizes: it can support up to 500 users in small mode and up to 5,000 users in large mode. It integrates with many AWS services such as Amazon Chime, Amazon Connect, Amazon QuickSight, Amazon RDS, WorkDocs, WorkMail, WorkSpaces, and even the AWS Management Console, allowing you to sign in with users of the directory service.

There are other services such as EC2, which can also utilize the Directory Service, either from the console or by manually configuring the operating system of the EC2 instance. When you deploy a simple AD Directory Service, you’re deploying a highly available version of SAMBA, so anything that can join this SAMBA directory is capable of joining the Directory Service running in simple AD mode.

The critical thing to understand about simple AD mode is that it's designed to be used in isolation. It’s not designed to integrate with on-premises systems, nor is it a full implementation of something like Microsoft Active Directory. If you need something bigger and more feature-rich, you can opt for Managed Microsoft AD mode. This mode is for when you want a direct presence inside AWS and also have an existing on-premises environment.

Using this mode, you can create an instance of the Directory Service inside AWS. Architecturally, it’s similar to simple AD, where you can create users within the directory service hosted inside AWS. Once created, services inside AWS can integrate directly with the directory service. Additionally, you can create a trust relationship with your existing on-premises directory, and this connection requires private networking such as a direct connect or VPN connection.

The benefit of this mode is that the primary location is in AWS, and it trusts your on-premises directory. Even if the VPN fails, the AWS services that rely on the directory can still function. When you deploy Directory Service in Microsoft AD mode, it’s a fully fledged directory service in its own right, not reliant on any on-premises infrastructure. It’s also an actual implementation of Microsoft Active Directory, specifically the 2012 R2 version, supporting applications requiring Microsoft AD features like schema extensions, such as Microsoft SharePoint and Microsoft SQL Server-based applications.

So, if you encounter exam questions about requiring an actual implementation of Microsoft Active Directory, complete with trust relationships with an on-premise Microsoft Active Directory, then you need to use the managed Microsoft Active Directory mode, not simple AD.

Lastly, there’s the AD Connector mode. Consider a scenario where you only want to use one specific AWS service that has a directory service requirement, like Amazon Workspaces. In this example, you already have an on-premises directory and don’t want to create a new one just to use this one product. AD Connector provides a solution. To use AD Connector, you need to establish private network connectivity between your AWS account and your on-premises network, such as via a VPN. Once the VPN is established, you can create the AD Connector and point it back at your on-premises directory.

It's critical to understand that the AD Connector is just a proxy. It exists solely to integrate with AWS services, so any AWS services that need a directory will see the AD Connector and know they have access to an active directory instance, but it doesn’t provide any authentication of its own. It simply proxies the requests back to your on-premises environment.

If the private network connectivity fails, the AD Connector stops working, and any services using it could experience issues. This means that AD Connector is best used when you already have a directory on-premises and just want to use AWS products and services requiring a directory without deploying a new one.

One important thing for the exam is knowing when to pick between the different modes for Directory Service. Start with simple AD. It's your default, designed for simple requirements, if you need an isolated directory within AWS and don't need connectivity with on-premises. Use it to support AWS products and services that require a directory. If you need an actual implementation of Microsoft Active Directory or have applications expecting it, use Microsoft AD. If you just need AWS services to access a directory but don’t want to manage a directory in the cloud, use AD Connector.

Remember that the AD Connector doesn't provide functionality of its own. It simply proxies the requests to your on-premises environment. It requires connectivity to your on-premises environment, and that environment must be fully functional. If either of those things is not true, the AD Connector will fail.

A major difference between the older SAAC01 exam and the newer C02 exam is that there are more questions about Windows environments. That’s why I’ve included this lesson on Directory Service. You need to be aware of all the products and services that can support and implement Windows environments within AWS and enable hybrid operations with your on-premises environments.

For the associate-level exam, the questions won’t be very challenging. They’ll focus on the high-level architecture, so you won’t need to know implementation details. That’s why this is a theory-only lesson. This lesson provides all the information you need to answer any directory service questions you might encounter on the exam.

At this point, that’s everything I wanted to cover. So go ahead, complete this video, and when you’re ready, I’ll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to talk about a really effective set of services which AWS provides for moving data between on-premises and AWS. These services are Snowball, Snowball Edge, and the AWS Snowmobile. Now we've got a lot to cover, so let's jump in and get started.

At a high level, the Snowball series—Snowball, Snowball Edge, and Snowmobile—are designed to move large amounts of data in or out of AWS. In many cases, especially with smaller projects, you can just upload data over an internet connection or, in some cases, if you have specific requirements, you can use Direct Connect. But there are situations where the amount of data that you need to move makes this impractical. This could be because of the speed of your internet connection making a transfer of this size impractical, or because you need to get huge amounts of data into AWS as quickly as possible.

Now, the devices in this product series are physical storage units—either suitcase-sized or the size of a truck, literally carried on trucks inside a custom-built shipping container. You can either order them empty, load them up with data, and then return them to AWS, or the reverse, so you can order them with data, receive them, empty off the data, and return the appliances to AWS.

The key things that you need to know for the associate exam are not specifically the product specifics, but rather when and where you need to use the products. So you don't need to be aware of the implementation details, just the architecture. That's what I want to cover in this lesson, and we're going to start with Snowball.

When you're using the Snowball product, it's actually a physical process—you're interacting physically with AWS, and so it's a device that you order from AWS, log a job, and the device is delivered to you, so it's not an instant process. Any data stored on a Snowball is encrypted using KMS, so there is encryption at rest. Anything that's persistently stored on that device is encrypted using KMS.

There are two types of Snowball devices. You can get a 50 TB device or an 80 TB device. In terms of network connectivity, you can connect to the Snowball using either 1 gig or 10 gig networking. That's important to make sure that you have that physical, cabled network connectivity wherever you get the Snowball delivered to because you will need to use physical networking.

While the capacity of the normal Snowball device is either 50 TB or 80 TB, the economical range for using Snowball is generally within the region of 10 TB to 10 PB of data. So if the amount of data that you need to transfer in or out of AWS is in that range, then it tends to be economical to use Snowball rather than transferring the data across the internet, Direct Connect, or any other connection technology. For large amounts of data, physical transfer using Snowball is often the most economical.

One of the benefits of using Snowball or Snowball Edge (which I'll cover next) is that you can order multiple devices. While it has a 50 or 80 TB capacity, and the economical range is 10 TB to 10 PB, you can order multiple devices and get them sent to multiple business premises. This is a really important architectural benefit: you could order 10 Snowballs and have one deployed into each of 10 business premises, using those devices to ingest data, send it back to AWS, and get that data accessible inside your AWS environment. So remember for the exam, multiple devices, multiple premises, and try your best to remember the economical range—10 TB to 10 PB.

Now, Snowball, as a device, only includes storage. It's only a storage device, and it doesn't include any compute capability. This is important because it's in contrast to the next product that I want to talk about, which is Snowball Edge. Snowball Edge comes with both storage and compute, so it's like the Snowball product, but in addition, it comes with compute capability. So architecturally, you tend to use Snowball when you've got large amounts of data to ingest or get out of AWS. With Snowball Edge, you’ve got some other architectural patterns that you can use that involve compute, and we’ll talk about that in a second.

Another benefit of Snowball Edge is that it has a larger capacity versus the Snowball product, and it also offers faster networking. You've got 10 gig over RJ45, 10 or 25 over SFP, and then 45, 50, or 100 over QSFP+, so whatever local connection technology you have, you can generally achieve faster connection to Snowball Edge versus Snowball.

There are actually three different types of Snowball Edge. First, we’ve got storage optimized, but there’s also a slight variant of the storage optimized series which includes EC2 capability. By default, the storage optimized version of Snowball Edge comes with 80 TB of storage, 24 vCPUs, and 32 GiB of memory, but if you include the EC2 capability option, it also comes with 1 terabyte of local SSD. So you can actually run EC2 instances on top of this using that 1 terabyte of SSD.

Now, we've also got compute optimized variants, which include 100 TB of storage plus 7.68 gig of NVME storage. This is storage directly attached to the PCI bus, it's super fast, and super low latency, which is beneficial when you've got aggressive compute requirements that you want to run on the Snowball Edge. The compute optimized also includes 52 virtual CPUs of capacity and 208 GiB of memory. Then finally, there’s also the compute optimized with GPU capability, which, in addition to all of those resources, also includes GPU capability. So for any scientific analysis, modeling, or any parallel activities that benefit from a GPU, you can also get the Snowball Edge with GPU capability.

In terms of when you’d use the Snowball Edge versus the Snowball: Snowball is an older generation, purely for storage. Snowball Edge includes compute, so if you've got any remote sites where you need to perform data processing on data as it's ingested, then you should use the Snowball Edge. If you’ve got higher capacity requirements, or need faster networking, or if you have a lot of data and need to make sure that you load it onto the device as quickly as possible, then by having the faster networking provided by the Snowball Edge, the turnaround time can be quicker.

The last piece of this product set is the Snowmobile, and the Snowmobile is a portable data center within a shipping container on a truck. I literally mean this: it is a truck that's delivered to your business premises, and on the back of this truck is a custom-designed shipping container. In that container is a portable data center, so this is a product that needs to be specially ordered from AWS. It's not something that's available in high volume and it's not available everywhere. It's generally only used when you have a single location with huge amounts of data that you need to ingest into AWS, such as when you’re dealing with large enterprises or performing a traditional data center migration of anything over 10 petabytes of data—that’s the type of scenario where you might use a Snowmobile.

Snowmobiles can actually store up to 100 petabytes of data per Snowmobile. The process is that you order a Snowmobile, it's driven to your data center location, and the back of the shipping container is opened up. They expect to connect into data center-grade power and data networking. Essentially, this is driven to your location, you plug it into your data center, and use it to transfer data into AWS.

For the exam, remember it's a single truck. Why this matters is that it's not economical for smaller than 10 petabytes or when you have multi-site migrations. You have to remember that this is one single device. So, if you have, for example, 10 petabytes of data, but that’s spread across lots of different sites, then logically, you would be using the Snowball Edge product. If you've got all this data on one single site, then potentially, it’s more economical to use the Snowmobile. You can't physically split a Snowmobile into multiple trucks. You can't do a road trip around your different data centers. A Snowmobile drives out to one location, it's plugged in, used to transfer data into, and then it drives off back to AWS.

So if your requirement is multi-site, then unless it really is a huge scale migration, you would not look to use a Snowmobile. These are the three different products: the Snowball, the Snowball Edge, and the Snowmobile. It will really benefit you in the exam to understand the exact set of requirements when you would and wouldn't use each of these products. I don't expect you to get any questions that test your knowledge in detail. You certainly won’t get any questions where you need to physically know the process of ordering and transferring, but from an architectural perspective, you will gain massive benefit from knowing the details of each of these products. That's what I've tried to do in this lesson.

With that being said, that is everything I wanted to cover in this lesson. Go ahead and complete the video, and then when you're ready, I look forward to you joining me in the next.

Welcome back, and in this final part of the Storage Gateway series, I want to talk about Storage Gateway running in file mode. So far, I've covered volume mode, where Storage Gateway handles raw block volumes, and VTL mode or tape mode, where Storage Gateway pretends to be a physical tape backup system. Running in file mode, as you can guess from the name, Storage Gateway manages files. Now, we have a lot to cover because this is one of the most feature-rich modes of Storage Gateway, so let's jump in and get started.

I want to stress one thing right at the start: for any Storage Gateway questions in the exam, if you see volumes mentioned, you should default to volume gateway. If you see tapes mentioned, default to VTL mode. If you see files mentioned, then default to file mode and only move away if you see something that eliminates any of those options. File Gateway bridges on-premises file storage and S3, linking local file storage to an S3 bucket. With a file gateway, you create one or more mount points or shares, which are available via two protocols: NFS (generally used for Linux servers and workstations) or SMB (a Windows network file-sharing protocol). These are another pair of keywords that will help you distinguish between volume gateway, tape gateway, and file gateway. So, if you see any mention of NFS or SMB with a Storage Gateway question that concerns files, you know it's going to be the file gateway.

These file shares or mount points you create within the file gateway map directly to one S3 bucket, which is in your account. You manage this S3 bucket and have visibility of it. This means that when you store files onto a mount point over SMB or NFS, they appear in the S3 bucket as objects. If you store objects into an S3 bucket, they’re visible on the corresponding mount point on-premises. This is essentially the key benefit of using Storage Gateway running in file mode: it translates between on-premises files and AWS-based S3 objects, which is super powerful from an architecture perspective. Like the other storage gateways, it typically runs on-premises, and to ensure performance, it also does read and write caching. This caching ensures that the performance achieved is comparable to anything else running on a local area network.

The file gateway isn't an overly complex product; essentially, what you see on screen is what it does. But where the power comes from is how it integrates with S3 and how you can take advantage of S3 features to implement some really useful architectures. Over the remainder of this lesson, I want to step through those architectures so that you can get some idea of how you can use it effectively in production and answer any questions relating to the file gateway that you might experience in the exam.

A typical architecture with file gateway starts with business premises on the left and AWS on the right. File gateway runs as a virtual appliance in most cases, and it has local storage that it uses as a read and write cache. This gives the data managed by the storage gateway near local area network performance. On the storage gateway end (on-premises), we create file shares, and each of these file shares is linked with a single S3 bucket running in your account. This link between a file share and an S3 bucket creates what's known as a bucket share. These file shares can be accessed from any local servers using NFS for Linux servers and SMB for Windows servers. If you're using a Windows share, you can also use Active Directory authentication for even better integration with a Windows environment.

The reason why file gateway is so powerful is because the file shares and the buckets are linked together. This means that S3 objects are visible in the file share and vice versa. Files on-premises map directly onto objects running in AWS, so there's a mapping between the file name and the object name. The structure of on-premises file shares is preserved by building that structure into the object name within S3, much like how S3 emulates a nested file system structure within a flat object storage system by building it into the object name. For example, a file called "winky.jpeg" on the left will be represented by an object called "winky.jpeg" inside the S3 bucket. Another file called "ruffle.png" inside the "omg wow" folder will be represented by an object called "/omg wow/ruffle.png," showing how a structure is emulated by building it into the object name.

You can have up to 10 of these shares per storage gateway, and crucially, the primary data is held on S3. The only thing stored locally is within the local cache, which holds data written or read from the storage gateway and is designed to improve performance to levels near those achieved from any other resources running on a local area network. Because the objects are stored within S3, you have the ability to integrate with other AWS services. You can use S3 events and Lambda, as well as other AWS services such as Athena. Anything that can use S3 as a source location will have access to any files stored on S3 indirectly using the file gateway.

At a high level, this is the architecture of a file gateway: it allows you to extend your local file storage into AWS using S3. If you see the keyword "file" in the exam, possibly with the keyword "extension," a possible answer is the Storage Gateway running in file mode. However, the product goes far beyond this. The reason it’s my favorite mode of Storage Gateway is because it enables some really cool hybrid architectures. The architecture shown on screen now is a simple two-site hybrid architecture with on-premises on the left and AWS on the right.

In this architecture, we still have the Storage Gateway in the on-premises environment on the left, and there's still the one-to-one relationship between the files presented by the Storage Gateway and the object in the S3 bucket. But we can add another on-premises environment at the bottom, and this environment also presents the same set of objects from the same bucket as files. There are some concerns to keep in mind. First, when you update a file on a local storage gateway, that update is copied into S3 automatically. But to save on resource usage and avoid unnecessary S3 listings, there's no automatic version of that in reverse. When you list the file share on-premises, you're listing the most recent copy of the S3 bucket that the gateway is aware of. For example, if you added a new cat picture to the top storage gateway, that would create a new object immediately in the S3 bucket. However, if you then listed the file share in the bottom on-premises environment, it wouldn't show until you initiated a listing.

There’s a feature of Storage Gateway called "notify when uploaded." I'll make sure to include a link to the lesson detailing this functionality, but at a high level, this sends an event using CloudWatch events to inform other Storage Gateways when an update has occurred. However, this needs to be designed into your solution—it doesn't occur by default. Another point to be aware of is that File Gateway doesn’t support any form of object locking. This means that if two users are editing the "winky.jpg" file in the top and bottom environments and they both write, there isn’t any form of checking or control over this access. This can result in data loss, where one update overwrites another. So either make sure that one of the shares is read-only and the others are read-write or implement some form of control on who accesses files and when.

Another powerful architecture supported by Storage Gateway in file mode is replication. Given this architecture, where we have two customer sites linked to the S3 bucket in US East 1, we could create another bucket in, say, US West 1 and then configure cross-region replication of that data between the two buckets. This gives us a nice way to implement multi-region disaster recovery without any significant changes to infrastructure or much in the way of additional costs. We can also use File Gateway and S3 lifecycle management together.

Let’s say we have this architecture with on-premises on the left and AWS on the right. Using File Gateway means that the files and objects remain in sync because it’s using S3. There are different storage classes available for objects, such as S3 Standard, S3 Standard Infrequent Access, and S3 Glacier. When you create a file share, you specify the default storage class to use, usually S3 Standard. However, on top of this default, you can create lifecycle policies within an S3 bucket, maybe configuring them to move objects from Standard to Standard-IA after 30 days. Behind the scenes, objects are moved automatically between these two classes, and because this is an automatic process, it repeats as additional objects reach a certain age. More objects move between these different storage classes. Multiple steps are allowed, so in addition to the move after 30 days to Standard-IA, you could also have a 90-day move to Glacier, meaning objects over time move to cheaper storage. This process happens in the background automatically, making it cost-effective, and because the primary copy of all data is in S3, any on-premises locations automatically benefit from this cost-effective storage system.

File Gateway is a really cool product, but to fully appreciate it, it helps to experience it in practice. For the exam, though, this lesson has covered everything you’ll need. I’ve covered all the main features and architectural patterns of File Gateway. For the exam, try to make sure that you're familiar with when you'd use each type of Storage Gateway—when it makes sense to use volume stored or when it makes sense to use volume cached, what situations VTL mode is useful in, and the same question for File Gateway. If you’re in doubt, come and talk to me on techstudieslack.com, and we can discuss this in more detail. But with that being said, thanks for watching. Go ahead, complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson of the Storage Gateway series, I wanted to cover Storage Gateway running in Tape mode, also known as VTL mode, which stands for Virtual Tape Library. Now, try your best as you go through this lesson to ignore the fact that the logo looks like a toilet roll. It's one of those things where once you've seen it, it can't easily be unseen. I also often forget that there might be some of my students who don't actually know what Tape backup is, so I want to quickly cover that before I show you how Storage Gateway can integrate Tape backups and AWS. So, let's jump in and take a look.

Large enterprise backups in recent times tend to run in one of three ways: backup to Tape, backup to disk, or off-site backup to a remote facility over a network link. For this lesson, we're focusing on Tape backup. Now, there are various different types of tapes, and one popular type is called LTO, which stands for Linear Tape Open. This is an example of some LTO tapes. They come in various different generations, and one of the more recent is LTO 9, which is capable of storing 24 terabytes of data per tape, and this is uncompressed data. If you add compression, it allows for storage up to 60 terabytes per tape.

All Tape backup solutions have at least one Tape drive. A Tape drive can logically be empty or have a tape inserted. Assuming it does have a tape inserted, then the Tape drive can read from the tape or write to the tape, and it's sequential, meaning not random access like disk or SSD-based storage. Now, to find data, you need to seek through the entire tape, locate the data, and then read it. Data that's stored on tape can't easily be updated. You need to overwrite the data that's already on that tape. It's not really possible to modify data stored on tape. Essentially, it's designed as a medium that allows write as a whole or read as a whole.

Now, as well as a tape drive, you have what's known as a Tape loader, sometimes called a Tape robot. Think of this as a literal robot arm, which can insert tapes, remove tapes, or swap tapes between a drive and somewhere else. Now, a tape library is a piece of equipment that often fits in a rack or is the size of one or more racks. It contains one or more tape drives, one or more tape loaders (the robots which move tapes), and a collection of slots, and these slots can store tapes when they're not in the drive. So, a tape library could have room for eight tapes, 32 tapes, hundreds of tapes, or even thousands of tapes.

So, when we're discussing tape backup, we've got a number of different components. We've got the drive itself, where tapes go to be read from or written to. Next, we've got the library, and the library consists of a tape drive or tape drives, the robots, and a number of slots that can store tapes when they're not in the drives themselves. And then, thirdly, we've got a tape shelf. Now, this is a throwback to the physical world where tapes were stored on shelves. If you see a tape shelf mentioned, it's anywhere that isn't the library, so another location that could be in the same building or a different physical site entirely.

In a traditional tape backup situation, this is what the architecture might look like. On the left, we've got a business premises, and inside it, we've got a number of application and data storage servers, which aren't shown, together with a backup server and a tape library. Now, the backup server connects to the tape library using a protocol known as iSCSI, and this iSCSI connection exposes a few devices, the most important ones being one or more tape drives and a media changer. A media changer is just another name for a tape loader or a tape robot.

Now, the important thing to realize is that everything has a cost, so the equipment costs money to buy—that's the tapes, the software, and the library—and their capital expenditure costs. Then, to operate it, there's ongoing costs such as licensing, maintenance, and staffing costs. It's not cheap to run an enterprise-grade backup architecture such as the one that's on screen now. In addition to this, we have the other side of the architecture—off-site tape storage, which is often managed by a third party. This location is often a decent distance away from your primary business premises, and this is done to provide resilience in the event of a disaster.

Now, only tapes that are in the library itself can be used for backups, and to keep data safe, any tapes that aren't being actively used are moved from your primary premises to off-site tape storage, and this transport costs money and takes time. So, we have a few main problems with this architecture: we have the cost to purchase, the cost to maintain, the cost to operate, and the time and cost to move things around between our primary premises and our off-site tape storage. Storage Gateway running in VTL or tape mode fixes many of these problems, so let's take a look at how.

Using Storage Gateway in VTL mode, much of the architecture changes. About the only thing that is shared is that we still have a business premises and a backup server. Instead of the on-premises tape library, we use Storage Gateway in tape or VTL mode, and this presents itself in the same way to the backup server using iSCSI. Now, this is actually part of the design: the backup server sees this as a normal tape loader; it doesn't know the difference between this and the previous physical tape library. There are very little, if any, software changes required beyond connecting the backup software to the Storage Gateway.

The Storage Gateway presents a media changer and the tape drives, but it looks like a normal physical tape library. However, it has an upload buffer and a local cache, much like Volume Gateway running in cache mode. It uses these to store data that is being actively used, essentially virtual tapes, and I'll talk about these in a second. Instead of using physical tapes, which are present in a local tape library, the Storage Gateway communicates with the Storage Gateway endpoint within AWS. This is much like the Volume Gateway. The Storage Gateway endpoint then presents two main capabilities: the Virtual Tape Library (VTL), which is backed by S3, and the Virtual Tape Shelf (VTS), which is backed by either Glacier or Glacier Deep Archive.

Now, conceptually, the Virtual Tape Library is an AWS-hosted version of a tape library, which the Storage Gateway uses, and the Virtual Tape Shelf is for virtual tapes that have been logically moved out of that Virtual Tape Library. So, the on-premises Storage Gateway communicates with the Virtual Tape Library, caches stuff locally, and uploads in the background to the Virtual Tape Library. So, backups occur at LAN speeds to the local storage that the Storage Gateway uses, and then in the background, any backup data gets uploaded to the Storage Gateway endpoint running inside AWS, specifically the Virtual Tape Library.

Now, a virtual tape can be anywhere from 100 gig to 5 terabytes. If you have a good memory, you might notice that the 5 terabyte maximum size for a virtual tape is also the maximum size of an S3 object, and that's because these virtual tapes are stored using S3 in an AWS-managed Storage Gateway bucket. Now, the Storage Gateway can handle a total of one PB of data across 1500 virtual tapes within the Virtual Tape Library. Remember, this is the part which uses S3.

When virtual tapes aren't being used for anything, they can be exported within the backup software, and this marks them as not being within the library. Now, in the physical architecture, which I showed you on the previous screen, this would then mean ejecting them from the physical tape library and moving them to off-site storage. An exported tape simply means that it's not in the library. Now, when you export a virtual tape using Storage Gateway in VTL mode, it archives it from the Virtual Tape Library (VTL) into the Virtual Tape Shelf (VTS), and this moves the data from S3 into Glacier or Glacier Deep Archive, which offers unlimited storage.

The limit of this Storage Gateway appliance is only for tapes that are stored in the Virtual Tape Library. Anything which you archive into the Virtual Tape Shelf benefits from unlimited amounts of capacity. Now, Glacier is generally used for archival when there's an expectation that at some point you will need access to the data, so anything that's infrequently accessed can be archived into the Virtual Tape Shelf using Glacier. Glacier Deep Archive is used for longer-term data retention, where you might never need to access the data again, but you do need to keep it, maybe for legal reasons. In either case, if you need to access the data again, then it can be retrieved from the Virtual Tape Shelf into the Virtual Tape Library, and then it can be accessed again by the Storage Gateway.

Now, I'm hoping by this point that you understand what this mode of the Storage Gateway provides. It essentially pretends to be an iSCSI tape library, an iSCSI changer, and an iSCSI drive, and it uses a combination of S3, Glacier, and Glacier Deep Archive to support the backup and restore functionality of a physical tape library. Now, this gives you a few interesting capabilities. You can use it to maintain your existing backup system, which you might need to keep, but replace much of the expensive parts with economical AWS storage. It also allows you to extend an additional backup system by using capacity within AWS, so you can use this together with existing backup software and extend any limited on-premises capacity into AWS by using S3 and Glacier.

Or, it also lets you do a migration. So, let's say that you're migrating everything into AWS, but you need to maintain a historical set of tape backups. Well, you can migrate those tape backups onto Storage Gateway using VTL mode, decommission the physical tape hardware, and then even run the Storage Gateway appliance and the backup server from within AWS for any data retrieval needs. So, this type of Storage Gateway presents some really interesting architectural possibilities.

For the exam, anything which involves traditional tape backup architecture, then Storage Gateway running in VTL mode is likely to be the correct answer. VTL mode is a really powerful product, which I've used a few times in real-world projects, generally as part of data center extensions or migrations of backup platforms. But at this point, that's everything that I wanted to cover about Storage Gateway running in VTL mode. So, thanks for watching. Go ahead and complete the video, and I'll look forward to you joining me in the next part of this Storage Gateway series, where I'll be covering the file gateway, which is probably my favorite Storage Gateway mode.

Welcome back.

Over the next few lessons, I'm going to be covering Storage Gateway in more depth, focusing on the types of architectures it can support. The key to exam success when it comes to Storage Gateway is understanding when you would use each of the modes, as each has its own specific situation where it should or shouldn't be used. In this lesson, I'll start off with the Storage Gateway running in Volume Stored mode and Volume Cached mode—so let's jump in and get started.

Storage Gateway normally runs as a virtual machine on-premises, although it can be ordered as a hardware appliance. However, it's much more common to use the virtual machine version of this product. It acts as a bridge between storage that exists on-premises or in a data center and AWS. Locally, it presents storage using iSCSI (a SAN and NAS protocol), NFS (commonly used by Linux environments to share storage over a network), and SMB (used within Windows environments). On the AWS side, it integrates with EBS, S3, and the various types of Glacier.

As a product, Storage Gateway is used for tasks such as migrations from on-premises to AWS, extending a data center into AWS, and addressing storage shortages by leveraging AWS storage. It can implement storage tiering, assist with disaster recovery, and replace legacy tape media backup solutions. For the exam, you need to identify the correct type of Storage Gateway for a given scenario—and that's what I want to help you with in this set of lessons.

As a quick visual refresher, a Storage Gateway is typically deployed as a virtual appliance on-premises. Architecturally, you might also have some Network Attached Storage (NAS) or a Storage Area Network (SAN) running on-premises. These storage systems are used by a collection of servers—also running on-premises. The servers probably have their own local disks, but for primary storage, they're likely to connect to the SAN or NAS equipment.

These storage systems (SANs or NASs) generally use the iSCSI protocol, which presents raw block storage over the network as block devices. The servers see them as just another type of storage device to create a file system on and use normally. This is a traditional architecture in many businesses. What's also common, especially for smaller businesses, is limited funding for backups or effective disaster recovery, prompting them to consider AWS as a solution to rising operational costs or as an alternative to maintaining their own data centers.

So how does Storage Gateway work? Volume Gateway works in two different modes: Cached mode and Stored mode. They are quite different and offer distinct advantages. First, let's look at Stored mode. In this mode, the virtual appliance presents volumes over iSCSI to servers running on-premises, functioning similarly to NAS or SAN hardware. These volumes appear just like those presented by NAS or SAN devices, allowing servers to create file systems on top of them as they normally would.

In Gateway Stored mode, these volumes consume local capacity. The Storage Gateway has local storage, which serves as the primary location for all the volumes it presents over iSCSI. This is a critical point for the exam—when you're using Storage Gateway in Volume Stored mode, everything is stored locally. All volumes presented to servers are stored on on-premises local storage.

In this mode, Storage Gateway also has a separate area called the upload buffer. Any data written to the local volumes is temporarily written to this buffer and then asynchronously copied into AWS via the Storage Gateway endpoint—a public endpoint accessible over a normal internet connection or a public VIF using Direct Connect. The data is copied into S3 in the form of EBS snapshots. Conceptually, these are snapshots of the on-premises volumes, occurring constantly in the background without human intervention. That's the architecture of Storage Gateway running in Volume Stored mode. Think about the architecture and what it enables, because this is what's important for the exam.

This mode is excellent for doing full disk backups of servers. You're using raw volumes on the on-premises side, and by asynchronously backing them up as EBS snapshots, you get a reliable full disk backup solution with strong RPO and RTO characteristics. Volume Gateway in Stored mode is also great for disaster recovery, since EBS snapshots can be used to create new EBS volumes. In theory, you could provision a full copy of an on-premises server in AWS using just these snapshots.

However—and this is important for the exam—this mode doesn't support extending your data center capacity. The primary location for data using this mode is on-premises. For every volume presented, there's a full copy of the data stored locally. If you're facing capacity issues, this mode won't help. But if you need low-latency data access, this mode is ideal, as the data resides locally. It also works well for full disk backups or disaster recovery scenarios.

I emphasize “full disk” here because in the next lessons, I’ll cover other Storage Gateway modes that also help with backups. Volume Gateway deals in volumes—raw disks presented over iSCSI. Some key facts worth knowing (though not required to memorize for the exam): in Volume Stored mode, you can have 32 volumes per gateway, with up to 16 TB per volume, for a total of 512 TB per gateway.

Now let’s turn to Volume Gateway in Cached mode, which suits different scenarios. Cached mode shares the same basic architecture: the Storage Gateway still runs as a virtual appliance (or physical in some cases), local servers are still presented with volumes via iSCSI, and the Gateway still communicates with AWS via the Storage Gateway endpoint, which remains a public endpoint using either internet or Direct Connect.

The major difference is the location of the primary data. In Cached mode, the main storage location is AWS—specifically S3—rather than on-premises. The Storage Gateway now only has local cache, while the primary data for all presented volumes resides in S3. This distinction is crucial: in Volume Stored mode, the data is stored locally; in Cached mode, it’s stored in AWS and only cached locally.

Importantly, when we say the data is in S3, it's actually in an AWS-managed area of S3, visible only through the Storage Gateway console. You can’t browse it in a regular S3 bucket because it stores raw block data, not files or objects. You can still create EBS snapshots from it, just like in Stored mode.

So the key difference between Stored and Cached modes is the location of the data. Stored mode keeps everything on-premises, using AWS only for backups. Cached mode stores data in S3, caching only the frequently accessed portions locally. This offers substantial architectural benefits: since only cached data is stored locally, you can manage hundreds of terabytes through the gateway while using only a small local cache. This enables an architecture called data center extension.

For example, imagine an on-premises facility with limited space and rising storage needs. Instead of investing in more hardware, the business can extend into AWS. Storage in AWS appears local, but it's actually hosted in the cloud. While Volume Stored and Cached modes are similar in using raw volumes and supporting EBS snapshots, only Cached mode enables extending data center capacity.

Stored mode is for backups, DR, and migration. It ensures local LAN-speed access, but requires full data storage locally. Cached mode allows AWS to act as primary storage, storing frequently accessed data locally, enabling cost-effective capacity extension while maintaining low-latency access for hot data. Less frequently accessed data may load more slowly, but it allows huge scalability. In Cached mode, a single gateway can handle up to 32 volumes at 32 TB each—up to 1 PB of data.

In summary, both modes work with volumes (raw block storage), but Stored mode stores everything locally and uses AWS only for backups, while Cached mode stores data in AWS and caches hot data locally, supporting data center extension. For the exam, if you see the keyword “volume” in a Storage Gateway question, you’re dealing with Volume mode. Deciding between Stored and Cached will depend on whether the scenario focuses on backup/DR/migration or on extending capacity.

That wraps up the theory for this lesson. In the next lesson, I’ll cover another mode of Storage Gateway: Tape mode, also known as VTL mode. Go ahead and complete this lesson, and when you’re ready, I look forward to having you join me in the next.

Welcome back and in this lesson I want to talk about the AWS Transit Gateway known as TGW. Now this is a product that I remember being super excited about because at the time there was a massive hole in the hybrid network capability on the AWS platform. Transit Gateway answered a lot of the complexity issues which plagued AWS in this space. Now understanding why the Transit Gateway is such a valuable product means focusing both on the features it provides as well as how it can help evolve network architectures and that's something I'll attempt to do in this lesson. Now we do have a lot to cover so let's jump in and get started.

The Transit Gateway is a network transit hub which connects VPCs to each other and to on-premises networks using site-to-site VPNs and Direct Connect. It's designed to reduce the complexity of network architectures within AWS. It's a network gateway object so another one that you need to remember and like other network gateway objects it's highly available and scalable. The architecture is that you create attachments which is how Transit Gateway connects to other network objects within AWS and it's how it connects to on-premises networks. Currently valid attachments include VPC attachments, site-to-site VPN attachments and Direct Connect gateway attachments.

Now to understand why Transit Gateway is required it's useful to compare a moderately complex network architecture and see how Transit Gateway affects that complexity. So let's do that. Let's use Animals for Life as an example and let's assume that the Animals for Life network has evolved and they have four VPCs—A, B, C and D—as well as a corporate office. Now we want to connect these together so that every point has connectivity to every other point in a fully highly available way. We can use VPC peering connections to connect the four VPCs and these are already highly available and scalable. But as you know they don't support transitive routing and so we need to create a full mesh between all VPCs. So rather than four peering connections we'd need to have six. That's already six connections that we need to plan, implement, manage and support, but that's not everything that we need for this architecture.

We need the corporate office to be connected to all of the VPCs and because VPN routing isn't transitive we need a full mesh here as well. This means a customer gateway on the customer side and VPN connections between the VPCs and that customer gateway. So that's a total of eight tunnels, two tunnels from each of the VPCs to the customer gateway of the Animals for Life corporate office. This ensures high availability at the AWS side. But remember we need this architecture to be fully, highly available and we currently have a single point of failure: the customer gateway on the customer side. While we have multiple availability zones at the AWS side all connecting back to the customer premises, they all do so via this single customer gateway. And so to make this architecture fully, highly available we need to add another customer gateway on the customer premises—ideally using a separate internet connection and ideally in a separate premises entirely—and then have that customer gateway connected back to all four of these VPCs. So that adds another eight tunnel connections.

Now I'm hoping at this point that you start to see the problem. A full mesh network is complex. It has a lot of admin overhead to implement and to maintain. And what's more, it scales really badly. The more networks are involved, the more networks get added each time a new network is added. It's a problem which gets worse the more you scale. So in addition to getting more complex, that increase in level of complexity itself increases the more that you scale. So this is not a solution that we can use much beyond this point. If we add additional VPCs or additional customer premises, it gets really complex really quickly. And that's where the transit gateway becomes really useful.

Now using Transit Gateway, we start with the same basic architecture: four VPCs—A, B, C and D—and then the corporate premises with the two customer gateway routers. This time though, we have a Transit Gateway which we create within the Animals for Life AWS account. A Transit Gateway can use a site-to-site VPN attachment meaning it becomes the AWS side termination point for the VPN. So rather than having to have connections between the corporate office and every VPC terminated on a virtual private gateway, instead each customer gateway only has to be connected back to this single Transit Gateway. So we have the same level of high availability. We still have the four tunnels connected from different availability zones at the AWS side to different customer gateways at the on-premises side. So we don't lose any high availability with this solution, but we do reduce the number of VPN tunnels that are required.

With the Transit Gateway, you can also create attachments to VPCs and just like VPC interface endpoints that you used earlier in the course, you need to specify a subnet in each availability zone inside the VPCs that you want to use the Transit Gateway with. And when you do that, it acts as a highly available inter-VPC router. So one single Transit Gateway can route traffic between lots of different VPCs and this is a transitive routing capable device. So we only need attachments from the Transit Gateway to VPC A, B, C and D, and then all of the VPCs can talk to each other through the Transit Gateway. In addition to allowing full connectivity between all of the VPCs, because we have the VPN attachment, it means that all of the VPCs can communicate with the on-premises environment as well as the on-premises environment being able to communicate with all of the individual VPCs using this single network routing device—the Transit Gateway.

And in addition, you can also peer Transit Gateways with other Transit Gateways in other accounts in other regions. So you can use this to peer with networks that themselves are connected to the peer Transit Gateway and those can be in other AWS regions and even across accounts. And this is a really useful feature to create a global network within AWS. Any cross-region data uses the AWS global network and so benefits from the more predictable latency rather than using the public internet. And in addition, you can also attach a Transit Gateway to Direct Connect gateways if your business uses Direct Connect. And so this allows you to use the Transit Gateway as well with physical, private networking connections into your business premises. And I'll be covering this specific feature in a dedicated lesson elsewhere in the course.

Transit Gateways come with a default route table, which is how traffic is routed between attachments. But you can create a complex routing topology by using multiple route tables. So before we finish this theory lesson, just some important considerations that you should be aware of for the Transit Gateway. It does support transitive routing, which means that you don't need to create this full mesh topology. You can have a single Transit Gateway with multiple attachments and it will orchestrate the routing of traffic between any of those attachments as long as appropriate routing is in place. So you need route tables with routes on them in order for the Transit Gateway to route traffic between its different attachments. But assuming you do, then it's capable of transitive routing.

Transit Gateway can be used to create global networks. I've just talked about that. You can peer different Transit Gateways. And again, you need to be aware of this for the exam. You can share Transit Gateways between different AWS accounts using AWS RAM or Resource Access Manager. I've not covered that product yet in the course, but it's an AWS service which allows you to share products and services or components of products and services between different AWS accounts. Again, you can peer Transit Gateways with different regions in the same or cross accounts. So remember that one for the exam. It doesn't have any limitations in terms of region or accounts. You really can use it to create really complex, highly efficient routing topologies.

Now, overall, the thing to remember about the Transit Gateway is it offers much less complexity in terms of network architectures than without Transit Gateway. So instead of having to use multiple VPC peers and then a full mesh topology in terms of VPN connections, you can use this one single resilient, scalable, highly available device to perform transitive routing between all of your different networks. And that results in a massive reduction of network complexity.

Now, there's going to be a demo lesson in this section of the course. Well, you'll get the opportunity to implement a Transit Gateway inside your AWS account. You'll get to experience using a Transit Gateway instead of VPC peering connections to link different VPCs together. But with that being said, that's all of the theory that I wanted to cover in this lesson. So go ahead, complete this video. And when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson I want to talk about how you can use Direct Connect, Public VIFs, and IPsec VPNs to provide end-to-end encrypted access to private VPC networks across Direct Connect. Let's just jump in and get started covering this really useful feature of Direct Connect and virtual private gateways.

Now, using a VPN gives you an encrypted and authenticated tunnel, and this is true whether you use the public internet or run a VPN over Direct Connect. By running a VPN over Direct Connect, though, you get that plus low latency and consistent latency. You get great performance together with great security.

Now architecturally, this uses a public VIF, and many students get confused by this because it provides access to a private VPC—so why not use a private VIF? Well, remember I said that a private VIF gives access to private IPs only. A public VIF gives access to public zones, meaning public IP addresses owned by AWS. Well, with a VPN, what you're connecting to are public IPs which belong to a virtual private gateway or transit gateway, and so to access these public IPs, you need a public VIF. When you're thinking about VIFs, focus on what it is that you're trying to access, and that should inform you whether you should use a public VIF or a private VIF.

Now a VPN is great because it's transit agnostic. You can connect using a VPN to a virtual private gateway or a transit gateway over the public internet or over a public VIF. The VPN configuration is the same—it's just the transit which differs: public internet or public VIF. A VPN is end-to-end encryption from a customer gateway through to a transit or virtual private gateway.

Compare this to MaxSec, which I've covered in another lesson of the course, which is single-hop based between the AWS DX router and whatever your cross-connect is terminated into. I say this so that you understand that a VPN and MaxSec are not competitors—they do different things. A VPN provides an end-to-end encrypted tunnel between a customer gateway and an AWS virtual private gateway or transit gateway, and a MaxSec connection is between two hops in the same layer two local area network.

VPNs have wide vendor support. Getting a router which supports IPsec VPN is easier than getting a switch which supports MaxSec, although this will change over time. VPNs also have more cryptographic overhead versus MaxSec, meaning VPN speeds tend to be very limited based on the hardware that you use. MaxSec is much faster and designed for terabit or above network speeds.

Now one very common pattern for using an IPsec VPN and Direct Connect together is that a VPN can be provided immediately in minutes using software, whereas Direct Connect takes time. This means you can start with a VPN, get your traffic flows working over that, and then add a Direct Connect later—either leaving the VPN in place to encrypt primary traffic over the Direct Connect, or using it as a backup to the Direct Connect, or both.

A common form of resilience in many of my clients is to have a normal internet connection; over this you also run an IPsec VPN into AWS. Then you have a Direct Connect also running another IPsec VPN tunnel. This way, traffic is always encrypted. The Direct Connect is the primary, so the organization benefits from great performance, and you have a backup in the form of a completely separate network connection and a completely separate IPsec tunnel.

Now visually, the architecture of using a VPN and Direct Connect looks like this. So this is a typical architecture: we have two AWS regions on the left—US East 1 at the top and AP Southeast 2 in the middle. We also have a Direct Connect location in AP Southeast 2 in the middle of your screen and a business premises on the right. When using a VPN with AWS—in this case, let's assume that we're going to use a virtual private gateway—what actually happens is that two VPN endpoints are created within the AWS public zone in that region, so one in each of two availability zones, and these endpoints have public addressing.

This means that you can either connect from the customer site to these endpoints using the public internet for transit, which means lots of hops as well as a fairly varied latency, or you can create the IPsec VPN across the public VIF, which means you'll benefit from Direct Connect low and consistent latency. In both cases, it's the same encrypted tunnel between the customer on-premises gateway and the AWS VPN endpoint. Only using a Direct Connect means using a public VIF as transit, so you'll benefit from the performance improvements that Direct Connect provides.

You can even connect to VPN gateways in other AWS regions using the same public VIF across the AWS global network, and this is often a great way to provide global encrypted transit between VPCs and your business network. What I want you to take away from this lesson is that IPsec running over a Direct Connect doesn't compete with MaxSec. VPN is when you need end-to-end encryption of data from AWS to on-premises networks using something which can work equally as well over the public internet and the public VIF. It also means that you can connect to VPCs in remote regions using the same grade of equipment.

Focus on understanding why we're using a public VIF with this architecture: because we're connecting from the customer gateway to a public IP or public IPs which are provided by the virtual private gateway or transit gateway. Because we're connecting to public IPs, we need to use a public VIF. With that being said, that's everything I wanted to cover about this topic. Go ahead and complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back. As an architect, you need to understand the impacts of failures at various points within the DX architecture and the way that it integrates with your on-premises networks. So let's jump in and get started because we've got a lot to cover.

Now before we start looking at how resilience works with Direct Connect, let's review an architecture which is not resilient. Now, worryingly, this is actually the way I've seen most people provision Direct Connect. A typical DX deployment has a number of physical components. First, the AWS region. Think of this as the actual infrastructure that AWS uses to deliver services in that region. Secondly, a Direct Connect or DX location, which is typically a data center in the geographic area that the region is in. Now there are often multiple DX locations in a single region and these are generally located within a major data center in a metro area. And the last typical component in most architectures is the customer premises. So your office buildings or self-managed data centers.

Now architecturally, I want you to think of the AWS region as a separate thing in terms of Direct Connect architecture. So an AWS region is connected to all of the DX locations in that region using multiple high-speed network connections. Now you can assume that this part is always highly available. So while the region and DX location are conceptually different, they're always connected with high performance, highly available networking. Now inside the DX location, which remember is a data center, are a collection of AWS DX routers and these conceptually are connected to the AWS region. So picture a DX router, which is the exit point of the AWS network.

When you order a DX connection within your AWS account, what you actually receive is a port on a DX router at a DX location. Now ideally, you'll also have equipment at this DX location and this is referred to as the customer DX router. If not, you'll need to purchase a service from a communications provider and use one of their routers, which is also going to be at the DX location. But in either case, there's another router inside the DX location, the customer or provider DX router. So when you order a DX connection, you're allocated a port on the AWS DX router and you need to arrange a connection between this port and a port on your customer DX router or provider DX router. And this process, this cable is called a cross connect and it's a single cable between both of these routers.

In addition to this, generally you'll also want to connect the DX location back to your company network. If you're a large company, you might have lots of capacity at the same data center that the DX location uses. But if not, you'll need to extend this back into your own on-premises network. Generally, you'll have a customer premises router and you'll pay a carrier or a telco provider to extend the direct connect from the customer or provider DX router all the way back through to your on-premises network. So to summarize, the AWS region is linked in a highly available way to one or more DX locations. The DX location houses the AWS DX routers in addition to your or a provider's DX router and you cross connect from the AWS DX router into your DX router with a physical cable. And then all of this is extended to your on-premises environment.

So what can go wrong with this architecture? Well, there are actually seven single points of failure on this diagram. There are actually more, but seven that I would be directly concerned about if I was implementing direct connect. The first is the entire DX location could fail. You can have power failures, buildings can and often do collapse. The AWS DX router could fail either in isolation or along with the building. The same for the cross connect. It's just a cable. Cables do fail. Your DX router could fail and what if you don't have an on-site spare? The extension from the DX location to your on-premises environment. It's just a cable. It probably goes under the road or across above ground cables and any engineering works can potentially be a risk to the stability of that cable. You might also have a failure of your actual customer premises environment or your customer premises router within that environment could also have a hardware failure.

When people think about direct connect for some reason, they have a perception that it's a resilient product. It's actually not resilient in any way by default. It's a product which is based on lots of physical components which each depend on each other. But it's also a product that's designed to be flexible. So it can actually be made into a super resilient service. Let's look at that and now that you know about the architecture details, I can speed up and zoom out a little.

Now we can improve the resilience of the architecture by provisioning multiple DX ports. So we start with the same architecture at a high level. The AWS region on the left, the DX location in the middle and the customer premises on the right. Now there are actually multiple points of connection within each DX location. If you have multiple routers in the DX location, you can configure multiple cross-connects into multiple DX ports. And from there you can extend those into multiple customer premises routers using extensions.

So this architecture has two AWS DX routers, two customer DX routers and two customer premises routers. So when you're ordering direct connect, if you order two direct connects into the same DX location, then AWS will provision these onto separate DX routers and that gives you a level of resilience. Now this architecture adds significant benefits because we have the two independent DX ports, two DX routers and two customer routers. The architecture can tolerate a failure of a router in either of those two paths or a failure of one of the extensions and still continue operating.

The design does have some problems though. Some single points of failure do still exist. If the DX location itself fails, then connectivity is lost and since all connectivity goes via a single customer location, if that single customer location fails, then connectivity to the AWS platform is also lost. So we still have two fairly major single points of failure, the two locations that are involved in this private networking. We also have a potentially hidden single point of failure with this architecture and this occurs because the extensions between the DX location and the single customer premises location could in theory travel via the same physical cable route. So if you order multiple connections between two physical locations, then generally the cable route for both of those connections could be the same. This isn't always the case but it's something to be very aware of.

I've seen many businesses build this type of architecture. They assume a high level of resilience only to find that both of their independent cables enter their building under the same sidewalk and both of those cables were broken by roadworks occurring on that same sidewalk. So to prevent this, we need another step of evolution in terms of resilience. We can't have any single points of failure if the private networking is important to our organization. So let's look at a better version of this architecture, another evolution in terms of resilience.

So at a high level, we still have the AWS region on the left but now we have two independent customer premises on the right. So two completely different buildings, ideally two buildings that are spread out geographically. In addition, we have two different DX locations. In each DX location, we're going to provision one DX port that's cross-connected into one customer DX router and each of these is going to be extended into a different customer router in a different customer premises.

If we architect the solution this way, it offers much better resilience than the previous architecture. We've got two different DX locations, meaning the architecture can tolerate the failure of one of these locations and still continue to operate. Because there are two customer premises and two customer routers, it can also tolerate the failure of hardware and location at the customer side. The only risk of outage is if an entire location fails and then the hardware in the remaining path also fails. So with this architecture, if we had hardware failure in DX location one, the solution would continue to run. If the entire DX location one failed, the solution would continue to run. If both DX location one and the customer premises one failed, the solution would still provide connectivity. Only if we had all of that fail and then in addition, if we had hardware failure in DX location two or customer premises two, would the connectivity be interrupted.

But we can take this one step further and implement an architecture designed for extreme levels of resilience. This next design offers maximum resilience. We still have the AWS region on the left, the two DX locations in the middle and the two customer premises environments on the right. However, this time in each of the DX locations, we have two DX ports on separate equipment. And then in each location, we also have two customer DX routers. This provides a level of resilience within each location covering hardware failure and resilience against the failure of an entire location.

So at each location, we have a pair of cross-connects between the AWS DX router and the customer DX router. And then these are all extended to dual customer routers at each of the customer premises locations. So this architecture gives us extreme levels of resilience. We have high availability from a direct connect location perspective. One can fail and the connectivity is still active because we have infrastructure in both. Inside each DX location, we have a pair of both AWS DX routers and customer DX routers. So even if one DX location fails, we could still lose one pair of those in the remaining DX location and still the connectivity would be fine.

The extensions from the DX location to the customer premises because they're going between two completely different locations at both sides will generally follow two completely separate routes. So this is because the starting and the end points of those connections are to different physical buildings, which means the extensions themselves and the customer premises are going to be highly available. And inside each of the customer premises because we're using multiple customer routers, these are also highly available.

Now this is relatively complex network architecture and the thing that I want you to take away from this lesson from an exam perspective and if you intend to use direct connect in real world projects is that direct connect is a physical technology and so it is not resilient in any way unless you architect it that way. So if you just provision a single direct connect, it will be a single port on a single DX router at a single DX location. You'll cross connect it to a single customer DX router, extend it to a single customer premises with a single customer router. Each step of that process will be a single pointer failure.

If you want something that is highly available and you need to use direct connect, then you need to consider one of the more resilient solutions that I've demonstrated in this lesson. Now you can also use site to site VPN as a backup for direct connect and I've explained exactly how this works in another lesson in this section of the course, but generally if you do need to use direct connects only for a design then you should definitely review all of these highly available architectures rather than provisioning a simple single direct connect. Now with that being said that's all of the theory and the architecture that I wanted to talk about in this lesson so go ahead complete the lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back. In this lesson, I want to talk about AWS Direct Connect. A Direct Connect (DX) is a physical connection into an AWS region. If you order this via AWS, the connection is either 1 gig, 10 gig, or 100 gig at the time of creating this lesson. There are other ways to provision slower speeds, but I'll be covering those in a dedicated lesson later in this section of the course. The connection is between a business premises, a Direct Connect (DX) location, and finally an AWS region. I’ll show this architecture visually on the next screen.

Conceptually, think of three different physical locations: your business premises, where you have a customer premises router; a DX location, where you also have other equipment such as a DX router and maybe some servers; and finally an AWS region, such as US East 1. When you order a DX connection, what you're actually ordering is a network port at the DX location. AWS provides a port allocation and authorizes you to connect to that port, which I’ll detail soon. However, a Direct Connect ordered directly from AWS doesn’t actually provide a connection of any kind—it’s just a physical port. It’s up to you to connect to this directly or arrange the connection to be extended via a third-party communications provider.

The port has two costs: an hourly cost based on the DX location and the speed of the port, and a charge for outbound data transfer. Inbound data transfer is free of charge. There are a couple of important things to keep in mind about Direct Connect. First is the provisioning time—AWS will take time to allocate a port, and once allocated, you’ll need to arrange the connection into that port at the DX location. If you haven’t already connected the DX location to your business network, you might be looking at weeks or months of extra time for the physical laying of cables between the DX location and your business premises. Keep that in mind.

Since it’s a physical cable, there’s no built-in resilience—if the cable is cut, it’s cut. You can design in resilience by using multiple Direct Connects, but that’s something you have to layer on top. Direct Connect provides low latency because data isn’t transiting across the public internet like with a VPN. It also provides consistent latency, as you’re using a single physical cable at best or a small number of private networking links at worst. If you need low and consistent latency for an application, Direct Connect is the way to go. In addition, it’s also the best way to achieve the highest speeds for hybrid networking within AWS. As mentioned, it can be provisioned with 1, 10, or 100 gigabit speeds, and since it’s a dedicated port, you’re very likely to achieve the maximum possible speed.

Compare that to an IPsec VPN, which uses encryption and therefore incurs processing overhead while transiting over the public internet. Direct Connect will give you higher, more consistent speeds. Lastly, Direct Connect can be used to access both AWS private services running in a VPC and AWS public services. However, it cannot be used to access the public internet unless you add a proxy or another networking appliance to handle that for you.

Visually, the architecture of Direct Connect starts on the right with your business premises, where you'll have some kind of customer premises router or firewall. This might be the same router connected to your internet connection or a new, dedicated DX-capable router, which I’ll explain more about in an upcoming lesson. Additionally, you’ll have some staff, in this case, Bob and Julie. In the middle, we have a DX location. This is often confusing, as it’s not a location actually owned by AWS—it’s not an AWS building. It’s usually a large regional data center where AWS rents space, and your business might also rent space alongside other businesses.

Inside this DX location is an AWS cage—an area owned by AWS containing one or more DX routers known as AWS DX routers, which are the endpoints of the Direct Connect service. You might also rent space in this DX location, known as the customer cage. If you’re a large organization, you might rent this space directly, housing some of your infrastructure and a router known as the customer DX router. If you’re a smaller organization, this cage might belong to a communications partner—this is called the comms partner cage. If you don’t have space in a DX location, the communications partner does and can extend connections from this DX location to your business premises.

The key thing to understand about Direct Connect is that it's a port allocation. When you order a Direct Connect from AWS to a specific DX location, you’re allocated a DX port. This must be physically connected using a fiber optic cable to another port in the DX location—either your router in your cage or a communications partner’s router in the same DX location. In either case, you’ll have a corresponding port within the DX location, whether on your own equipment or that of a comms provider. Between these two ports, you’ll need to order a cross connect.

The cross connect is a physical connection between the AWS DX port in the AWS cage and your or your provider’s port within the DX location. This concept is crucial, whether you have equipment in the DX location or purchase access through a communications partner. From the partner, you'll be allocated a port within the DX location, and it is to this port that the cross connect is linked. This is the cable that connects the AWS DX port to your router or a communications partner’s router. If you're using a communications partner, this link can then be extended to your customer premises. But in all cases, you must have a port within either a customer cage or comms partner cage at the DX location to establish a cross connect with AWS’s DX port.

On the left side, we have an AWS region—such as AP Southeast 2—with a VPC containing a private subnet and services. We also have the AWS public zone and example services such as SQS, Elastic IP addresses, and S3. The AWS region is AWS-owned infrastructure, which may or may not be in the same facility as the DX location but is always connected with multiple high-speed resilient network connections. Conceptually, you can think of the region as always being connected to one or more local DX locations.

That’s the physical architecture, and I’ll go into more detail in upcoming lessons elsewhere in the course. Logically, we configure virtual interfaces—called VIFs—over this single physical connection. There are three types of VIFs. First are transit VIFs, which have specific use cases that I’ll explain in detail later. Second are public VIFs, used to access AWS public space services. A public VIF runs over the full Direct Connect path—from your customer router to your DX router, then into the AWS DX router, and finally into the public AWS region. Third are private VIFs, which also run over Direct Connect but connect into virtual private gateways attached to a VPC, giving you access to private AWS services.

That’s everything I wanted to cover in this lesson. Go ahead and complete it, and when you're ready, I look forward to you joining me in the next one.

Welcome back and in this lesson I'm going to be stepping through the architecture of AWS site-to-site VPN. For the exam and if you're designing solutions for real-world production usage, understanding VPNs and how they can be used within AWS is essential. They offer the quickest way to create a network link between an AWS environment and something that's not AWS. And this might be on-premises, another cloud environment or a data centre.

Now we've got a lot to cover so let's jump in and get started. A site-to-site VPN is a logical connection between a VPC or virtual private cloud and an on-premises network. And this connection is encrypted in transit using IPsec, which is important because it runs over the public internet in most cases. Now there's a common exception to this when you run a VPN over the top of a direct connect and we'll be covering this later in this section. But assume, unless written otherwise, that a VPN is running over the public internet.

Now a site-to-site VPN can be fully, highly available, assuming that you design and implement it correctly. This is really important to understand for the exam and real-world usage. So I'm going to be covering it as a priority in this lesson. There are a few points of failure within the VPN architecture and you need to understand them all.

Site-to-site VPNs are also quick to provision. Assuming you understand all the steps and have all the skills, you can have a site-to-site VPN up and running in less than an hour. And try and remember this because it's in contrast to the long provisioning times for physical connections like direct connect, which we'll talk about later in this section.

Now there are a few components involved in creating a VPN connection that you need to be aware of. First, and this goes without saying, the VPC. VPNs connect VPCs and private on-premise networks. So it's logical that the VPC is one important building block of the wider connection architecture. Second, we've got the virtual private gateway or VGW and this is another type of logical gateway object, which can be the target on route tables. It's something that you create and associate with a single VPC and it's the target on one or more route tables.

Next, we've got the customer gateway or CGW and this can actually refer to two different things. It's often used to refer to both the logical piece of configuration within AWS and the thing that that configuration represents, a physical on-premises router which the VPN connects to. So when you see CGW mentioned, it's either the logical configuration in AWS or it's the physical device that this logical configuration represents. And then the last component is the VPN connection itself which stores the configuration and it's linked to one virtual private gateway and one customer gateway. So this is how we create the network virtual connection between these two locations.

Now, later in this section, I'm going to be showing you how to create a VPN connection, but for now, I want to focus on the architecture and the theory. So let's look visually at how VPNs are architected. First, I want to cover a simple implementation of a site to site VPN so that you're comfortable with the architecture.

So on the left, we have the Animals for Life VPC. It's a simplified version with three private subnets in availability zone A, B and C. Next, we've got the AWS Public Zone where AWS public services operate from. The public internet directly connected to that and then finally on the right, the Animals for Life corporate office using an IP range of 192.168.10.0/24.

Now, step one for creating a VPN connection is to gather all of the required information. We need the IP address range of the VPC that will be connecting to the on-premises network and we'll also need the IP range of the on-premises network itself and the IP address of the physical router on the customer premises. Once we have all of this information, then we can create a virtual private gateway and attach it to the Animals for Life VPC. The virtual private gateway is a logical gateway object within AWS and so it can be the target of routes just like any other gateway object.

Now, within our on-premises environment, we're going to have a customer premises router and this will have an external IP address. And for this router, we create a customer gateway object within AWS. This is a logical configuration entity that represents this physical device on our customer premises. In this case, we need to define its public IP address so that the logical CGW entity matches the physical router.

Behind the scenes, the virtual private gateway is actually a highly available gateway object. Just the same as earlier in the course when you configured internet gateways. All you had to do was create the gateway and associate it with a VPC and a virtual private gateway is just the same. Behind the scenes, a virtual private gateway actually has physical endpoints. These are devices in different availability zones each with public IP version 4 addresses. And this means that the virtual private gateway is fully, highly available by design. An availability zone can fail and if it affects one of the physical endpoints, the other will still function. But that doesn't mean that the whole thing is highly available and I'll detail that during the remainder of this lesson.

The next step is that we need to create a VPN connection inside AWS and there are different types of VPN connection. There are static and dynamic VPNs. For now, we're going to create a static one and I'll be explaining the differences between the two later in this lesson. Now, when creating a VPN connection, you need to link it to a virtual private gateway and this means that it can use the endpoints which that virtual private gateway provides. You also need to specify a customer gateway to use and when you do, two VPN tunnels are created. One between each endpoint and the physical on-premises router.

A VPN tunnel is an encrypted channel through which data can flow between the VPC and on-premises network or vice versa. As long as at least one of these VPN tunnels are active, then the two networks are connected. So in this particular case, we've got one VPN connection that's using the two endpoints of the virtual private gateway and both of those are connected back to our one customer gateway. So we have a partially highly available design. If one of the AZs on the AWS side fails, then the other endpoint will continue functioning. So at least one of these tunnels will be active.

Now, because this is a static VPN, it means that we have to statically configure the VPN connection with IP addressing information. So we have to tell the AWS side about the network range that's in use within the on-premises network and we have to configure the on-premises side so that it knows the IP address range that the AWS side uses. And this means that traffic can flow from the VPC via the VPC router through the virtual private gateway over the tunnels to the on-premises network and back again.

Now, as I just mentioned, this design from an overall perspective is actually not fully highly available, but there is still one single point of failure. And that single point of failure is the customer on-premises router. If this fails, then the whole VPN connection fails. Even though at the AWS side, it is highly available, all of the connections currently terminate into the single customer on-premises router. At the AWS side, there are two tunnels to separate hardware in separate availability zones, but this doesn't matter if the customer side fails because all of the tunnels terminate into the same single point of failure. And this is known as partial high availability. It's highly available on the AWS side, but suffers from a single point of failure on the customer side. So it's not a fully highly available solution.

It is actually pretty simple to resolve this to modify this design so that it is fully highly available. And let's look at that next. Moving to a fully highly available solution means adding another on-premises customer router using a second internet connection and ideally doing all of this in a separate building. Once you have this second resilient connectivity method, then you can create an additional VPN connection at the AWS side.

Now, behind the scenes, this actually creates two more physical endpoints which are managed by the virtual private gateway. And each of those has their own public IP addressing. So this new VPN connection, it would be linked to the same virtual private gateway at the AWS side, but to the new customer gateway. So it would establish another pair of VPN tunnels between the two new endpoints and that additional customer gateway.

Now, this means architecturally, we're in the situation where the virtual private gateway is now highly available. So it's highly available as a logical entity. It's using endpoints which are located in different availability zones and so it can withstand physical failure. But now in addition, at the customer side, we're now using multiple pieces of hardware with multiple internet connections, ideally in separate buildings. And that means this is a fully highly available solution. It's got two VPN tunnels connecting each customer premises router to two VPC endpoints in separate availability zones. And then that configuration is repeated again with a second customer gateway. So either of the customer gateways can fail, either of the availability zones can fail. And still the VPC and on-premises network will have connectivity.

Now, before we finish, I just want to talk about the differences between static and dynamic VPNs. Now, a dynamic VPN uses a protocol called BGP known as the border gateway protocol. And that's important because if your customer router doesn't support BGP, then you can't use dynamic VPNs. So conceptually, this is a traditional VPN architecture. A VPC subnet on the left, a VPC router middle left, a virtual private gateway middle right, and then an on-premises environment with a customer router on the right. This architecture is the same based on both types of VPNs, so static VPNs and dynamic VPNs. At a high level, the difference is how routes are communicated.

So a static VPN uses static networking configuration. Static routes are added to the route tables and static networks have to be identified on the VPN connection. The benefit of using a static VPN is that it's simple. It just uses IPsec and because of that, it works almost anywhere with any combination of routers. You are really restricted on things like load balancing and multi-connection failover. So if you need any advanced high availability, if you need to use multiple connections, if the VPNs need to work with Direct Connect, which we'll talk about later in this section, then you really do need to be using dynamic VPNs.

With dynamic VPNs, as I just mentioned, you're using a protocol called BGP or the Border Gateway Protocol. Now this is a protocol which lets routers exchange networking information. And so if you have a dynamic VPN, you're creating a relationship between the virtual private gateway and the customer router. Over this relationship, they can both exchange information on which networks are at the AWS side and which are at the customer side. In addition, they can communicate the state of links and adjust routing on the fly. And that allows for multiple links to be used at once between the same locations. So this is why dynamic VPNs are able to use really high end, highly available VPN architectures because they can communicate the state of the links between the virtual private gateway and the customer gateway.

Now with dynamic VPNs, routes can still be added to the route table statically. Or you can make the entire solution fully dynamic by enabling a feature called route propagation on the route tables in the VPC. And when you enable route propagation, it means that while any VPNs are active, any networks that these VPNs become aware of, so the on-premises networks in this example are automatically added as dynamically learned routes on the route tables. So instead of having to statically enter routes on each and every route table, if you enable routes propagation, they will learn these routes from the virtual private gateway whenever any VPNs are active. So any virtual private gateways which learn any routes using BGP, they can automatically and dynamically be added onto route tables on a per route table basis if you enable route propagation.

Now whichever method you decide on, there are a number of key considerations that you need to be aware of. First, there is a speed cap for VPNs. A single VPN connection with two tunnels has a maximum throughput of 1.25 gigabits per second. Now this is an AWS limit. You would also need to check the speed supported by your customer router because VPNs use encryption. There's a processing overhead on encrypting and decrypting data and at high speeds, this overhead can be significant. Now the speed limit is something that you should remember for the exam because it's often something which makes selecting between VPNs and something else significantly easier. So if you need more than 1.25 GB per second, then you can't use VPNs.

Now you also need to be aware that there is a cap for the virtual private gateway as a whole. So for all VPN connections connecting to that virtual private gateway and that's also 1.25 GB per second. Another consideration for VPNs is latency. The VPN connection transits over the public internet and depending on the quality of your internet connection, there may be many hops between you and the AWS VPN endpoints. Each hop adds latency and variability. So if you care about these as a priority, maybe you're running an application which is really latency sensitive. You might want to look at something else like Direct Connect which we'll be covering later in this section. Again, latency is often a selection criteria to pick between VPNs and something else in the exam.

Now in terms of costs, VPNs have an hourly cost to operate. There's a data transfer charge to transfer data out. And because you're using the internet to transit data, your on-premises internet connection is also going to be used by the VPN. So if you have any data caps on your internet connection, this is something to keep in mind, especially if you're going to be using a VPN to transfer lots of data.

Now one of the benefits of VPNs and this is important for the exam is that they are very quick to set up. Sometimes taking hours or less because it's all software defined. An IPsec is supported on pretty much all hardware at this point, even consumer grade routers. It is worth keeping in mind though that to use dynamic VPNs you will need BGP support which is much less common. But when comparing VPNs to anything else, VPNs are almost always quicker to set up versus other private connection technologies.

VPNs can also be used as a backup for a physical connection such as Direct Connect Rather than needing to provision two physical connections for true high availability, you can use one physical connection as the primary and use VPNs as the secondary. VPNs can also be used with physical technologies though, for example Direct Connect. So you can use a VPN at the start because they're quick to set up and provision. And then you can lodge a request to provision a Direct Connect which is added later. So a Direct Connect can take much longer to provision sometimes weeks or months, but you can use a VPN to set up that initial connectivity and then either replace it further down the line as the Direct Connect comes online or you can run both of them together for high availability.

Now VPNs can also be used over the top of Direct Connect to add a layer of encryption, but I'll be covering that in the Direct Connect lesson. For now though that's all of the theory that I wanted to cover, so go ahead complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover IPsec fundamentals. So I want to talk about what IPsec is, why it matters, and how IPsec works at a fundamental level. Now we have a lot of theory to cover, so let's jump in and get started. At a foundational level, IPsec is a group of protocols which work together. Their aim is to set up secure networking tunnels across insecure networks—for example, connecting two secure networks or, more specifically, their routers (called PIRS) across the public internet. You might use this if you're a business with multiple sites spread around geographically and want to connect them together, or if you have infrastructure in AWS or another cloud platform and want to connect to that infrastructure.

IPsec provides authentication so that only PIRS which are known to each other and can authenticate with each other can connect. Any traffic which is carried by the IPsec protocols is encrypted, which means to unlockers the secure data which has been carried is ciphertext—it can't be viewed and it can't be altered without being detected. Architecturally, it looks like this: we have the public internet, which is an insecure network full of goblins looking to steal your data. Over this insecure network, we create IPsec tunnels between PIRS. These tunnels exist as they're required. Within IPsec VPNs there's the concept of "interesting traffic," which is simply traffic that matches certain rules. These could be based on network prefixes or match more complex traffic types. Regardless of the rules, if data matches any of those rules, it's classified as interesting traffic, and a VPN tunnel is created to carry traffic through to its destination. If there's no interesting traffic, then tunnels are eventually torn down, only to be reestablished when the system next detects interesting traffic. The key thing to understand is that even though those tunnels use the public internet for transit, any data within the tunnels is encrypted while transiting over that insecure network—it's protected.

Now, to understand the nuance of what IPsec does, we need to refresh a few key pieces of knowledge. In my fundamentals section, I talked about the different types of encryption. I mentioned symmetric and asymmetric encryption. Symmetric encryption is fast, generally really easy to perform on any modern CPU, and it has pretty low overhead. But exchanging keys is a challenge—since the same keys are used to encrypt and decrypt, how can you get the key from one entity to another securely? Do you transmit it in advance over a different medium, or do you encrypt it? If so, you run into a catch-22: how do you securely transmit the encrypted key? That's why asymmetric encryption is really valuable. It's slower, so we don't want to be using it all the time, but it makes exchanging keys really simple because different keys are used for encryption and decryption. A public key is used to encrypt data, and only the corresponding private key can decrypt that data. This means that you can safely exchange the public key while keeping the private key private. So the aim of most protocols which handle the encryption of data over the internet is to start with asymmetric encryption, use this to securely exchange symmetric keys, and then use those for ongoing encryption. I mention that because it will help you understand exactly how IPsec VPN works.

So let's go through it. IPsec has two main phases. If you work with VPNs, you're going to hear a lot of talk about phase one or phase two. It'll make sense why these are needed by the end of this lesson. Understand that there are two phases in setting up a given VPN connection. The first is known as Ike Phase One. Ike, or Internet Key Exchange, as the name suggests, is a protocol for how keys are exchanged in this context within a VPN. There are two versions: Ike version one and Ike version two. Version one is older; version two is newer and comes with more features. You don’t need to know all the details right now—just understand that the protocol is about exchanging keys. Ike Phase One is the slow and heavy part of the process. It’s where you initially authenticate using a pre-shared key (a password of sorts) or a certificate. It’s where asymmetric encryption is used to agree on, create, and share symmetric keys used in Phase Two. The end of this phase is what's known as an Ike Phase One tunnel, or a Security Association (SA). There’s a lot of jargon being thrown around, and I’ll be showing you how this all works visually in just a moment. But at the end of Phase One, you have a Phase One tunnel, and the heavy work of moving toward symmetric keys which can be used for encryption has been completed.

The next step is Ike Phase Two, which is faster and much more agile because much of the heavy lifting has been done in Phase One. Technically, the Phase One keys are used as a starting point for Phase Two. Phase Two is built on top of Phase One and is concerned with agreeing on encryption methods and the keys used for the bulk transfer of data. The end result is an IPsec Security Association—a Phase Two tunnel which runs over Phase One. These different phases are split because it's possible for Phase One to be established, then a Phase Two tunnel created, used, and torn down when no more interesting traffic occurs—while the Phase One tunnel stays. This means establishing a new Phase Two tunnel is much faster and less work. It's an elegant and well-designed architecture.

Let’s look at how this all works together visually. This is Ike Phase One. The architecture is simple: two business sites—Site One on the left with the user Bob, and Site Two on the right with the user Julie—with the public internet in the middle. The very first step of this process is that the routers, the two peers at either side of this architecture, need to authenticate—essentially prove their identity—done either using certificates or pre-shared keys. It's important to understand that this isn't yet about encryption; it's about proving identity, proving that both sides agree that the other should be part of this VPN. No keys are exchanged—it’s just about identity. Once the identity has been confirmed, we move on to the next stage of Ike Phase One.

In this stage, we use a process called Diffie-Hellman Key Exchange. Again, sorry about the jargon, but try your best to remember Diffie-Hellman, known as DH. Each side creates a Diffie-Hellman private key. This key is used to decrypt data and to sign things—you should remember this from the encryption fundamentals lesson. Each side also derives a corresponding public key from its private key. The public key can be used to encrypt data that only the private key can decrypt. These public keys are exchanged—Bob has Julie’s public key, and Julie has Bob’s. These public keys are not sensitive and can only be used to encrypt data for decryption by the corresponding private key. Then comes the mathematically complex part—each side uses its own private key and the other’s public key to derive a shared Diffie-Hellman key. This key is the same on both sides, even though it’s been independently generated. It's used to exchange other key material and agreements, essentially a negotiation. Each side independently uses this DH key plus the exchanged material to generate a final Phase One symmetric key, used to encrypt anything passing through the Phase One tunnel, known as the Ike Security Association.

That process is slow and heavy—it’s both complex and simplistically elegant at the same time—but it means both sides have the same symmetric key without ever directly passing it between them. The phase ends with this Security Association in place, and it can now be used in Phase Two. In Phase Two, we now have a few components: the DH key on both sides, the Phase One symmetric key on both sides, and the established Phase One tunnel. In this phase, both peers want to agree on how the VPN will be constructed. Phase One was about allowing this—exchanging keys and allowing the peers to communicate. Ike Phase Two is about getting the VPN running and being ready to encrypt data—agreeing on how, when, and what. The symmetric key encrypts and decrypts agreements and passes more key material between the peers. One peer informs the other about the cipher suites it supports—encryption methods it can perform. The other peer picks the best shared one and lets the first know, and this becomes the agreed method of communication.

Then, using the DH key and the exchanged key material, both peers create a new symmetric IPsec key. This key is designed for large-scale data transfer. It’s an efficient and secure algorithm, and the specific one is based on the earlier negotiation. This IPsec key is used to encrypt and decrypt the "interesting traffic" across the VPN tunnel. Across each Phase One tunnel, there is actually a pair of Security Associations—one from right to left and one from left to right. These are used to transfer data between networks at either side of a VPN.

Now, there are two types of VPNs you need to understand: policy-based VPNs and route-based VPNs. The difference lies in how they match interesting traffic—the traffic sent over a VPN. In policy-based VPNs, rules match traffic, and based on the rule, traffic is sent over a pair of Security Associations—one for each direction. This allows different rules for different types of traffic, which is great for rigorous security environments. In contrast, route-based VPNs match traffic based on prefix—for example, "send traffic for 192.168.0.0/24 over this VPN." This uses a single pair of Security Associations per network prefix, meaning all traffic types between those networks use the same SA pair. It’s less functional but simpler to set up.

To illustrate the differences between route-based and policy-based VPNs, let's look visually at the architectures. In a simple route-based VPN, a Phase One tunnel is established using a Phase One key. Assuming we use a route-based VPN, a single pair of Security Associations is created—one in each direction—using a single IPsec key. This gives us essentially a single Phase Two tunnel running over the Phase One tunnel. That Phase Two or IPsec tunnel (the pair of SAs) can be dropped when there’s no interesting traffic and recreated again on top of the same Phase One tunnel when new traffic is detected. The key point is there’s one Phase One tunnel and one Phase Two tunnel based on routes.

Running a policy-based VPN is different. We still have the same Phase One tunnel, but over the top of this, each policy match uses an SA pair with a unique IPsec key. This allows us to have, for the same network, different security settings for different types of traffic—for example, infrastructure at the top, CCTV in the middle, and financial systems at the bottom. Policy-based VPNs are more difficult to configure but offer greater flexibility for using different security settings for different traffic types.

Now, that at a very high level is how VPNs function—the security architecture of how everything interacts. Elsewhere in my course, you'll be learning how AWS uses VPNs within their product set. But for now, that’s everything I wanted to cover. Go ahead and complete this video, and then, when you’re ready, I look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be talking about the border gateway protocol known as BGP. Now BGP is a routing protocol and that means that it's a protocol which is used to control how data flows from point A through points B and C and arrives at the destination point D. Now BGP is a complex topic that goes far beyond the scope of this exam but as a solutions architect you need to be aware of how it works at a high level because AWS products such as Direct Connect and Dynamic VPNs both utilize BGP. So let's jump in and get started.

BGP as a system is made up of lots of self managing networks known as autonomous systems or AS. Now an AS could be a large network, it could be a collection of routers but in either case they're controlled by one single entity. From a BGP perspective it's viewed as a black box, an abstraction away from the detail which BGP doesn't need. Now you might have an enterprise network with lots of routers and complex internal routing but all BGP needs to be aware of is your network as a whole. So your autonomous systems are black boxes which abstract away from the detail and only concern themselves with network routing in and out of your autonomous system.

Now each autonomous system is allocated a number by IANA, the Internet Assigned Numbers Authority. The ASNs are 16 bits in length and range from 0 through to 65,535. Now most of that range are public ASNs which are directly allocated by IANA. However the range from 64,512 to 65,534 are private and can be utilized within private peering arrangements without being officially allocated. Now ASNs or Autonomous System Numbers are the way that BGP identifies different entities within the network, so different peers. So that's the way that BGP can distinguish between your network or your ASN and my network.

BGP is designed to be reliable and distributed and it operates over TCP using port 179 and so it includes error correction and flow control to ensure that all parties can communicate reliably. It isn't however automatic, you have to manually create a peering relationship, a BGP relationship between two different autonomous systems and once done those two autonomous systems can communicate what they know about network topology. Now a given autonomous system will learn about networks from any of the peering relationships that it has and anything that it learns it will communicate out to any of its other peers. And so because of the peering relationship structure you rapidly build up a larger BGP network where each individual autonomous system is exchanging network topology information. And that's how the internet functions from a routing perspective. All of the major core networks are busy exchanging routing and topology information between each other.

Now BGP is what's known as a path vector protocol and this means that it exchanges the best path to a destination between peers. It doesn't exchange every path only the best path that a given autonomous system is aware of and that path is known as an AS path, an autonomous system path. Now BGP doesn't take into account link speed or condition, it focuses on paths. For example, can we get from A to D using A, B, C and D or is there a direct link between A and D? It's BGP's responsibility to build up this network topology map and allow the exchange between different autonomous systems.

Now while working with AWS or integrating AWS networks with more complex hybrid architectures, you might see the terms IBGP or EBGP. Now IBGP focuses on routing within an autonomous system and EBGP focuses on routing between autonomous systems. And this lesson will focus on BGP as it relates to routing between autonomous systems because that's the type that tends to be used most often with AWS. Now I need to stress at this point that this lesson is not a deep dive into BGP. All I need you to understand at this point is the high level architecture so that you can make sense of how it's used within AWS. So let's look at this visually and hopefully it will make more sense.

So I want to step through an example of a fairly common BGP style topology. So this is Australia, the land of crocodiles and kangaroos. And in this example we have three major metro areas. We have Brisbane on the east and this has an IP address range of 10.16.0.0/16. And the router is using the IP of 10.16.0.1 and this has an autonomous system number of 200. We have Adelaide on the south coast using a network range of 10.17.0.0/16 and the router is using 10.17.0.1 and this has an autonomous system number of 201. And then finally between the two in the middle of Australia we have Alice Springs using the network 10.18.0.0/16. The router uses 10.18.0.1 and the autonomous system number is 202. Now between Brisbane and Adelaide and between Adelaide and Alice Springs is a one gigabit fiberlink. And then connecting Brisbane and Alice Springs is a five megabit satellite connection with an unlimited data cap.

BGP at its foundation is designed to exchange network topology and it does this by exchanging paths between autonomous systems. So let's step through an example of how this might look using this network structure. We start at the top right with Brisbane and this is how the route table for Brisbane might look at this point. The route table contains the destination. In this case we only have the one route and it's the local network for Brisbane. The next column in the route table is the next hop. So what IP address is needed is the first or next hop to get to that network and 0.0.0.0 in this case means that it's locally connected. And this is because it's the local network that exists in the Brisbane site. And then finally we have the AS path which is the autonomous system path and this shows the path or the way to get from one autonomous system to another. And the I in this case means that it's the origin so it's this network.

Now the two other locations will have a similar route table at this stage. So Adelaide will have one for 10.17.0.0 and Alice Springs will have one for 10.18.0.0/16. And both of those will have 0.0.0.0 as the next hop and I for the AS path because they're all local networks. So each of these autonomous systems so 200, 201 and 202 can have peering relationships configured. So let's assume that we've linked all three. So Brisbane and Alice Springs, Alice Springs and Adelaide and then finally Adelaide and Brisbane. Each of those peers will exchange the best paths that they have to a destination with each other. So Adelaide will send Brisbane the networks that it knows about and at this point it's only itself. And what it does when it exchanges this or when it advertises this is it pre-pens its AS number onto the path.

So Brisbane now knows that to get to the 10.17.0.0 network it needs to send the data to 10.17.0.1. And because of the AS path it knows that it goes through autonomous system 201 which is Adelaide and then it reaches the origin or I. And so it knows that the data only has to go through one autonomous system to reach its final destination. Now in addition to this Brisbane will also receive an additional path advertised from Alice Springs in this case over the satellite connection. And Alice Springs propends its AS number 202 onto that path. So Brisbane knows to get to the 10.18.0.0/16 network. The next stop is 10.18.0.1 which is the Alice Springs router and it needs to go via the 202 autonomous system number which belongs to Alice Springs. So at this point Brisbane knows about both of the other autonomous systems and it's able to reach both of them from a routing perspective.

Now in addition to that Adelaide will also learn about the Brisbane autonomous system because it has a peering relationship with the Brisbane autonomous system. And in addition Adelaide will also in the same way learn about the network in Alice Springs because it also has a peering relationship with the Alice Springs ASN 202. And then finally because Alice Springs also has BGP peering relationships between it and both of the other autonomous systems. It will also learn about the Brisbane autonomous system and the Adelaide autonomous system. And so at this point all three networks are able to route traffic to the other two. So if we look at the route table for Alice Springs it knows how to get to the 10.16 and 10.17 networks via the ASN of 202.01 respectively. All three autonomous systems can talk to both of the others and this has all been configured automatically once those BGP peering relationships were set up between each of the autonomous systems.

But it doesn't stop there. This is a ring network and so there are two ways to get to every other network clockwise and anti-clockwise. Adelaide is aware of how to get to Alice Springs so ASN 202 because it's directly connected to that. And so it will advertise this to Brisbane pre-pending its own ASN onto the AS path. And so Brisbane can now reach Alice Springs via Adelaide so using the 201 and then 202 AS path. Notice how the next hop for the route given to Brisbane is the Adelaide router so 10.17.0.1. And so if we used this route table entry the traffic would go first to Adelaide and then be forwarded on to Alice Springs. Likewise Adelaide is aware of Brisbane and so it will advertise that to Alice Springs pre-pending its own ASN onto the AS path. So notice how this new route on the Alice Springs route table the one for 10.16.0.0/16 is going via Adelaide so 10.17.0.1. The AS path is 201 which is Adelaide, 200 which is Brisbane and then the origin.

Now lastly Adelaide will also learn an additional route to Alice Springs but this time via Brisbane. And Brisbane would pre-pend its own ASN onto the AS path. So in this case we've got the additional route at the bottom for 10.18.0.0/16 but the next hop is Brisbane 10.16.0.1 and the AS path is 200 which is Brisbane and then 202 which is Alice Springs and then we've got the origin. Autonomous systems advertise the shortest route that they're aware of to any other autonomous systems that they have peering relationships with. Now at this point we're in a situation where we actually have a fully highly available network with paths to every single network. If any of these three sites failed then BGP would be aware of the route to the working sites. Notice that the indirect routes that I've highlighted in blue at the bottom of each route table have a longer AS path. These are non-preferred because it's not the shortest path to the destination. So Brisbane for example if it was sending traffic to Alice Springs it would use the shorter path, the direct satellite connection. By default BGP always uses the shorter path as the preferred one.

Now there are situations where you want to influence which path is used to reach a given network. Imagine that you're the network administrator for the Alice Springs network. Now that autonomous system has two networking connections, the fiber connection coming from Adelaide and the satellite connection between it and Brisbane. Now ideally you want to ensure that the satellite connection is only ever used as a backup when absolutely required and that's for two reasons. Firstly it's a slower connection, it only operates at 5 megabits and also because it's a satellite connection it will suffer from significantly higher latencies than the fiber connection between Alice Springs and Adelaide and then Adelaide and Brisbane. Now because BGP doesn't take into account performance or condition the satellite connection because it's the shortest path will always be used for any communications between Alice Springs and Brisbane.

But you are able to use a technique called ASPATH prepending which means that you can configure BGP at Alice Springs to make the satellite link look worse than it actually is. And you do this by adding additional autonomous system numbers to the path. You make it appear to be longer than it physically is. Remember BGP decides everything based on path length and so by artificially lengthening the path between Alice Springs and Brisbane it means that Brisbane will learn a new route, the old one will be removed and so the new shortest path between Brisbane and Alice Springs will be the one highlighted in blue at the bottom of the Brisbane route table. This one will be seen as shorter than the artificially extended one using ASPATH prepending and so now all of the data between Brisbane and Alice Springs will go via the fiber link from Brisbane through Adelaide and finally to Alice Springs. BGP thinks that the path from Brisbane to Alice Springs directly over the satellite connection has three hops versus the two hops for the fiber connection via Adelaide and so this one will always be preferred.

So in summary a BGP autonomous system advertises the shortest path to a destination that it's aware of to all of the other BGP routers that it's paired with. It might be aware of more paths but it only advertises the shortest one and it means that all BGP networks work together to create a dynamic and ever-changing topology of all interconnected networks. It's how many large enterprise networks function, it's how the internet works and it's how routes are learned and communicated when using Direct Connect and dynamic VPNs within AWS. Now that's everything that I wanted to cover. This has just been a high level introduction to how BGP works and it's going to be a protocol that you'll need to understand in order to architect more complex or hybrid networks between AWS and on-premise. Now that's all of the theory that I wanted to cover in this lesson so go ahead, finish off this video and when you're ready I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to introduce a product that is becoming more important for the exam. As a solutions architect, it's an essential one to understand. That product is the AWS Global Accelerator, which is designed to optimize the flow of data from your users to your AWS infrastructure. We have a fair amount to cover, so let's jump in and take a look.

To understand why the Global Accelerator is required, let's review a typical problem when using AWS. Let's say you've created an application and initially choose to host it in the US. This application, involving cats, becomes really popular with users based in the US, who generally have a great user experience. However, over time, the application’s notoriety increases, and it becomes popular with global users, who experience a much less optimal performance. The reason for this suboptimal experience is that the traffic between their locations and the infrastructure in North America is less direct. Conceptually, every flow of data over the internet can take a different route. For example, communication between a laptop and a VPC is not direct; the data moves through various routers and different hops. Each hop adds delay, variability, and potential failure. What’s worse is that the route can vary between customers and even for the return flow of traffic for the same customer. Each of these hops is suboptimal, so the fewer the hops, the better and more consistent the experience. Generally, customers further away from your infrastructure will go through more internet-based hops, resulting in a lower quality of connection. The internet is designed to be distributed, autonomous, and highly resilient, and while speed is important, it's less important than these other priorities.

The AWS Global Accelerator product isn’t that difficult to understand architecturally. In many ways, its architecture is similar to CloudFront, and one of the key things in the exam is being able to determine when to use CloudFront and when to use the Global Accelerator. Both improve performance, but they do so in different ways and for different reasons. Global Accelerator starts with two Anycast IP addresses, which are a special type of IP address. Normal IP addresses are referred to as Unicast IP addresses, and these refer to one specific network device. If two devices on a network share the same Unicast IP address, bad things can happen. In contrast, Anycast IPs allow multiple devices to use the same IP address, which is advertised to the public internet. Internet core routers route traffic to the device closest to the source. In our example, we have Anycast IP addresses, such as 1.2.3.4 and 4.3.2.1, which map to three Global Accelerator edge locations. While there are more in reality, I’m keeping the diagram simple. The key thing to understand is that all three Global Accelerator edge locations use these Anycast IP addresses, so any traffic destined for either of these IP addresses can be serviced by any of the edge locations.

If we have two users, one based in London and one in Australia, and they both browse to these Anycast IP addresses, their traffic will be routed to the closest edge location, using the public internet. This part of the connection is still subject to the variability that the public internet can cause, but it’s now limited to the part between the customer and the Global Accelerator edge location. What we’ve essentially done is move the AWS network closer to the customer. Once traffic arrives at the edge location, it’s transmitted over the AWS global network. AWS controls its own dedicated network with fiber links between all of its regions. They handle capacity and performance, and if performance is anything but optimal, you can complain to them.

For the exam, you only need to understand the architecture: customers will arrive at one of the Global Accelerator edge locations because they’re using one of the Anycast IP addresses assigned to us when we create a Global Accelerator. So when we create a Global Accelerator, we’re allocated these two Anycast IP addresses. If customers use these, their connections will be routed to the closest Global Accelerator edge location. The part indicated in red in the diagram occurs over the public internet, and this can be affected by the variability that the internet experiences. However, once traffic enters the Global Accelerator product, it’s transmitted over the AWS global network to our infrastructure, resulting in substantially improved performance. There are fewer hops, and AWS generally maintains the network to a higher standard, specifically for the transit of data between AWS regions.

Now, let’s talk about when and where to use Global Accelerator. This product is very much like CloudFront, so it’s understandable if you’re confused. Both products aim to move the AWS network closer to your customers, but they do so in different ways. CloudFront specifically moves content closer by caching it at the edge locations, while Global Accelerator moves the actual AWS network as close to your customers as possible. The goal with Global Accelerator is to get your customers onto the AWS global network as quickly and as close to their location as possible, and this is done using the Anycast IP addresses. Once the traffic reaches the edge, it’s transmitted over the AWS global network to the appropriate location.

Global Accelerator is capable of routing traffic to the closest infrastructure location to the customer, so it can direct connections from London to local infrastructure based in Europe, rather than the US. The key thing that Global Accelerator does is get data from your customer to an application endpoint as quickly as possible, with the best performance possible. One key difference between Global Accelerator and CloudFront is that Global Accelerator is a network product. It works on any TCP or UDP applications, including web apps, whereas CloudFront only caches HTTP and HTTPS content. If you see questions mentioning caching, it’s likely to be CloudFront that is the right answer, but if the question involves TCP or UDP network optimization and global performance, then Global Accelerator might be the correct answer.

Global Accelerator doesn’t cache anything; it doesn’t cache content or network data, and it doesn’t provide any HTTP or HTTPS-level capabilities. It’s strictly a network product. So if a question involves transiting network data (TCP or UDP) as quickly and efficiently as possible through a global network, it’s likely to be Global Accelerator. If it involves content delivery, caching, pre-signed URLs, or other CloudFront services, then CloudFront is probably the correct answer. Although you might initially find it difficult to distinguish between the two products, it should now be clear that they’re separate. If you need to do caching, deal with web or secure web content, or manipulate content, it’s CloudFront. If you need global TCP or UDP network optimization, it’s Global Accelerator.

That’s everything you’ll need to know for now. Go ahead and complete this video, and when you’re ready, I’ll look forward to you joining me in the next one.

Welcome back, and in this lesson, I want to cover something that starts to feature much more in AWS exams, and that's CloudFront Lambda at Edge. You don't need to have any experience implementing it, but you do need to know how it's architected and what it's capable of doing. So let's jump in and get started.

Lambda at Edge is a feature of CloudFront that allows you to run lightweight Lambda functions at CloudFront Edge locations. These Lambda functions can adjust traffic between the viewer and the origin in a number of interesting ways, and we'll talk about some of those soon. However, there are some limitations that you need to be aware of because the Lambda functions are running at the Edge. They don't have the full Lambda feature set. Currently, only Node.js and Python are supported as runtimes. You can't access any VPC-based resources since the functions are running in the AWS public zone, and additionally, Lambda layers are not supported. Lastly, the functions have different size and execution time limits compared to normal Lambda.

Now, you don't need to memorize all of these facts. What's more important is a good understanding of the architecture. So let's look at that next. Lambda at the Edge starts with the traditional CloudFront architecture. So, customers on the left, the Edge locations in the middle, and the origins on the right. Any interaction between a customer, Edge location, and origin consists of four individual parts of that communication: the connection between the customer and the Edge location, which is known as the viewer request; the connection between the Edge location and the origin, known as the origin request; when the origin responds, there's a connection between the origin and the CloudFront Edge, known as the origin response; and finally, the connection between the Edge location and the customer, known as the viewer response.

Now, with Lambda at the Edge, each of these individual components of the wider communication can run a Lambda function, and this Lambda function can influence the traffic as part of that connection. A viewer request Lambda function runs after the CloudFront Edge location receives a request from a viewer. An origin request function runs before CloudFront forwards that request onto the origin. An origin response function runs after CloudFront receives a reply from the origin, and then finally, a viewer response function runs before the response is forwarded back to the viewer.

Now there are limits on how the Lambda functions can run in each part of the architecture. At the viewer side, a Lambda at Edge function has a limit of 128 MB for memory allocation and a function timeout of five seconds. At the origin side, the memory limits are the same as a normal Lambda, but with a 30-second timeout. Again, don't worry too much about these limits. For now, try to focus at a high level on what these limits mean, what types of architectures, and what type of adjustments these Lambda functions can perform on each of these different components of the flow of data between a viewer and an origin and back again.

Now, let's look at some example solutions which involve Lambda at the Edge. I've included a link attached to this lesson which gives a few examples of situations where you would use Lambda at the Edge. I can't give an exhaustive list in this lesson because, just like Lambda itself, you can pretty much do anything that you want as long as you can code it within a Lambda environment. But a couple of common examples that you might find useful for the exam: First, you can use Lambda at the Edge to perform A/B testing. This is generally done with a viewer request function. You can use a viewer request function in an A/B testing scenario to present two different versions of an image without creating redirects or changing the URL. In this architecture, the function views the viewer request and modifies the request URL based on which version of an image you want the viewer to receive. With this architecture, the Lambda function can modify the viewer request and change the URL based on any logic that you can define inside a Lambda function. It can be things like a percentage-based algorithm or it can be random chance.

Another scenario which you might use Lambda at the Edge for is running a function as part of the origin request. This can be used to perform a gradual migration between different S3 origins. You can use a function running in this part of the architecture to gradually transfer traffic from an existing S3 origin over to a new one, and you can do so in a controlled way. For example, based on a weighted value, which represents a percentage of the traffic of your application, you can increase the percentage of traffic which goes to the new S3 origin versus the old. And all of this can be done in a controlled way without updating the CloudFront distribution.

You can also use Lambda at the Edge to customize behavior based on the type of device that your customer has. Given a particular type of device or a particular capability of that device, you can display different objects. This might include different sizes of objects or objects with different quality levels. For example, if you have a device which has a high DPI screen, so a higher dots per inch, then you might want to display objects which themselves have a higher DPI value and save lower DPI objects for devices which can't support high DPI. So again, that's something that you can use Lambda at the Edge for rather than making any changes to the CloudFront distribution.

You can also use Lambda at the Edge to vary the content displayed by country. So a Lambda function that's running in the origin request component of the communication can be used to adjust what gets displayed based on the country of the customer. Now, the link that I've included attached to this lesson gives a lot more examples of the types of scenarios that would benefit from Lambda at the Edge. In addition to the scenarios, most of these include example Lambda function code that you can implement in your own environments.

So this is going to be something that's outside of the scope of this course. You only need to be aware of the architecture of Lambda at the Edge for this certification. But if you do want to experiment with this in your own time, then you can use the examples contained on this page, and again, the URL is attached to the lesson, and you can do your own experimentation. But at this point, that's all of the architecture that I wanted to cover in this lesson. I just want you to be aware of exactly what Lambda at Edge can be used for because you might get a question on it in the exam. So make sure that you're comfortable with all of the examples that I've given in this lesson and all of the examples which are included on the link that are attached to this lesson.

Again, you won't need to remember all of the different facts and the execution limits and the memory amounts. It's all about the architecture. So if you familiarize yourself with all of the examples that are on screen now and the ones that are in the link attached to this lesson, then you'll have all of the information that you need to answer questions about this topic in the exam. But at this point, that's all of the theory that I wanted to cover in this lesson. So go ahead, complete the lesson, and then when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, I want to step through how you can deliver private content from CloudFront using behaviors. Additionally, I want to step through the differences between signed URLs and signed cookies, which are ways to deliver private content to your end users. We’ve got a lot to cover, so let’s jump in and get started.

CloudFront can run in two security modes when it comes to content. The first and the default is public. In this mode, any content that is distributed via CloudFront is public and can be accessed by any viewer. This is the mode that you've probably experienced so far, but there's also private. In this mode, any requests made to CloudFront need to be made with a signed cookie or signed URL, or they’ll be denied. CloudFront distributions are created with a single behavior, and in this state, the whole behavior—and so the whole distribution—is either public or private. Generally, though, you're going to have multiple behaviors, and part will be public and part private. This allows you to redirect any unintended accesses to a private behavior at a public one, for example, starting a login process.

Now, there are two ways to configure private behaviors in CloudFront: the old way and the new preferred way. In both cases, you require a signer, and a signer is an entity or entities which can create signed URLs or signed cookies. Once a signer is added to a behavior, that behavior is now private, and only signed URLs and cookies can be used to access content. With the old way, you first had to create a CloudFront key to use, and this is something that an account root user had to create and manage. This is a special key that's tied to an AWS account rather than a specific identity within that account, and once a CloudFront key exists in an account, that account can be added as a trusted signer to a distribution, specifically a behavior in that distribution. For real-world usage and for the exam, while this is the legacy method, you do need to remember the term "trusted signer." If you see it, you'll know that a private distribution or a private behavior is involved.

The new and preferred method is to create trusted key groups and assign those as signers. The key groups determine which keys can be used to create signed URLs and signed cookies. There are a few reasons why you should use trusted key groups versus the old architecture. First, you don't need to use the AWS account root user to manage public keys for CloudFront signed URLs and signed cookies. If you use trusted key groups, then you can manage these in a much more flexible way. You can manage these key groups and the configuration using the CloudFront API, and you can associate a higher number of public keys with your distribution, more specifically with your behavior, giving you more flexibility in how you use and manage those keys. So it’s absolutely preferred to use this new method of trusted key groups versus the old method of a CloudFront key being added to an AWS account and that account being added as a trusted signer. So there's the old way and the new way, and absolutely you should prefer the new way for any new deployments.

Now at this point, I want to quickly step through the differences between signed URLs and signed cookies so you know some of the situations where you might use one versus the other. Signed URLs provide access to one object and one object only. That's really critical—remember that one for the exam because it can be a really easy way to pick between the two. Now, this is not really valid at this point, but historically RTMP distributions couldn't use signed cookies, so this was a legacy point to pick between signed URLs and cookies, but this isn't really applicable anymore. You should use signed URLs if the clients don't support using cookies. Not everything does, so if your client doesn't support cookies, then you can only use signed URLs. Cookies can provide access to groups of objects, so you could use a signed cookie to provide access to groups of files or all files of a particular type. For example, all cat gifts—this is a really common requirement in applications. So, when you use signed URLs with CloudFront, you get a custom URL. If you want to present access using a certain format of URL, then you need to use signed cookies, so that's another point of differentiation.

Now visually, this is how the architecture looks. We start with our customers who are using the Categorum application—this time, the new iPhone application. Because of the popularity of the existing web application, the new mobile application has been developed to use CloudFront. The application has images which are public, and then some more sensitive ones, for example, cats bearing all for a belly rub. So, there needs to be some method of distributing private content. Within the CloudFront distribution, there are two behaviors: a public behavior, which is the default, and this handles all non-sensitive application operations, and then a private one, which handles access to all of the sensitive cat gifts. All of the infrastructure runs within an AWS account, and it’s a serverless application, so the back end consists of API Gateway, Lambda for the compute functionality, and S3 to store the media.

The application flow starts when the application connects through to the distribution, which for the default behavior uses the API Gateway as an origin, which uses Lambda for the serverless compute. Let's assume that the mobile app is using ID Federation, so a Google, Twitter, or Facebook Identity for logins. The application communicates with the default behavior, uses API Gateway, logs in, and accesses some images which are private. The Lambda signer function checks the application's access to the image, and if everything is good because we've added trusted key groups on the distribution, specifically the behavior, the Lambda function is able to generate a signed cookie which grants access to a selection of images belonging to this specific application user. That cookie, together with information on access URLs, is returned to the mobile application. The mobile application, all behind the scenes, uses the access information to access the images, and it supplies the cookie along with this request. The cookie is checked by CloudFront, and assuming everything checks out, an origin fetch occurs. The cat images are retrieved and returned back to the application.

Private behaviors are an excellent way to secure content, but you need to make sure that the origin is also secure. In this case, the S3 origin needs to be configured using an origin access identity so that it only accepts connections from the CloudFront distribution, and that will avoid the security issue where CloudFront gets bypassed. Now, at this point, that’s all of the theory I wanted to cover in this video. Thanks for watching, go ahead and complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back. In the next few lessons, I want to talk about how to secure the content delivery path when using CloudFront. When content is being delivered globally using CloudFront, there are a few zones that you need to think about. First, on the left are the origins, which are the locations where content is hosted. In the middle, we've got the CloudFront network, which consists of the network itself and the edge locations, and then, on the right, the public internet and our consumers of content. For the next two lessons, I want to focus on the security of this path. So first, in this lesson, I'll focus on the security of the origin fetch side, which is the transfer of data into the CloudFront network from the origins and then through to the edge locations. Then, in the next lesson, I'll be covering the security of the customer or viewer side, which involves getting content through to the consumer in a safe and secure way. For this lesson, I'll be focusing on the origin side security, specifically on how we can ensure that only CloudFront gets access to the data on those origins, essentially avoiding an ingenious customer bypassing CloudFront and accessing the origins directly.

So, let's get started and explore this part of the delivery path. Now, before we start, I want to reiterate something I covered in an earlier lesson. You can use S3 as an origin for CloudFront, but you can do it in two different ways. If you just use S3 as an origin, then it's known as an S3 origin. However, if you utilize the static web hosting feature of S3 and use this with CloudFront, then the S3 bucket is treated the same as any non-S3 origin, and this is known as a custom origin. For this lesson, when I'm covering OAIs or origin access identities, this is only applicable for S3 origins, not when using the static website feature of S3.

So what is an OAI? Well, it's a type of identity. It's not the same as an IAM user or an IAM role, but it does share some of the characteristics of both. It can be associated with CloudFront distributions, and those CloudFront distributions, when they're accessing an S3 origin, in essence, the CloudFront distribution becomes that origin access identity. This means that when a CloudFront distribution is accessing an S3 origin, the identity can be used within bucket policies, either explicit allows or denies. Generally, the common pattern is to lock an S3 origin down to only being accessible via CloudFront. This uses the implicit default deny to apply to everything except the origin access identity. So, the origin access identity is explicitly allowed access to the bucket, and everything else is implicitly denied. Visually, this looks like this: we start with a CloudFront distribution already configured for Animals for Life. This architecture uses an S3 origin, a few edge locations, and two customers, Julie and Moss, and we want to allow access via CloudFront to this S3 origin and deny any direct access. To do that, we create an origin access identity and associate that origin access identity with the CloudFront distribution.

The effect of doing this means that the edge locations gain this identity, the origin access identity. Then, we can create or adjust the bucket policy on the S3 bucket. We add an explicit allow for the origin access identity, and in its most secure form, we remove all other access, leaving the implicit deny. At this point, any access from the edge locations is actually from the origin access identity, the virtual identity that we've created and associated with the CloudFront distribution. Therefore, access from the edge locations is allowed because the origin access identity is explicitly allowed via the bucket policy. However, direct access, for example, from our Moss user, would not have the origin access identity associated with them, and because of this, it's implicitly denied from accessing the bucket. So, with this configuration, we've explicitly allowed the origin access identity and not explicitly allowed anything else. Therefore, what remains is the implicit deny that applies to everything. These identities can be created and used on many CloudFront distributions and many buckets at the same time. Generally, though, I find it easier to manage if you create one origin access identity for use with one CloudFront distribution because, long-term, this makes it easier to manage permissions.

So that's how we handle origin security for S3 origins, but what about non-S3 origins, custom origins? Is there a way to secure those? Let's take a look at that next. For this architecture, let's say that we have two custom origins, two CloudFront edge locations, and a customer, and what we want to do is prevent the customer from accessing the origins directly. Now, remember, these are not S3 origins, and so we can't use origin access identities to control access. For custom origins, we have two ways that we can implement a more secure architecture. First, we can utilize custom headers. The way this works is that our users use HTTPS to communicate with the edge locations, and we can insist on this by configuring the viewer protocol policy. Now, HTTPS is actually just HTTP running inside a secure tunnel, which has the advantage of protecting the contents of that tunnel. We can also use the same protocol between the edge location and the origin, which is known as the origin protocol policy. But in addition to this, we configure CloudFront to add a custom header, which is sent along with the request to the origin. The origin is then configured to require this header to be present, or it won't service the request. These are called custom headers, and they can be configured within CloudFront. Because the entire stream utilizes HTTPS, no one can oversee the headers we're using and fake them. The custom headers are injected at the edge location, and these allow our custom origin to know for sure that the request is coming from a CloudFront edge location. If this header isn't present, the origin will simply refuse to service any of the requests.

Now, that's one way to handle it, but we do have another way, and that's via traditional security methods. AWS actually publicizes the IP addresses of all of their services, so we can easily determine the IP ranges at the CloudFront edge locations. If we have the IP ranges that are used by CloudFront, then we can use a traditional firewall around the custom origin. This firewall is then configured to allow connections from the edge locations and deny anything else. This is another solution, which means the origin is essentially private to anything but CloudFront and can't be bypassed. You can use either of these approaches or even both of them in combination. By doing so, you ensure that the secure and private distribution of content cannot be bypassed by accessing the origins directly.

All of these methods—origin access identity, custom headers, and traditional IP blocks—secure the first part of the content delivery path. In the next lesson, we're going to look at how to use CloudFront to secure the point between the edge location and our customer. So thanks for watching, go ahead and complete this lesson, and when you're ready, I look forward to speaking to you in the next.

Welcome back! In this lesson, I want to go into a little bit more detail about origin types and origin architecture within CloudFront. You need to understand the types of origins, how they differ, and the features that each of them provides. This is going to be another lesson where it's easier to show you the differences rather than talk about them, so I'm going to move over to my console UI and explain the key points that you need to know for the exam and real-world usage.

Okay, let's take a look at some origins. I’ll click on the services dropdown and type CloudFront to move to the CloudFront console. Now, I have two CloudFront distributions already set up. One of them is a production one, so this one is blurred out, and the other is just one that I'm getting ready for production usage. I’ll open up this distribution and click on origins. Architecturally, origins are where CloudFront goes to get content. If an edge location receives a request from a customer and that object isn't cached at the edge, then an origin fetch occurs to the relevant origin.

Now, origin groups—though I don’t have any configured—allow you to add resiliency. If you have two or more origins created within a distribution, you can create an origin group, group those origins together, and have an origin group used by a behavior. Remember, origins themselves are selected from behavior. If I go to behavior, we only have the one default behavior. If I select it and click edit, it’s here where I can pick an origin or an origin group. For this behavior, it will direct any requests, if an origin fetch is required, to the origin or origin group specified in this dropdown. This is only for the single origin, but if we had an origin group, it would provide resilience across those origins. This is a really cool way to add resilience.

Moving back to origins, there are actually a few categories of origins, and it’s important to understand all of them and exactly which features they provide, as well as the situations where you’d use one versus another. For origins, you can have Amazon S3 buckets, AWS MediaPackage channel endpoints, AWS MediaStore container endpoints, and then everything else, which means web servers. We haven’t covered MediaPackage or MediaStore yet, but I’ll be touching upon those elsewhere in the course. The split between S3 buckets, MediaPackage, MediaStore, and everything else is important. The "everything else" refers to web servers, known as custom origins, and these have different features and restrictions compared to S3 buckets. It's also important to note that an S3 bucket has one set of features, but if you configure static website hosting on that S3 bucket and use it as an origin, CloudFront views it as a web server, so a custom origin, and the feature set available is different.

S3 origins are the simplest to integrate because they’re designed to work directly with CloudFront. Let’s look at exactly what we can configure with an S3 origin. I’ve already got one prepared, so I’ll select it and click on edit. For the origin domain name, this points directly at an S3 bucket. The origin path allows CloudFront to use a particular path inside that origin. By default, any requests made to the default behavior, which points to this origin, will apply to the top level of the bucket. If we wanted to look inside a particular path in that bucket—say, images—we could specify that in the origin path box. Since this is an S3 origin, we have access to various advanced features that we wouldn’t have if we were using custom origins. One of these advanced features is origin access. This is the ability to restrict access to an S3 origin so that it’s only accessible via a CloudFront distribution.

There are two ways of doing this. We have origin access identity, which is the legacy method. Since this is an older CloudFront distribution, I have legacy access identities selected. The new and recommended way is origin access control, and I’ll demonstrate this elsewhere in the course, where you'll get a chance to experience it in practice. For now, we don’t need to worry too much about it. Just know that it means you can restrict an S3 origin so that it's only accessible via the CloudFront distribution. Another important point to realize when using S3 origins is that whichever protocol is used between the customer and the edge location—the viewer protocol policy—is also used between CloudFront and the S3 origin, called the origin protocol policy. These protocols are matched. If you’re using an S3 origin, you have the same viewer-side and origin-side protocol, whether you're using HTTP or HTTPS. Lastly, you can pass through origin custom headers. If you have any headers you want to pass through to the origin, you can do so in the origin settings. That’s pretty much all that can be customized when using an S3 origin.

Everything’s handled for you, but the complex configuration comes when you're using a custom origin. Let’s look at that next. I’ll click on cancel and then click on create origin. For the origin domain name, I’ll type a placeholder, such as catagram.io. CloudFront is smart enough to realize that this isn’t an S3 bucket, so now I get the additional options that we can configure for custom origins. We still have the ability to specify an origin path, which works in the same way as it does for S3 origins. If we want our behavior to point at an origin but instead of using the top level of that origin, look at a sub-path, we can specify that in the origin path box.

Because this is a custom origin, we can be much more granular with some of the configuration options. For example, we can specify a minimum origin SSL protocol. This configures the minimum protocol level that CloudFront will use when it establishes a connection with your origin. Best practice is always to select the latest version supported by the custom origin to ensure maximum security. You can also configure the origin protocol policy. For S3 origins, the viewer protocol and the origin protocol are matched. When you're using a custom origin, you're able to select from one of three options: HTTP only, HTTPS only, or match the viewer protocol policy. If the viewer protocol policy is HTTP, and this option is selected, CloudFront will connect to your custom origin using HTTP. You can explicitly set either insecure or secure protocols, or you can match it, so you need to choose whichever is appropriate for your particular use case.

With custom origins, you also have the ability to pick the HTTP and HTTPS port to use for CloudFront connections between the edge location and the origin. When you're using S3, you can’t configure this because S3 doesn’t have configurable ports. However, when running a custom origin, you might have different services bound to different ports, and you can select the port for HTTP and HTTPS. The default is 80 for insecure HTTP and 443 for secure HTTPS, but you can change these if you're using different ports on your custom origin. These are really important points to remember, especially for the exam. If you see any exam questions discussing custom ports or the ability to configure the origin protocol policy or the minimum SSL protocol versions, then you’ll need to be using a custom origin.

You also still have the ability to pass through custom headers. In this section of the course, I’ll explain how you can secure origins to ensure they’re only accessible via CloudFront. If you’re not using an S3 origin, you won’t be able to use origin access identities or origin access control. Instead, to secure custom origins, you can pass in a custom header that only you’re aware of and have your custom origin check for that header. This allows you to configure your custom origin to only accept connections from CloudFront. This is an important point to remember if you’re aiming for maximum security with custom origins.

That’s everything I wanted to cover in this lesson. I just wanted to give you a quick walkthrough of some important configuration options available for S3 and custom origins. It's fairly common to see CloudFront distributions use S3 origins, as it’s a popular way to deliver static content. If you need to integrate custom origins, you should be aware of those advanced configuration options. For the exam, make sure you’re aware of the different options for custom and S3 origins because these topics come up in multiple questions. With that being said, that covers everything about origins. Go ahead and complete this lesson, and when you’re ready, I look forward to you joining me in the next!

Welcome back, and in this lesson, I want to focus on how CloudFront works with SSL. Each CloudFront distribution receives a default domain name when it's created. It's the default way that you access a distribution, and it's a CNAME DNS record. Now, it looks something like this: it starts with a random part and is always followed by cloudfront.net. You can enable HTTPS access to your distribution by default with no additional requirements as long as you use this address. CloudFront is supplied with a default SSL certificate, which uses star.cloudfront.net as the name. So, it covers all of the CloudFront distributions that use that default domain name.

Most of the time, though, you want to use your own custom name with a CloudFront distribution. For example, cdn.catagram.whatever. This is allowed via the alternate domain name feature, where you specify different names that will be used to access a CloudFront distribution. Once these are added and active, you can point that custom name at your CloudFront distribution using a DNS provider such as Route53TPS. You need a certificate applied to the distribution which matches that name. Even if you don't use HTTPS, you need a way of verifying that you own and control the domain. That way is by adding an SSL certificate that matches the name you're adding to the CloudFront distribution. The result is, whether you want to use HTTPS or not, you need to add a cert to the distribution that matches the alternate domain name you're trying to add.

To do this, you either need to generate or import an SSL certificate using the AWS Certificate Manager, known as ACM. Now, this is a regional service. Normally, you need to add a certificate in the same region as the service you're using. So, a load balancer located in AP Southeast 2 would also need a certificate created within ACM, also in the AP Southeast 2 region. However, exceptions to this exist for global services, and one such global service is CloudFront. For these services, the certificate needs to always be created or added in US East 1. Remember this for the exam, it will come up. For CloudFront, if you're wanting to add any certificates, they always need to be in US East 1, which is the Northern Virginia region.

There are a few options that you can set on a CloudFront behavior in terms of how to handle HTTP versus HTTPS. First, you can allow both HTTP and HTTPS, so no restrictions. You will allow the customer to make the choice about the protocol, whether it's insecure or secure. Second, you can redirect any incoming HTTP connections to HTTPS, which is the option many people use to encourage the use of secure HTTP. Finally, you can restrict a behavior within CloudFront to only allow HTTPS, but this does mean that any HTTP connections will fail entirely.

If you choose to use HTTPS with CloudFront, then you have to have the appropriate certificates that match the name you're using for that distribution. For the exam, understanding certificates is really important, which is what I want to cover in detail in the remainder of this lesson. There are actually two sets of connections when any individual is using CloudFront: first, you've got the connection between the viewer and the CloudFront edge location, and second, the connection between CloudFront and the origin that's being used. These are known as the viewer and origin protocols. For the exam, and really try to commit this one to memory, both of those connections need valid public certificates as well as any intermediate certificates in the chain. The key part here is public. Self-signed certificates, if you see that term, will not work with CloudFront. They need to be publicly trusted certificates.

Now that I've covered the basics of HTTPS with CloudFront, let's quickly move on and touch on something else. One really important thing to understand about CloudFront and SSL for the exam is how it's charged. To understand that and why it is this way, you need a little understanding of how SSL has worked over time. Historically, before 2003, every SSL-enabled website needed its own dedicated IP. The reason why this is critical to understand is important if you want to truly understand SSL. SSL and TLS are often used interchangeably, but in this context, I just mean encryption that happens over a network connection.

The problem is that when encryption is being used as part of HTTPS, that encryption happens at the TCP layer, which is much lower level than HTTP, which is an application layer protocol. You might be aware that a single web server can actually host many websites using different names, all using one single IP address. For example, I could host Catergram and DogoGram on the same server using the same IP address. When using HTTP, this works because your browser tells the server which website you're trying to access through something called a host header. Essentially, your browser tells my server that you're requesting a page from Catergram or DogoGram, and so my server knows which website to serve. This happens at the application layer, Layer 7, after the connection has been established.

TLS, or the encrypted part of HTTPS, happens before this point. When you're establishing the encrypted connection between your device and an IP address, the web server identifies itself. If you don't have a way of telling the server which site you're trying to access, it won't know which certificate to use. This is why historically, it wasn't possible to host multiple HTTPS sites on a single IP address, because each site needed its own certificate, and there was no way for the server to determine which certificate to use for a given request.

In 2003, an extension called SNI, or Server Name Indication, was added to TLS. This feature allows a client to tell a server which domain name it's attempting to access during the TLS handshake, before HTTP even gets involved. With SNI, the client can tell the server it wants to access Catergram, and the server can respond with the Catergram certificate, allowing one IP address to host many HTTPS websites, each with their own certificate. However, not all browsers support SNI. If you want to use CloudFront and support HTTPS connections with a custom certificate and custom domain name, then CloudFront needs to provide dedicated IP addresses for older browsers that do not support SNI.

When using CloudFront, you can either choose to use SNI mode, which is free as part of the service, or you can choose to use a dedicated IP at the edge location, which costs money. As of the time of this lesson, this costs $600 per month per distribution. If you only need to support modern browsers that support SNI, it’s free, and you don’t need to pay any extra. You just need to install your SSL certificate. For older browsers that do not support SNI, you need to pay $600 per month for a dedicated IP address.

With that said, one last thing before we finish is to look at the architecture of SSL in CloudFront visually. So, let’s move on and take a look at that next. Architecturally, this is how it looks: we have a CloudFront edge location in the middle and three origins on the right—an S3 bucket, an application load balancer, and a custom origin, which could either be an EC2 instance or an on-premises web server. On the left, we have customers, with one using a modern web browser at the top, and at the bottom, we have customers with slightly older, pre-2003 browsers.

What you need to understand for the exam is the certificate requirements to support this and how the older browsers influence things. If we have a mixture of clients, some of which include older browsers, with this architecture, we would need to use a dedicated IP, which costs extra. If we only had to support modern browsers that support SNI, then we could use the one shared IP address. In either case, our customers use these IP addresses to connect to one or more edge locations, and this is called the viewer protocol or viewer connection—the connection between the viewers or customers and the edge location.

The key consideration here is that the certificate used by the edge location has to be a publicly trusted certificate, trusted by the web browsers our customers use. This generally means something from major certificate authorities such as Komodo, Digisert, Symantec, or AWS Certificate Manager. If you use AWS Certificate Manager, then, just to reiterate, the certificate must be created in US East 1. I'm going to keep stressing this point throughout any CloudFront-related lessons in the course because it’s a frequent exam topic. For anything CloudFront-related, where it integrates with a regional service, such as logging or certificates, assume you have to interact with it in US East 1.

Any public certificate needs to match the name of the CloudFront distribution it’s applied to. If you add a custom domain name, the DNS needs to point to CloudFront, and the certificate needs to match the DNS name you're using. So, that’s the viewer side secured, and a really important point to stress is that you cannot use self-signed certificates. Only publicly trusted certificates can be applied to CloudFront distributions. That’s another really important point for the exam.

On the other side is the connection between the edge location and the origin or origins, known as the origin protocol. The rules for certificates on this side are similar to the viewer side. They need to use publicly trusted certificates, and again, no self-signed certificates. If your origin is S3, you don't need to worry about anything else because S3 handles this natively. You don’t need to apply certificates to your S3 bucket, and indeed, you can’t change the certificate on an S3 bucket. So, if you're using S3 origins, it's really simple—you just point your CloudFront distribution at the origin, and everything works.

If you're using an application load balancer, it needs a publicly trusted certificate, and you can either use one that’s generated externally or use AWS Certificate Manager to generate a managed one. For custom origins like EC2 instances or on-premise servers, you also need a publicly trusted certificate, but these services are not supported by ACM, so you can’t use ACM to manage the certificate on your behalf. Instead, you need to apply the certificates manually.

In all cases for origins, the certificate needs to match the DNS name of the origin. So, in order for SSL to work as an architecture, the certificate applied to CloudFront needs to match the DNS name of whatever your customers are using to access CloudFront. Then, at the origin side, the certificate installed on any of your origins needs to match the DNS name that CloudFront uses to contact the origin. That’s really important.

Now, that’s everything I wanted to cover for this lesson. Thanks for watching. Go ahead and complete it, and when you're ready, I look forward to you joining me in the next lesson.

Welcome back, and in this lesson, I want to talk about AWS Certificate Manager, or ACM. This is something essential to understand for almost all of the AWS certifications and most real-world projects. You need to know a little bit at the associate level, more at the pro level, and different things matter in each of the different streams: architect, developer, and operations. Now, let's just jump in and get started.

Let's start with the basics to put ACM into context. HTTP, or the Hypertext Transfer Protocol, was initially created without the need for much in the way of security, so no server identity authentication or transport encryption. As HTTP evolved from just text to complex web applications, security vulnerabilities became an issue. For example, if somebody could spoof a website’s DNS name, they could direct users to another potentially compromised web server. Users would be unaware of this because the address displayed by the browser would appear normal, just like they expect. This could be used to gain access to credentials and potentially sniff data in transit.

The evolution of HTTP, HTTPS, or Hypertext Transfer Protocol Secure, was designed to address the problems with HTTP. It uses either SSL or TLS protocols to create a secure tunnel through which normal HTTP can be transferred. In effect, the data is encrypted in transit from the perspective of an outside observer. Now, HTTPS also allows for servers to prove their identity. Using SSL and TLS, servers can be authenticated by using digital certificates. These certificates can be digitally signed by one of the certificate authorities trusted by the web client. Since your web client trusts the CA, you trust the certificate it signs, and that's why you trust the site itself. It makes it harder to spoof.

If the site claiming to be Netflix.com actually has the Netflix.com certificate, which is signed by a trusted certificate authority, then it's almost certain to actually be Netflix.com. To be viewed as secure, a website picks a DNS name like animalsforlive.org, generates a certificate or has one generated for it, signs it, and uses that certificate to prove its identity. So, the DNS name and the certificate are tied together.

Now, ACM can function both as a public certificate authority, generating certificates that are trusted by public web browsers and devices, or as a private certificate authority. This has the same architecture but is something private to your organization, often used by large corporates. With private certificate authorities, you need to configure clients so that they trust the private certificate authority. This is generally done manually by adding this trust into your client laptop and desktop builds or automatically by adding a policy to configure this trust.

In public mode, browsers trust a list of certificate authorities provided by the vendor of that operating system, and these trusted providers can themselves trust other providers, which establishes this chain of trust. With ACM, you can either generate or import certificates. The product can make certificates for you, which just need DNS or email verification to prove that you own the domain. If ACM generates the certificates, it can automatically renew them on your behalf, and you won't have any ongoing issues with expired certificates. If you import certificates generated from another external source, then you are responsible for renewing them, which generally means renewing them with the external source and then importing them again into ACM.

Now, these are really important points to remember for the exam. If ACM generates the certificate for you, it can automatically renew it. If it imports it, you're going to be responsible. Another important point for the exam is that ACM can only deploy certificates to supported services. The certificates are always stored encrypted within the product and deployed in a managed and secure way to those supported services within AWS. However, not all services are supported. In fact, this is generally only CloudFront and load balancers. EC2, for example, which is a self-managed compute service, is not supported because AWS has no way of securing the transfer and deployment. If you manage an EC2 instance and have root access, there will always be a way to access the certificate, and the whole point of ACM is to secure the storage and deployment of those certificates.

That's going to be tested in AWS exams all the time, so be aware that not all AWS services are supported, specifically EC2. Remember that for the exam just to restress: you cannot use ACM with EC2. A few more important things to know before we look at the architecture visually: ACM is a regional service. There is an isolated ACM in US East One, AP Southeast Two, and every AWS region. If you import a certificate into a region or generate a certificate in that region, those certificates cannot leave that region. Once inside, they're locked to that particular region.

Now, and this is really critical for the AWS exams, I cannot stress this enough. If you want to use a certificate within a service, for example, a load balancer in AP Southeast Two, then the certificate needs to be inside ACM in that same region. I’m going to repeat this because it’s that important: To use a certificate from ACM inside a load balancer within a particular region, such as AP Southeast Two, that certificate needs to be within ACM in AP Southeast Two.

There is one exception to this, and it's not really an exception once you understand why. For CloudFront, that service, while being global, should be viewed as running in US East One from an ACM perspective. For CloudFront, conceptually, think about it as the distribution, which is the unit of configuration for CloudFront, being within US East One. And so, you always use US East One for CloudFront certificates. So, one last time: for most services, the certificate needs to be in the same region where the service is located. For CloudFront, always use US East One with ACM. If you generate a certificate in any other region, you won’t be able to deploy it using CloudFront.

Now, let’s look at this visually because everything should start to click. Visually, this is how ACM looks. On the right, we’ve got three regions: US West One at the top, US East One in the middle, and AP Southeast Two at the bottom. Inside each of these regions, we have regionally isolated instances of ACM. Then, also in each region, we have application load balancers together with associated EC2 instances. We also have a CloudFront distribution, associated edge locations, and an S3 origin. For this lesson, the region of the S3 bucket doesn’t matter because we’re focusing on ACM, and S3 does not use ACM for certificates.

On the left, we have some globally distributed users, and on the right, our security specialist. Step number one is that our security specialist will interact with ACM in each of these regions, generate a certificate, and then deploy it out to ACM in each region where service is required. This means that for supported services in those regions, such as application load balancers, those certificates can be used from ACM to services in those regions. What we can't do is deploy cross-region. In this example, from ACM located in US West One to a load balancer located in US East One, cross-region deployment is not supported. Nor can we deploy to unsupported services such as EC2.

For CloudFront, as I mentioned earlier, conceptually think about it as the distribution, the main unit of configuration, being located in US East One. This means when deploying certificates to CloudFront using ACM, the certificate needs to be located in US East One. Once the certificate is linked to the distribution, the distribution can then take the certificate and deploy it out to the edge locations, no matter what regions they're located in.

Once the certificates are deployed onto supported services, they can be used to establish trust from customers to the application load balancer, as with the top example. The same architecture is true for edge locations at the bottom. Once the ACM certificate is deployed to the distribution and then passed out to the edge locations, customers can make secure connections to those edge locations. Now, once again, ACM isn’t used for S3, which handles its own interaction with CloudFront within this architecture, so S3 does not use ACM for any certificates.

Now, that’s all of the architecture I wanted to cover about ACM. It’s everything that you need for the associate or professional level AWS certifications, and enough to get started with the product for any real-world projects. ACM often comes up in the exams focused on diagnosing errors around which certificates can be used in which regions. So now you know that certificates can only be used in the same regions they’re deployed into. Cross-region deployments are not supported, EC2 is not supported, and for CloudFront, from the point of view of ACM, always think of it as being in US East One.

Now, you have all you need with everything I’ve covered in this lesson. Thanks for watching! Go ahead and complete this lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson, I want to talk about CloudFront TTL as well as CloudFront invalidations. Both of these features can be used to influence how long objects are stored at edge locations and when they're ejected. We've got a lot to cover, so let's jump in and get started.

Now let's step through in detail exactly what happens with caching one image at one edge location. A simple architecture consists of an S3 origin on the left, an edge location in the middle, and three users at the top, middle, and bottom right. Let's say we have a photo of Whiskers the cat, and he's crying a little, so it's not his best-ever photo, but that's the one uploaded into the S3 bucket by the Categorum application. Our first customer makes a request for the picture of Whiskers. Since this image is not stored on the edge location, an origin fetch happens where the image is retrieved from the origin and placed on the edge location before being returned to the customer, which is the response.

Now, let's say the image of Whiskers is replaced in the origin. We take away the picture of Whiskers the cat crying and replace it with a much better one, showing a much happier-looking picture of Whiskers. However, now that this image has been replaced on the origin, the copy on the edge location is still the old version. What happens when another customer makes a request to the same edge location? This time, the older or bad image of Whiskers is returned. Why? Because it's the one that's cached at the edge location, and from an object perspective, it's still viewed as valid. Even though the origin has a new version, it’s never checked because the cached copy in the edge location is viewed as valid by CloudFront.

There are ways to influence this, which I'll explain later in the lesson, but for now, you need to understand that this architecture can be problematic. At some point, every object cached by CloudFront will expire. When that happens, it doesn't get immediately discarded, but it's viewed as stale, meaning it's no longer current. If another customer requests a copy of this object, the edge location doesn't immediately return the object. Instead, as with step two, it forwards the request to the origin, and the origin will respond in one of two ways. This depends on the version of the object cached at the edge location versus the one stored in the origin. It's either current, or the origin has an updated object.

If the object is current, then a 304 "Not Modified" response is returned, and the object is delivered directly from the edge location to the customer, marking the copy in the edge location as current again. If there is a difference between the edge location and the origin—meaning the origin has a newer version—then a 200 "OK" message is returned along with the new version of the object, which replaces the one cached at the edge location. This is how an edge location behaves within the CloudFront network.

An object stays in the cache ideally for the entire time that it's valid. However, if the edge location faces capacity issues, it could eject the object early. Even when an object expires, the next time it's accessed, assuming it's still within the edge location cache, the edge location checks the version of the object it has versus the one in the origin. If they're the same, a 304 code is returned, and the object is not updated but marked as current again. A new version is only transferred if the communication between the edge location and the origin determines that the version of the object in the origin has been updated.

The problem to understand is step four on this diagram. The middle user received an old version of the object, even though a newer version was stored in the origin. This is an issue because even though the updated copy existed in the origin, the user received a copy of the old object. This is something to be aware of, as there are ways to influence this, which we will explore further in the lesson.

Now, let's talk about object validity. An edge location views an object as not expired when it's within its TTL (Time to Live) period. Before we go further, it's important to understand that the more often the edge location delivers objects directly to your customer (a cache hit), the lower the load on your origin, which results in better performance for the user. So, where possible, we want to avoid edge locations needing to perform origin fetches, as that would degrade CloudFront's performance.

Objects cached by CloudFront have a default validity period of 24 hours, defined on a behavior within a distribution. The default TTL is 24 hours, meaning any objects cached by CloudFront using this behavior will have a TTL of 24 hours. After this time, the object is viewed as expired. Additionally, you can set two other values: the minimum TTL and the maximum TTL. These values, on their own, do not influence caching behavior but set lower and upper bounds for the TTL of individual objects.

It’s possible to define per-object TTL values. If you don't specify an object TTL, the default TTL attached to the behavior is used (the 24-hour default). An origin, whether an S3 bucket or a custom origin, can direct CloudFront to use object-specific TTL values using headers. These headers include Cache-Control: s-max-age and Cache-Control: max-age, both of which are set in seconds. These headers tell CloudFront to apply a TTL value in seconds for a particular object. Once the specified TTL has passed, the object is viewed as expired.

We also have the Expires header, which works differently from the above headers. Instead of specifying a number of seconds, this header specifies a date and time when the object should be viewed as expired. For both the headers specifying seconds and the Expires header, the minimum and maximum TTL values set on the behavior act as limiters. If a per-object TTL is lower than the minimum TTL for the behavior, the minimum TTL is used, and if it's higher than the maximum TTL, the maximum TTL is applied.

It’s important to understand this architecture. The default TTL on a behavior is 24 hours, and this applies to any object without a per-object TTL set. You can also set minimum and maximum TTL values that act as limiters for any per-object TTLs specified using headers like Cache-Control and Expires. These headers can be set using custom origins or S3. If you're using custom origins, the headers can be injected by your application or web server. If using S3, these headers are defined in the object metadata and can be set via the API, command line, or console UI.

Let's now cover one last topic before we finish the lesson: cache invalidations. Cache invalidations are performed on a distribution, and whatever invalidation pattern you specify is applied to all edge locations within that distribution. Invalidation is not immediate but expires any objects regardless of their TTL based on the pattern you define. Examples include invalidating a specific object using a specific path (e.g., /images/whiskers1.jpeg), using a wildcard to invalidate objects starting with a pattern (e.g., /images/whiskers*), or invalidating all objects in a given path (e.g., /images/*).

There is also the option to invalidate all objects cached by a distribution with the wildcard /*, affecting every edge location. Keep in mind that there is a cost to perform cache invalidations, and this cost is the same regardless of the number of objects matched by the pattern. Cache invalidation should only be used to correct errors, and if you're frequently updating or invalidating individual files, using versioned file names might be a better solution.

For example, using versioned file names like whiskers1_v1.jpeg and replacing it with whiskers1_v2.jpeg allows you to update the file without needing invalidation. This approach avoids the cost of invalidations, ensures that even cached copies in browsers won't interfere with the updated version, and provides better logging and consistency across edge locations.

Remember, versioned file names differ from S3 object versioning, which involves different data stored under the same name. Using versioned file names means different file names for each version of an object, ensuring they are cached independently on each edge location. This approach is cost-effective and consistent, making it the preferred choice when you're frequently updating objects.

That's all the theory I wanted to cover in this lesson. Thanks for watching. Go ahead and complete the lesson, and when you're ready, I look forward to you joining me in the next one.

Welcome back, and in this lesson, I want to quickly step through the architecture of CloudFront behaviors. Now, I've introduced them earlier in this section, so you need to have a good grasp of what options are set at the distribution level and what is configured within a behavior. As I've already introduced behaviors, it's going to be easier for me to show you rather than tell you the details of behaviors and how they fit into the wider CloudFront components. So, I'm going to switch over to my console and step through all the features and exactly how things work.

Okay, so let's take a look at some behaviors. I'll go ahead and move to the CloudFront console. I'll click on services and type CloudFront, then select it from the list. Now, I've got two CloudFront distributions—one of them is production, and one of them is for my testing. The production one is blurred out, so I'm just going to go ahead and move into my testing distribution. Distributions are the unit of configuration within CloudFront, and you'll see that there are lots of high-level options configured at a distribution level. It's here where all of the main important configuration options for the distribution are configured. So, let's take a look at some of them.

First, we've got the price class. The price class determines which edge locations your distribution is deployed to. You can make CloudFront slightly cheaper by selecting to only deploy the distribution to US, Canada, and Europe-based edge locations. This will result in a slightly reduced level of performance for any users not in those regions. You can elect to use all of the edge locations, which provides the best performance, or use the option in between, which deploys to only the US, Canada, Europe, Asia, the Middle East, and Africa. Normally, I like to deploy out to all edge locations because I prioritize customer performance, but you do have the ability to narrow this down and select only the US, Canada, and Europe for deployment. Just keep that in mind.

It's also at a distribution that you're able to associate a web application firewall. This is a layer seven firewall product available within AWS. I'll be covering this elsewhere in the course, but it's at a distribution level that you can configure this integration. You create a web ACL within the WAF product and then associate it with a CloudFront distribution. It's also at the distribution level that you can configure alternate domain names for your CloudFront distribution. Notice how my CloudFront distribution has this default domain name, which is the random string unique for this distribution, followed by CloudFront.net. This is the default, but I did configure an alternate domain name, which is labs-bucket.cantral.io, and this is added at a distribution level.

It's also at the distribution level that you can configure the type of SSL certificate that you want to use with the CloudFront distribution. I'll be talking about this elsewhere in this section, where I focus specifically on CloudFront and SSL, but you're able to use the default certificate as long as you're using that default DNS name. If you want to use an alternate domain name and use that with HTTPS, you need to use a custom SSL certificate. And when you're using a custom SSL certificate, that's defined at the distribution level. It uses ACM, and you have to pick between SNI and non-SNI. I'll be talking about exactly what that means in a dedicated lesson elsewhere in this section.

For the exam, this is important: you can select the security policy to use. There are various different security policies, and AWS updates these periodically. This is generally a trade-off because if you pick a more recent security policy, you can potentially prevent any customers with older browsers from accessing your distribution. You need to pick the one that's the best balance of security and accessibility for your users. As well as that, all the things that are configured at a distribution level are supported HTTP versions, whether you want logging on or off, which I'll cover in another lesson coming up elsewhere in the course. These are all the high-level things that can be configured at a distribution level.

There's also a lot which can be configured from a behavior perspective. A single distribution can have multiple behaviors, and I've mentioned that there's always going to be the one default behavior. Let's open that up, select it, and then click on edit. The way that behaviors work is that for any requests coming into an edge location, their pattern is matched against any behaviors for that distribution using this path pattern. The default behavior has a wildcard or star path pattern, so it matches anything which is not matched by another more specific behavior. Once a path pattern is matched against an incoming request, it's then subject to any of the options specified within this behavior. The most important one is which origin or origin group to use, but you can also select the viewer protocol policy, which defines the policy used between the viewer and the edge location. Options include insecure or secure HTTPS. You can redirect insecure requests towards secure HTTPS or only accept secure HTTPS. These options are configurable on a per-behavior basis, which is important to understand.

You can also select to allow different HTTP methods, and again, that's configured on a behavior. You can configure field-level encryption, which I talk about in a dedicated lesson elsewhere in this section, so I won't go over it here in detail. This allows you to encrypt data from the point that it enters the edge location through the CloudFront network, and again, this is configured on a per-behavior basis. You're also able to set all the cache directives within a behavior. You can do this either using legacy cache settings (which mine is configured using because this is an older distribution) or using the newer cache policy and origin request policy settings, which are recommended by AWS. These settings define methods for caching, the cache, and origin request settings. You're able to set whether you want to cache based on any request headers, with options including non-whitelist or all. Again, this is per behavior.

The minimum TTL, maximum TTL, and default TTL are all set on a per-behavior basis. I'll talk about this in much more detail elsewhere in this section of the course. An important one for the exam is that you're also able to restrict viewer access to a behavior. This is different from restricting access to an S3 origin. This option sets the entire behavior to be restricted or private. If you select this, you need to specify the trusted authorization type, which is either trusted key groups or trusted signers. Key groups are the new way of doing this, while signers are the legacy way. For the exam, if you see trusted key groups or trusted signers, you know that it is set to restrict viewer access, and you need things like signed cookies or signed URLs to access the content. I'll be discussing this elsewhere in the course if appropriate.

Many distributions in the real world will have some behaviors which are non-restricted (for example, sign-on) and some behaviors which are restricted. These control access to sensitive content. It's on a behavior that you can set to compress objects automatically. Additionally, on a per-behavior basis, you can associate Lambda at Edge functions with CloudFront. I talk about Lambda at Edge elsewhere in this section of the course, but it's at the behavior level that you associate these Lambda functions.

From a real-world perspective, you'll always have access to Google and the console, so you can easily remind yourself of exactly which options are set on a per-behavior basis versus the distribution. For the exam, do your best to commit these to memory. Specifically, you need to understand that all of the caching controls are set on a behavior, as well as the restrict viewer access. If you remember that those are behavior-based, you'll also remember that you can have different settings for those options for different behaviors in the same distribution. This will help you answer some of the more complex exam questions you might encounter.

With that being said, that's everything I wanted to cover in this lesson. I just wanted to give you a quick walkthrough to help you understand the different components. Go ahead, complete this lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back. In this lesson, I want to either introduce or refresh your memory on the high-level architecture of CloudFront. We’ll cover what it does, the components it has, and some of the important terminology. This lesson will serve as an introduction or a refresher, so let’s jump in and get started.

CloudFront is a content delivery network (CDN). Its job is to improve the delivery of content from its original location to the viewers of that data, and it does so by caching and using an efficient global network. To illustrate, let’s consider an example where I’m running an application from Australia. The application becomes so successful that it has global users, like Bob on the west coast of the US and Julie in the UK. When they access the application, the data has to travel from Australia to them, but in reality, the route the data takes is often less direct than shown here. Whatever the route, the data travels long distances, which introduces two problems: higher latencies and slower transfer speeds. Both of these impact user experience. Essentially, data is transferred globally every time it is requested, and CloudFront helps us with this challenge.

Before we dive into the architecture of CloudFront, I want to introduce a few key concepts. You might be familiar with some of these terms if you've studied for the Associate Level Solutions Architect Certification. If so, consider this a refresher for some of the more advanced topics that will be covered in later lessons. First, we have an origin, which is the original location of your content. An origin can be an S3 bucket or a custom origin, which refers to anything that runs a web server with a publicly routable IPv4 address. The origin is where your content lives and is served from, and we will discuss more about origins as we move through the section. For one CloudFront configuration, you can have one or more origins.

Next is a distribution, which is the unit of configuration within CloudFront. To use CloudFront, you create a distribution, and this distribution gets deployed to the CloudFront network. Almost everything is configured within a distribution, either directly or indirectly. So, when I mentioned that a CloudFront configuration can have multiple origins, they are all configured inside a distribution, though indirectly, as we’ll discuss later in this lesson. Then, we have edge locations, which are the pieces of global infrastructure where your content is cached. AWS has regions located globally, generally in all major markets, but edge locations are more numerous and distributed closer to your customers. As of the time of creating this lesson, there are over 200 edge locations, with a good chance one is near you. Edge locations are smaller than AWS regions, typically consisting of one or more racks in a third-party data center, with about 90% of storage and a bit of compute for certain AWS services. These edge locations are primarily used for caching data, so you cannot deploy EC2 instances directly to them.

The last term I want to introduce is a regional edge cache, which is much bigger than edge locations and fewer in number. These caches are designed to hold more data, including content that is accessed less frequently but still benefits from being cached closer to customers. Regional edge caches are especially useful in large, global deployments of CloudFront. Now, the upcoming diagram will clarify how regional edge caches and edge locations are related, so let’s take a look at that next.

CloudFront is not that complex architecturally. At a high level, Bob uploads content to an S3 bucket, which will be the origin for his CloudFront distribution. Bob also creates a CloudFront distribution, which is the configuration for CloudFront. On the distribution, he configures the S3 bucket as the origin, and then on the other side of the architecture are the edge locations—global locations that cache the content and distribute it. These edge locations are spread out globally to be as close to customers as possible. Along with the distribution, a domain name is created, usually ending in CloudFront.net and unique to each distribution. You can also use your own domain name for the distribution, such as animalsforlife.org. Once the distribution is configured, it is deployed to the CloudFront network, pushing the configuration to all the chosen edge locations, making them available to customers.

Architecturally, between the edge locations and the origin are the regional edge caches, which are larger and support multiple local edge locations in the same geographic area. Now let’s assume we have two customers, Julie and Moss, located in different cities but within the same continent. When they access the website animalsforlife.org, they are directed to their closest edge location. If Julie accesses the content first, her local edge location is checked for the requested object, such as whiskers.jpg. If it’s cached locally, the object is returned quickly, resulting in a cache hit—this is a good thing. If the object is not cached locally, it’s a cache miss, and the edge location checks the regional edge cache. If the object is in the regional cache, it’s returned from there, and the edge location caches it. If it’s not in the regional edge cache, the content is fetched from the origin and cached at both the regional and local edge locations. When Moss accesses the same content, the process is similar. His edge location checks for the cached object, and if it’s in the regional edge cache from Julie’s earlier request, it’s delivered to Moss.

By deploying CloudFront, you reduce the load on origins and improve performance globally. There are two key things to know about CloudFront: first, it integrates with AWS Certificate Manager (ACM), so you can use SSL certificates with CloudFront. Second, CloudFront is only for download operations; uploads go directly to the origin for processing, as CloudFront performs no write caching. This distinction is important for exam questions that test your knowledge about CloudFront’s caching capabilities.

I want to elaborate on one more point, which will help you understand the following lessons. I mentioned earlier that distributions are the main configuration entity in CloudFront, but they don’t directly store a lot of the important configuration. That’s actually contained within behaviors, which are sub-configurations inside distributions. Behaviors are linked to origins, and they control things like TTL (time-to-live), caching policies, and whether content is public or private. Each distribution has at least one behavior, the default behavior, which matches everything with a wildcard. You can define additional, more specific behaviors, which take priority. For example, if you have private images, you could create a behavior that matches a specific path pattern (like IMG/*), so that different content types can have different configurations. Behaviors allow for more granular control over how content is cached and delivered.

This concludes the quick refresher. In the remaining lessons of this section, I’ll be focusing on key features and functionality provided by CloudFront. For now, complete this lesson, and when you’re ready, I look forward to you joining me in the next.

Welcome back, and in this video, I want to briefly talk about Amazon AppFlow at a high level. In this video, I'll be covering the basics. If you need any other knowledge for the course that you're studying, there will be additional videos. If you only see this one, don't worry, it's everything that you'll need to know. Now let's jump in and get started.

AppFlow is an interesting service in that if you’ve worked in this space and had this specific problem, you’ll immediately see the value that the product provides. If not, you might not get the point. AppFlow is a fully managed integration service, and you can think of it like middleware. It allows you to exchange data between applications using flows. Applications are connected using connectors, and the main unit of configuration in the product is a flow.

A flow consists of a source connector and a destination connector, along with other optional components. But at a high level, the job of the product is to exchange data. Examples of this might include syncing data across applications or aggregating data from different sources together to avoid data silos within your organization. By default, the service uses public endpoints, which allows it to interact with public SaaS applications, but it can also work using PrivateLink to access private sources.

It comes with functionality for connecting to many of the most popular applications by default, but you can also use the custom connector SDK to build your own. Some examples where you might use the product are to sync contact records from Salesforce to Redshift for analysis, or to copy your support tickets from something like Zendesk into S3 for storage or analysis. AppFlow is one of those services that can do a lot, and if you have a need for this type of functionality, you will immediately understand how awesome it is.

Visually, this is how the architecture might look. We start with a flow, and into this, we configure source and destination connections. In this case, the source is Slack, and the destination is Redshift. Connections store the configuration and credentials to access an application. It's important to understand that connections are defined separately from flows so they can be reused across many different flows. It’s using connections, with this example, that the product knows how to connect to Slack and Redshift and what authentication details to use for both of these applications.

Next, within the flow, we define source and destination field mappings, as well as any optional data transformation configurations. This is what, in this example, tells AppFlow what fields we’re interested in from Slack and where to write them in Redshift. We can also define optional filtering and validation within the flow to control what data we want to copy and what checks, if any, should be performed en route. And that, at a high level, is AppFlow. It’s designed to enable you to exchange data between applications in a managed way.

A basic architectural understanding is enough knowledge for most of the AWS exams, and if you need to know more, I'll include additional videos. If you only see this one, this is everything you need to know. At this point, that's everything I’m going to cover in this video. So go ahead and complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson, I want to very briefly touch on Amazon MQ. Amazon MQ is a product that is almost like a merge between SQS and SNS but using open standards. Now, it's something that you need to understand for the exam, so let's jump in and get started, and I'm going to keep this as brief as possible.

To understand when you would use Amazon MQ, it's good to put it into context versus the other AWS products that are similar. SNS and SQS are AWS services that utilize AWS APIs. SNS provides topics, which are one-to-many communication channels, and SQS provides queues, which are one-to-one communication channels. While queues can have multiple compute things adding to the queue and removing from it, conceptually, it's the same worker group at each side, so it's one-to-one communication. Queues are generally used to allow different components of an application to be decoupled.

Now, both of these services, SNS and SQS, are public services within AWS, meaning they can be accessed from anywhere with network connectivity to the public endpoint for those services. They're also both highly scalable and integrated with AWS from an API perspective. Other AWS products can directly use them as well. The problem, however, is that larger organizations might already use topics and queues, meaning they might already have an on-premise messaging system. This on-premise messaging or queuing system might already use certain industry standards. That organization might want to migrate that existing system into AWS, and in that case, SNS and SQS won't work without application modification.

To migrate an existing messaging or queuing system into AWS without application modification, we need a standards-compliant solution. Amazon MQ is an open-source message broker. It's based on a managed implementation of Apache Active MQ, one of the most common enterprise message broker solutions. If you need a system that supports the JMS API or protocols such as AMQP, MQTT, OpenWire, or Stomp, then this means you need Amazon MQ.

The product provides both queues and topics, so it supports both one-to-one and one-to-many messaging architectures, and it does so within the same product. While Amazon MQ is a managed service, it’s not managed in the same way that SNS and SQS are. With Amazon MQ, you're provided with message broker servers, which can either be a single instance for test development or a highly available pair for production usage. One critical thing to understand about Amazon MQ is that, unlike SQS and SNS, it's not a public service. It runs in a VPC, meaning private networking or holes in a firewall are required for anyone who needs to access it. It also doesn't have native AWS integration, so you can't use it with other AWS products and services in the same way as SNS and SQS because other services expect to use SNS and SQS.

So, you do have to keep in mind both the strengths and limitations of this product. In the exam, you will be expected to identify the types of situations when you would select Amazon MQ, and I'll be touching upon that towards the end of this lesson. This is an architecture of SNS, which you've seen before. Publishers add messages to a topic, and subscribers get those messages delivered. SNS as a service runs in the public AWS zone, so it's accessible anywhere with a network connection.

This is how SQS functions. Again, messages can be added to a queue and received at the other side of that queue. Once again, it's an AWS public service, meaning it’s accessible anywhere with network connectivity to the public SQS endpoint. Now, visually, this is how a typical Amazon MQ deployment might look. You might have an existing on-premises environment with an existing messaging infrastructure. In this example, a message producer interacts with an on-premise implementation of Active MQ.

If you want to migrate this into AWS or begin a period of coexistence, then you need an AWS environment. Let’s say we have one with two availability zones, and let's say you provision a highly available pair of Amazon MQ servers in this environment. These servers would deploy a primary and standby and use EFS for shared storage between the two by default. This means data is replicated between availability zones and brokers.

The crucial thing to understand for the exam is that Amazon MQ is not a public service, and this means you need a private network connection between your on-premises environment and AWS. This could be a virtual private network (VPN) or a direct connect. This private networking ensures that the on-premises broker and the AWS managed pair can communicate over this connection. This allows any migrated application to communicate with those brokers using standard protocols and integrate with the on-premises implementation.

Before we finish, I want to go through a few considerations you should be aware of for the exam. Your default position should be to use SNS or SQS for most new implementations where you require topics or queues. You should always select SNS or SQS if you need topics or queues and AWS integration. For example, if you want to take advantage of other AWS services for logging, permissions, encryption, or if you're using other AWS services that expect SNS and SQS to exist, this is a good reason to pick SNS or SQS.

You should choose Amazon MQ if you need to migrate from an existing system with little to no application change, especially if you need to utilize APIs such as JMS or protocols like AMQP, MQTT, OpenWire, and Stomp. Remember, though, if you do decide to use Amazon MQ—and this is really important, as I’ve seen it in several exam questions—you need to make sure that you have the appropriate private networking configured. Amazon MQ is not a public service. It occupies a VPC, and anything accessing the service needs to have access to that networking inside the VPC.

Again, you don't need extensive knowledge of this product for the exam, but I have started to see more and more questions dealing with hybrid-style scenarios where an existing system exists on-premises, and you need to migrate from it into AWS or establish coexistence with that existing system. For both of these architectures, Amazon MQ is an excellent solution. With that being said, that's everything I wanted to cover in this lesson. Go ahead and complete the lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson, I want to talk about AWS Glue. Glue is an interesting product that starts to feature more in the AWS exams and in real-world projects, which I've been exposed to. Now, I'm only going to be talking about it in terms of the architectural theory in this lesson because anything more is well beyond the scope of this course. So let's just jump in and take a look.

AWS Glue is a serverless ETL (Extract, Transform, and Load) system. There's another product within AWS called Data Pipeline, which can also handle ETL processes, but this uses compute within your account. Specifically, it creates EMR clusters to perform the tasks. Glue, on the other hand, is serverless, meaning AWS provides and manages all of the resources as part of the managed service.

At a high level, Glue is used to move and transform data between a source and destination. These sources and destinations can include databases, streams, or other stores of data, such as S3. If you want to take source data and restructure or enrich it, you can use a Glue job to handle that in a serverless way. Glue also crawls data sources and generates the AWS Glue Data Catalog, which I'll cover in more detail next. Glue supports a range of data locations, such as source data stores like S3, RDS, and any JDBC-compatible databases (e.g., Redshift or others), and DynamoDB. Additionally, Glue can work with source streams like Kinesis Data Streams and Apache Kafka, and data targets including S3, RDS, and again, any JDBC-compatible databases.

Now, let's quickly focus on the Data Catalog. AWS Glue provides a data catalog, which is a collection of metadata combined with data management and search tools. Essentially, it's persistent metadata about data sources within a region. The AWS Glue Data Catalog provides one unique data catalog in every region of every AWS account, and it helps avoid data silos. Rather than data being hidden away somewhere, managed by a particular team and not visible to others in the organization, it makes this metadata and data structure available to be browsed and brought into other systems using the ETL features of Glue. This helps improve the visibility of data across an organization.

Various AWS data-related products can use Glue for ETL and catalog services, such as Athena, Redshift Spectrum, EMR, and AWS Lake Formation. They all use the Data Catalog in some way, and the way data is discovered is by configuring crawlers, giving them credentials, and then pointing them at sources and letting them go to work. Visually, this is how the components of Glue fit together. Let’s start with the Data Catalog functionality.

So, we have some data sources on the left: S3, RDS, maybe some JDBC-compatible stores, DynamoDB, Kinesis, Kafka, and more. We configure data crawlers, which connect to these stores, determine schemas, create metadata, and all of this information goes into a data catalog. This means that rather than those data stores being siloed, we now have visibility of them across the organization. The data catalog can be connected to by users of the AWS account, allowing all members of the business to get value from all of the data by using it in areas beyond where it was initially gathered. Essentially, it publicizes data from across an organization and makes it visible, allowing teams like finance to use data that was gathered by different teams within the organization.

The other components of Glue are Glue jobs, and the Data Catalog is also used as part of Glue jobs. Glue jobs are extract, transform, and load (ETL) jobs. Data is extracted from a source and then loaded into a destination, with Glue performing transformations in between using a script that you create. Since Glue is serverless, you don't need to manage the compute used to perform the transformation. AWS maintains a pool of resources, and these are used to perform transformation tasks when required, with billing based only on the resources consumed.

Glue jobs can be started manually or invoked in an event-driven way using events from other sources or scheduled events within EventBridge. That's pretty much what you need to understand about Glue for the exam. It's an extract, transform, and load (ETL) service and a data catalog service that is serverless and forms part of the data and analytics services provided by AWS. Historically, the ETL part of this has been done using Data Pipeline, so in exam questions, you will generally only see one or the other: either Data Pipeline or Glue. If you see both, look for keywords such as serverless, ad hoc, or cost-effective, and if you see these, you should pick Glue rather than Data Pipeline.

Data Pipeline does offer some additional functionality compared to Glue, but over time, my expectation is that the Glue product will replace the functionality offered by Data Pipeline. At this point, though, that's everything I wanted to cover in this lesson. Go ahead and complete the lesson, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to go into some more depth about Amazon Cognito, which is one of the core identity products available within AWS. Now, we do have a lot to cover, so let's jump in and get started. This is going to be one of the most important non-graphical screens of information in the entire course. I want to make sure that you understand the terrible naming within the Cognito product. Cognito provides two main pieces of functionality. Both are very different, but both are essential to understand.

The service as a whole provides authentication, authorization, and user management for web and/or mobile applications. Authentication means to log in to verify credentials, authorization means to manage access to services, and user management means to allow the creation and management of a serverless user database. Now, there are two parts of Cognito: user pools and identity pools, and the naming on these is terrible. This is why most students struggle to understand the detail of how Cognito works. The end goal of a user pool is to allow you to sign in, and if successful, you get a JSON web token, known as a JWT. This JWT can be used for authentication with applications, and certain AWS products such as API Gateway can even accept it directly. But, and this is crucial to understand, most AWS services cannot use JWTs. To access most AWS services, you need actual AWS credentials.

Now, user pools do not grant access to AWS services; their job is to control sign-in and deliver a JWT. So they do things like sign-up and sign-in services. They also provide a built-in customizable web user interface to sign in users. They provide certain security features such as multi-factor authentication, check for compromised credentials, and offer account takeover protection, as well as phone and email verification. You can also implement customized workflows and user migration by using Lambda triggers, and we'll talk about that if applicable elsewhere in the course.

Now, where it gets confusing is that user pools, as well as allowing sign-in from built-in users, they also allow social sign-in using identities provided by Facebook, Google, Amazon, Apple, as well as offering sign-in services using other identity types such as SAML identity providers. But the important thing to understand is this is about offering a joined-up user management experience. At no point can a user pool be used to directly access most AWS resources. When you think of user pools, imagine a database of users, which can include external identities. They sign in and they get a JWT. That's it. I'm stressing this point because it's really important to conceptually separate this from an identity pool, which is coming up next.

Now, the aim of an identity pool is to exchange a type of external identity for a set of temporary AWS credentials, which can then be used to access AWS resources. Now, one option is unauthenticated identities, which can be used to offer guest access to AWS resources. Imagine you have a mobile application and want to allow high scores to be stored in a leaderboard, which is hosted using DynamoDB, and you want to offer this without a user having to sign up, and this is one way to do that. Identity pools can also be used to swap an external identity for temporary AWS credentials, and this means things like Google identity, Facebook, Twitter, SAML 2.0 for corporate logins, and even user pool identities. So from an identity pool perspective, user pools are just treated as another form of identity.

Now, all of these are examples of authenticated identities. If another identity provider, which we trust, says that they have authenticated successfully, then identity pools will exchange that identity for temporary AWS credentials. Now, I hope at this point that you do see the difference. User pools are about offering a joined-up sign-up or sign-in experience with user directory and profile management services. So it's about login and about managing user identities. Identity pools are about swapping either an unauthenticated or authenticated identity for AWS credentials, and one possible type of identity is actually a user pool identity. And this is a reason why these two different components of Cognito are often difficult to separate because they can operate together.

Now, identity pools work by assuming an IAM role on behalf of the identity. That assumption generates temporary credentials, and they're provided back in return in most cases to a mobile or web application. These IAM roles are configured within identity pools, and there's going to be a demo coming up very soon where you can experience that. Now, for the rest of this lesson, let's just step through a few architecture overviews, and I think doing this visually will help you to understand how the product works. First, let's step through an architecture that just uses user pools. Remember, user pools are about user management, sign-in, sign-up, and anything associated with that process.

So we start with a web and mobile application and a Cognito user pool with both internal identities and social sign-in. So anyone can sign in to the pool with any type of identity, and the result is a Cognito user pool token, also known as a JSON web token or JWT. This user pool token proves that the identity has been used to sign in, and it now represents a Cognito user pool user. Whether an internal user is used or a social identity, the authenticated identity is now a user pool identity. And this token can then be used to access self-managed resources such as applications running on servers that you manage or accessing databases which you also manage. It can also be used with an API Gateway, which is capable of accepting user pool tokens directly. Remember, these are known as JWTs. An API Gateway is capable of accepting JWTs for authentication.

So let's focus for a second on what's just happened. A user pool is a collection of identities of users. It's used to allow sign-up and sign-in both for internal users and social sign-ins. The tokens which are generated as a result can be used for self-managed systems, and the tokens can be used to authenticate for API Gateway. But, and this is the single biggest thing to remember about Cognito, these tokens cannot be used to access AWS resources. In general, that requires AWS credentials, and AWS credentials can be handed out via identity pools. So let's look at those next.

So we have the same web and mobile application. This time, though, we aren't using user pools. We're allowing customers to log in directly using external identities. How this works is as follows. We start with a collection of supported external identities. And these include the same social identities, which I've demonstrated previously with user pools. Our application allows users to sign in with any of those external identities. So when they click on a sign-in button within our application, they're directed at an external ID provider sign-in page. You might have experienced one of these before. This is an example of the sign-in with Google page. After a customer authenticates with their Google credentials, which it's worth pointing out that we never have access to, because this sign-in takes place on the external identity provider, in any case, we receive a Google token as a result, but it could be a Facebook token, an Amazon token, or whatever external ID provider is used. Crucially, it can be one of many different types.

If we want to support many different external identity providers, then we need to configure that support. But now that we have this external ID provider token, this proves that a user has logged in with an external ID provider. This token can't be used to access AWS resources, and that's where identity pools come in handy. Our application takes this token and passes it to an identity pool that we've configured. We've configured this to support every external identity that we want to allow logins from. This is a key thing to keep in mind. If we want to support five external ID providers, we need five different configurations, five different types of tokens to be supported.

What happens next is that Cognito is configured with roles, at least one for authenticated identities and one for unauthenticated or guest identities. In this case, we have an authenticated identity, the Google token. And so, on our behalf, Cognito assumes a role and generates temporary AWS credentials, which are then passed back to the application. The application can then use these credentials to access AWS resources. Once they expire, the application renews them again using Cognito, and the process continues. The permissions the application has are based on the roles' permissions. At no point does the application store any credentials within code or any credentials permanently. So the process is that an external identity provider authenticates a user, Cognito identity pools swap the external ID token for temporary credentials, and these are used to authorize access to AWS resources.

So once again, focus on the fact that user pools are about sign-in and sign-up for users, and identity pools are about swapping identity tokens from an external ID provider for temporary AWS credentials. These are two very different and isolated tasks. Now, you can use user pools and identity pools together to fix one small lingering problem. With this configuration, your application has to be able to deal with many different ID tokens from many different external providers. Now, one option is that we could use user pools to handle the many different types of identity, and then we can use identity pools to swap the Cognito user pool token for AWS credentials.

Now, the swapping of any external ID provider token for AWS credentials is known as Web Identity Federation, and you're going to experience that term both in the real world and in the exam. So let's quickly step through the final architecture, which combines both user pools and identity pools. We start with a user pool, and this is configured to support external identities and its internal store of users. Whatever is used, whichever identity type is used to log in, the identity that's authenticated is now a Cognito user pool user. So there's only one type of token which is generated, whether sign-in is using internal users or social sign-in. This is the user pool token or JWT.

By using a user pool, we've abstracted away from all of the configuration of many different external ID providers. We have conceptually one user store to manage, one set of user profiles all provided via a Cognito user pool. So if you log in with a user pool user or if you log in via the user pool but using Google credentials, the outcome is the same. A user pool token is returned to the application, so the user pool simplifies the management of identity tokens. Next, the application can pass this user pool token into an identity pool, and this assumes an IAM role defined in the identity pool, which generates temporary AWS credentials, and these temporary credentials are returned to the application. The benefit to this approach is that the identity pool need only be configured with a single external identity provider, the user pool. But otherwise, the process is the same as using an identity pool directly, just with less admin overhead. The application can then use those AWS credentials to access AWS resources, and that's pretty much everything I wanted to cover.

Now, in summary, user pools manage user sign-up and user sign-in, either internal or using social logins. And what you get as a result is a user pool token, also known as a JSON web token or JWT, and that is the output of any form of sign-in using user pools. Now, identity pools swap external identity tokens for AWS credentials. This process is called federation. External identity tokens can be direct external identity tokens, such as Google, Amazon, Facebook, and many others, or they can be user pool tokens, which can themselves represent external ID logins. Once an application uses an identity pool to gain access to temporary AWS credentials, it can access AWS resources.

Now, this process allows for a near-unlimited number of users. An unlimited is much more than the 5000 IAM user limit, which means this is great for web-scale applications. Now you're going to get experience of identity pools in an upcoming advanced demo. For now, though, that's everything that I wanted to cover. Really try to focus on understanding the two different parts of Cognito really well. I promise it will be helpful for both the exam and for the real world. Now, at this point, that's everything I wanted to cover, so thanks for watching. Go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to cover another product within the Kinesis family, Kinesis Video Streams. Now this product is a little bit different than the others in the family; it's still used for streams but this time for video data. So let's jump in and take a look. Kinesis Video Streams allows you to ingest live video streaming data from producers, and producers can be security cameras, smartphones, cars, drones, or non-video but time serialized data such as audio data, thermal data, depth, or even radar data. Now once the media is inside AWS, then consumers can access the data frame by frame or as needed to perform further analysis, and on the next screen, I'll be demonstrating an architecture involving recognition, which is a service I cover elsewhere in the course.

Kinesis Video Streams can persist data and encrypt data both in transit and at rest, and it does this as a managed service. Now you can't access the data directly that's ingested by Kinesis Video Streams, and that's really critical to understand for the exam. It's not stored in its original format; it's all been indexed and stored in a structured way inside the product, so don't let any exam question fool you into thinking that you can access the data directly on storage such as EBS or S3 or EFS. It's not possible—you have to go via the product itself. Now Kinesis Video Streams integrates with other AWS services, and two really common examples are recognition for live stream deep learning-based analytics, for example, facial recognition, and something like Kinect for voicemail or other audio streaming.

Now let's step through a fairly common style of architecture which uses Kinesis Video Streams and recognition, because this should help you understand all the different components and how they can be used for the exam. Now let's say we have a smart home, so we have a cat, a doggo, and three video cameras, and we want a solution where we can detect any known or unknown faces in the house and alert us if anything is concerning. So those three cameras stream their video feeds into AWS, specifically three Kinesis Video Streams, one per camera. Now this means we don't need any processing in the house, no hardware designed to perform complex analysis on the video, and it means that we've got a location to store the video data in some form outside of the property.

So we configure those three video streams to integrate with recognition video. This is a product I've talked about elsewhere in the course, which provides deep learning-based intelligence for images and video. One of the things that it can do is facial recognition on live video streams, so the Kinesis Video Streams are integrated with recognition and we also define a face collection, so data on some known faces which we expect in our house. So we've got Bob the homeowner, Julie his friend, another random friend, and Whiskers, a small group of cat sitters for when his human minion isn't around. Now recognition then analyzes the streamed data and outputs an analysis to a Kinesis data stream. The analysis includes details of any faces which are detected in the video stream, and in addition to that list of detected faces, it can identify any of those which it has a level of confidence match one of the faces in the face collection.

Now we can configure a Lambda function to be invoked based on records in the Kinesis data streams, so the Lambda function is invoked and can analyze every record in the stream. Then it can make some logic-based decisions based on whether it detects known or unknown faces, and if a face is detected which shouldn't be there, then the Lambda function can utilize the Simple Notification Service (SNS), which can be used to send Bob or Julie a notification. This is an example of a very simple architecture using Kinesis Video Streams and recognition that can be used for an event-driven video analytics workflow. Now the product is capable of doing so much more, but in the exam, if you see any mention of any live video streaming and any analytics that needs to be performed on that video stream, if you see any mention of G streamer or RTSP, then you can probably think about using Kinesis Video Streams as your default answer.

With that being said, though, I don't expect it to feature in the exam in a detailed way, so that's everything that you need to know to cover you for any exam questions. So go ahead, complete this video, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover Amazon Kinesis Data Analytics. This is a real-time data processing product, and it's critical that you understand its features together with when you should and shouldn't use it for the exam. Before I start talking about Kinesis Data Analytics, I want to position the product relative to everything else. Kinesis data streams are used to allow the large-scale ingestion of data into AWS and the consumption of that data by other compute resources known as consumers. Kinesis Data Firehose provides delivery services. It accepts data in and then delivers it to supported destinations in near real-time and it can also use Lambda to perform transformation of that data as it passes through. Kinesis Data Analytics is a service that provides real-time processing of data which flows through it using the structured query language known as SQL. Data inputs at one side, queries run against that data in real-time, and then data is output to destinations at the other.

The product ingests from either Kinesis data streams or Kinesis Firehose and can optionally pull in static reference data from S3, but I'll show you how that works visually in a moment. Now after data is processed, it can be sent on in real-time to destinations, and currently, the supported destinations are Firehose and indirectly any of the destinations which Firehose supports. But keep in mind, if you're using Firehose, then the data becomes near real-time rather than real-time. The product also directly supports AWS Lambda as a destination, as well as Kinesis Data Streams, and in both of those cases, the data delivery is real-time. So you only have near real-time if you choose Firehose or any of those indirect destinations. If you use Lambda or Kinesis Data Streams, then you keep the real-time nature of the data. Conceptually, the product fits between two streams of data: input streams and output streams, and it allows you, in real-time, to use SQL queries to adjust the data from the input to the output.

Now let's look at it visually because it will be easier to see how all of the various components fit together. So on the left, we start with the inputs, the source streams, and this can be Kinesis Streams or Kinesis Firehose. In the middle, we create a Kinesis Analytics application; this is a real-time product, and I'll explain what that means in a second. The Kinesis Analytics application can also take data in from a static reference source, an S3 bucket, and then the Kinesis Analytics application will output to destination streams on the right, so Kinesis Streams or Kinesis Firehose. Remember, all of these are external sources or destinations; they exist outside of Kinesis Data Analytics. Kinesis Data Analytics doesn't actually modify the sources in any way. What actually happens is this: inside the analytics application, you define sources and destinations known as inputs and outputs.

So conceptually, what happens is for the input side, objects called in-application input streams are created based on the inputs. Now you can think of these like normal database tables, but they contain a constantly updated stream of data from the input sources, the actual Kinesis Streams or Firehose. These exist inside the analytics application, but they always match what's happening on the streams which are outside of the application. Now the reference table is a table which matches data contained within an S3 bucket and it can be used to store static data which can enrich the data coming in over the streams. Consider the example of a popular online game where a Kinesis Stream has all of the data about player scores and player activities. In this particular case, the reference table might contain data on player information which can augment the stuff coming in via the stream. So if the stream only contains the raw score and activity data, then the reference data will contain other metadata about those players, so maybe player names, certain items the player has, or awards, and these can all be used to enrich the data that's coming in real-time from Kinesis Streams.

Now the core to the Kinesis Analytics application is the application code, and this is coded using the structured query language, or SQL. It processes inputs and it produces outputs. So in this case, it operates on data in the in-application input stream table and the reference table, and any output from the SQL statement is added to in-application output streams. Again, think of these like tables which exist within the Kinesis Analytics application; only these tables map onto real external streams, so any data that's outputted into those tables by the Kinesis Analytics application is entered onto the Kinesis Stream or Kinesis Firehose, and then these will feed into any consumers of the stream or destinations of the firehose. Additionally, any errors generated by the SQL query can be added to an in-application error stream, and all of this happens in real time. So data is captured from the source streams via the in-application input stream, the virtual tables. It's manipulated by the analytics application using the SQL query, and then stored into the in-application output streams which put that data into either the external Kinesis Stream or external Kinesis Firehose.

All of this just to stress it again happens in real time, and if the output data is delivered into a Kinesis Stream, then it stays real-time. If the output data is delivered into a Kinesis Firehose, then it becomes near real-time, delivering to all of those supported destinations. Now, you only pay for the data processed by the application, but it is not cheap, so you should only use it for scenarios which really fit this type of need. Before we finish this lesson, let's talk about the scenarios where you might choose to use Kinesis Data Analytics. There are some particular use cases or scenarios which fit using Kinesis Data Analytics. At a high level, this is anything which uses streaming data that needs real-time SQL-based processing, so things like time series analytics, maybe election data and e-sports, things like real-time dashboards for games, high score tables or leaderboards, and even things like real-time metrics for security and response teams. Anything which needs real-time stream-based SQL processing is an ideal candidate for Kinesis Data Analytics.

Now, I mentioned in the previous lesson that Data Firehose can also support transformation of data using Lambda, but remember the key differentiator is that Data Firehose is not a real-time product, and using Lambda you're restricted to relatively simple manipulations of data. Using Kinesis Data Analytics, you can create complex SQL queries and use those queries to manipulate input data into whatever format you want for the output data. So it has a lot more in terms of features than Data Firehose, so if you're dealing with any exam questions which need really complex manipulation of data in real-time, then Kinesis Data Analytics is the product to choose. Okay, so with that being said, that's everything that I wanted to cover in this theory lesson. Go ahead and complete the lesson, and then when you're ready, I look forward to you joining me in the next lesson.

Welcome back, and in this lesson, I want to talk in detail about Amazon Kinesis Data Firehose. This is one product out of the Kinesis product set that combines a design to cope with large amounts of streaming data ingestion, consumption, and management within AWS. It's important for the exam that you really understand the different situations when you would use each of the Kinesis family of products. So let's jump in and explore Data Firehose in detail.

You learned in the last lesson that Kinesis Data Streams is a product that provides a way for producers to send huge quantities of data into AWS, storing that data for a window of time, and then allowing multiple consumers to consume that data at different rates. Producers need to be designed to put data into Kinesis, and consumers need to be designed to consume data from Kinesis. What Kinesis by default doesn't offer is a way to persist that data. Once records in Kinesis age past the end of the rolling window, then they're gone forever. Kinesis Data Firehose is a fully managed service to deliver data to supported services, including S3, which lets data be persisted beyond the rolling window of Kinesis Data Streams. Data Firehose is also used to load data into data lake products, data stores, and analytics services within AWS.

Data Firehose scales automatically. It's fully serverless, and it's resilient. Firehose accepts data and offers near-real-time delivery of that data to destinations. Now, this is key for the exam: It is not a real-time product; it is a near-real-time product. Generally, the delay is around the 60-second mark, so it's not like Kinesis, which offers consumers fully real-time access to data that is ingested. Firehose is near real-time, so remember that one for the exam.

Firehose also supports the transformation of data on the fly using Lambda. Anything that you can define in a Lambda function can be done to data being handled by Firehose, but be aware that it can add latency depending on the complexity of the processing. Firehose is a pay-as-you-go service, and you'll be billed based on the data volume passing through the service. It's a really cost-effective service that handles the delivery of data through to supported destinations.

Let’s look at the architecture of Firehose visually. We start with Kinesis Data Firehose in the middle. The end result of Firehose is to deliver incoming data through to a number of supported destinations. Now these are important for you to remember for the exam. You need to be able to pick if Firehose is a valid solution, and for that, you need to know the valid destinations for the service. So, it can deliver data to HTTP endpoints, which means it can deliver to third-party providers. It directly supports delivery to Splunk, Redshift, Elasticsearch, and finally, it can deliver data into S3.

Firehose can directly accept data from producers, or that data can be obtained from a Kinesis Data Stream. So, if you already have a set of producers adding data into a Kinesis Data Stream, you might want to integrate that with Firehose. Remember, these producers are adding data into the Kinesis Stream. That data is available in real-time by any consumers of that stream, but Kinesis offers no way to persist that data anywhere or deliver it natively to any other services. But what we can do is integrate the Kinesis Data Stream with the Kinesis Firehose delivery stream. That data is delivered into Firehose in real-time.

Producers can also send data directly into Firehose if you have no need for the features that Kinesis Data Streams provide or you just want to use Firehose directly. In any case, Firehose receives the data in real-time, but this is where that changes. So, even though Firehose receives data in real-time, Firehose itself is not a real-time service. Kinesis Data Streams are real-time, but Firehose is known as a near-real-time service. What this means in practice is that any data being handled by the service is buffered for delivery. Firehose waits for one MB of data or 60 seconds. These can be adjusted, but these are the general minimums of the product.

For low-volume producers, Firehose will generally wait for the full 60 seconds and then deliver that data through to the destinations. For high-volume producers, it will deliver every MB of data that's injected into the product. So, even though Firehose gets the data in real-time, it doesn't deliver it to the destination in real-time, and that's essential to remember for the exam. If there are any answers involving Firehose, it cannot be a real-time solution. It can only be near real-time. From an AWS perspective, something in the range of 200 milliseconds would be a real-time product, but something in the range of 60 seconds would be classified as near real-time, and you need to get a feel for the differences between those two and which products fit into which categories.

Now, Firehose can actually transform the data passing through it using Lambda. So, source records added to Firehose are sent to a Lambda function, and functions can be created from blueprints to perform common tasks. Transformed records are then sent back for delivery, but this can add to the latency of data flowing through the product. If you decide to do a transform, you can optionally store the unmodified data in a backup bucket that you define. Once the buffer or time buffer passes, data is passed into the final destinations, so transformed records can be sent into S3, Elasticsearch, Splunk, or HTTP endpoints. The only exception to this architecture for delivery is when you're using Redshift.

What happens with Redshift is that it uses an intermediate S3 bucket and then runs a Redshift copy to bring the data from S3 into the product. So, even though conceptually it's direct when used, you're actually copying data to an intermediate location, an S3 bucket, and then you're running the copy command to pull that data into Redshift, and that's handled all end-to-end by the Data Firehose product.

There are a few common situations where Firehose will be used. You might use it to provide persistence to data coming into a Kinesis stream, providing permanent storage of data that comes into a stream so it's not lost when it exits the rolling window that Kinesis Data Streams provide. Or, you might use it if you want to store data in a different format because Firehose can transform it using Lambda. Or you might want to deliver data that comes either directly into Firehose or via a data stream into one of the supported products. But just keep in mind, though, it is not real-time. I need to stress that for the exam—it's only near real-time.

You trade the fact that you don't have to build this yourself, so you don't need to put in the effort to build this solution, but what you lose is the real-time nature of Kinesis. If you need a solution that handles data in real-time, then you need to stick to Kinesis and use something like a Lambda function to handle what to do with that data, say, delivering it in real-time to Elasticsearch.

Now, with that being said, that is everything I wanted to cover in this lesson. For the exam, you just need a good architectural overview of how the Firehose product works and some of the scenarios in which it might be used. So, really try to focus on these core concepts. Exactly what Firehose does, try to commit to memory that it's only a near real-time product, and make sure that you remember all of the supported destinations.

Now, thanks for watching. Go ahead and complete this lesson, and then when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, I want to talk about another product within AWS, Kinesis Data Streams. So, let's just jump in and get started.

Kinesis is a service that a lot of people I talk to confuse with SQS. There are even exam questions which test your ability to select between the two. Now, this shouldn't be a difficult thing to do because they're actually very different products designed for different situations. Kinesis is a scalable streaming service. Now, what I mean by this is that it's designed to ingest data, lots of data from lots of devices or applications. Producers send data into a Kinesis stream. The stream is the basic entity of Kinesis, and it can scale from low levels of data throughput to near infinite amounts of data. Now, Kinesis is a public service and it's highly available in a region by design. You don't need to worry about replication or providing access from a network perspective like other application services within AWS. All of this is handled as a service.

Kinesis Streams provide a level of persistence. You have a default 24-hour rolling window, so when data is ingested by a Kinesis stream from a producer, it's accessible for 24 hours by default from that point. So, data which is 24 hours and one second old is discarded. Now, as a product, it includes storage for that amount of data, so however much you ingest within that 24-hour period, the storage is included. And this window can be increased up to a maximum of 365 days for additional costs. Kinesis supports lots of producers pushing data into a stream, but also multiple consumers reading data from that same stream. And consumers can access data from anywhere within the rolling window, for example, the default 24 hours. And each of these consumers might access this data at different levels of granularity, so maybe looking at data every second, or looking at data points once per minute or once per hour. This makes Kinesis great for things like analytics and dashboards.

Now, visually the product architecture looks like this. On the right, we have producers, and these might be things like EC2 instances, on-premises servers, mobile applications or devices, and even things like IoT sensors. On the left, we have consumers. Again, these could be on-premises servers running software to access Kinesis, EC2 instances, or even Lambda functions which can be configured to invoke when data is added to the stream. In the middle is the stream itself, and it's into this that producers send data, so the stream ingests this data. And it's from this that consumers read the data.

Now, the way that a Kinesis stream scales is by using a shard architecture. A stream starts off with one shard, and as additional scale is required, shards are added to the stream. Now, each shard provides its own capacity: one MB per second of ingestion capacity and two MB per second of consumption. The more shards a stream has, the more expensive it is and the more performance that it provides. Now, what also impacts the price is the data window. As I mentioned previously, by default, a stream provides a 24-hour window, and this can be increased up to 365 days for additional cost. And remember, the window is also persistent, so a 365-day window means 365 days' worth of data stored by Kinesis.

The way that the data is stored on a stream is via Kinesis data records, and these have a maximum size of one MB. Kinesis data records are stored across shards, meaning the performance scales in a linear way based on the number of shards. Kinesis also has a related product called the Kinesis Data Firehose, and there will be a separate video discussing this in more detail. This connects to a Kinesis stream and can move the data which arrives onto a stream en masse into another AWS service, an example being S3. So, if you have a fleet of sensors which stream data into Kinesis and that's used for real-time analysis, but if you also need to store this longer term, maybe to analyze it using a different AWS product such as EMR, which is a big data analytics tool, then you can put that data into S3 using Kinesis Firehose.

Now, I just want to spend a few moments more comparing SQS and Kinesis so that you understand the differences from a conceptual level. Now, one of the common areas of confusion is this difference between these two products. When should you pick SQS versus Kinesis? Well, if you're in the exam and you're reviewing one particular question, then you need to review it through this lens. Is the question about the ingestion of data, or is it about worker pools decoupling, or does it mention asynchronous communications? Well, if it's about the ingestion of data, it's going to be Kinesis. If it's about any of the others, then assume it's SQS first and only change your mind if you have strong reasons to do so.

SQS generally has one thing or one group of things sending messages to the queue. This might be something like a web tier inside an auto-scaling group. Generally, you won't have hundreds or thousands of sensors sending to an SQS queue. It's not designed for that type of workflow. Additionally, you'll generally only have one consumer or group of consumers reading from the queue, generally a worker tier. SQS queues are generally used for decoupling application components. They allow asynchronous communications where the sender and receiver don't need to be aware of each other and don't care about each other. SQS also doesn't really provide the concept of persistence. Messages on a queue are temporary. Once they're received and processed, the next step is deletion, at which point they're gone forever. There's no concept of a time window within SQS queues.

Now, contrast this to Kinesis. It's designed for huge scale ingestion of data. Lots of things sending data into a stream at potentially super high data rates. And it's designed for multiple consumers, each of which might be consuming data at different rates. Kinesis is designed for ingestion, analytics, monitoring, application clicks or mobile click streams. If you think for a minute about the two products, they aren't all that similar, either in function or in terms of the ideal architecture. Try and make sure that before you go into the exam, you really clearly see the distinction between these two products. There's always going to be one or two questions asking you about either of these products and generally one which asks you to pick between them for a given scenario.

Now, that's everything that I wanted to cover in this video at the high level about Kinesis Data Streams. Thanks for watching, go ahead and complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to talk about dead letter queues, which is another piece of SQS functionality that you need to be aware of. So, let's just jump in and get started.

Dead letter queues are designed to help you handle reoccurring failures while processing messages which are within an SQS queue. So, let's say that you have a queue, and inside this queue is a single message, and let's say that this particular message is problematic. Something about it is causing errors while processing it. So, the first time that it's received, it's invisible for the duration of the visibility timeout. Then, once the visibility timeout expires, it appears again in the queue, assuming that it hasn't been successfully processed and then explicitly deleted. But imagine that this process happens again and again. The message is received, processing fails, and eventually, the message appears again after the visibility timeout. This process could continue forever, and it's this issue which dead letter queues aim to fix.

Every time the message is received, the receive count attribute is incremented: initially 1, then 2, then 3, then 4, then 5, and so on. What we can do is define a redrive policy. So, this defines the source queue, the dead letter queue to use, and the conditions where the message will be moved into this dead letter queue, and it defines a variable called max receive count. So, how this works is that when the receive count on a given message is more than the max receive count, and when the message isn't explicitly deleted, it's moved to the dead letter queue.

Setting up a dead letter queue gives you some really useful pieces of functionality. It allows you to configure an alarm for any messages which are delivered to a dead letter queue, so this could automatically notify you if you have any problematic messages. It's a separate area, which allows you to perform separate isolated diagnostics, so you can examine logs for a particular message to determine why it's repeatedly failed processing. You can analyze the contents of messages which are delivered to a dead letter queue to diagnose what's causing the issue, and it also allows you to test or apply separate processing which can be used for problematic messages.

Now, one really important thing to keep in mind when you're using dead letter queues in the real world is that all SQS queues have retention periods for messages. So, if a message ages past a certain point and hasn't been processed, then that message is dropped. Now, the way that this works is that when a message is added to a queue, it has an N queue timestamp, so the timestamp of the point that it was sent into the queue. Now, when you're moving a message from a normal queue to a dead letter queue, this N queue timestamp is not adjusted, so it remains the same. The timestamp is maintained, and it's the date and time when it was added to the original queue. So, you have to be really careful when a message is moved into a dead letter queue. If a message, for example, has been in a source queue for one day, and the retention period on a dead letter queue is two days, the message will only remain in the dead letter queue for one additional day because this original N queue timestamp is used rather than the date and time that the message was moved into the dead letter queue. So, generally, the retention period of dead letter queues should be longer than source queues, and this takes into account that the N queue timestamp is not updated when the message is moved between queues.

So, dead letter queues are a really useful architecture, which allows you to build additional rigor into any processes surrounding queues. It allows you to define this dead letter queue, which helps with diagnostics, and you can add additional processing features which allow problematic messages to be processed, and many other use cases. And finally, a single dead letter queue can be used for multiple source queues, so that's also something to keep in mind.

Now, that's everything I wanted to cover in this lesson. So, thanks for watching, go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover a feature of SQS called delay cues. And this is going to be a quick topic. It's just something that you'll need to understand for the exam and it might come in useful for the real world. So let's just jump in and get started.

Delay cues, at a high level, allow you to postpone the delivery of messages to consumers. Now, as a refresher, by now you'll understand the concept of a visibility timeout. The concept is simple enough, but we'll use this as an opportunity for a quick refresher. So we start with an SQS cue, and inside this cue, we send a single message, which is added to the cue using the send message operation. Once a message is in the cue, messages can be polled using receive message. And while the message is being processed, the visibility timeout takes effect. During this time, any further receive message calls will return no results. During this processing period, either the process will complete and the message will be explicitly deleted or not. If not, this suggests a failure in processing, and the message will reappear on the cue.

Now, the visibility timeout period is configurable. The default is 30 seconds, and the valid range is 0 seconds through to 12 hours. This value can be changed on a per cue or per message basis, in which case it's changed with the change message visibility operation. Now, the critical thing to understand about visibility timeout is that messages need to appear on the cue and be received before this visibility timeout occurs. So, this is used to allow automatic reprocessing. So, you receive messages from a cue and you begin processing. If that processing fails and the application doing it crashes, it might not be in a position where it can tell the cue that processing has failed. And so, visibility timeout means that after a certain configurable duration, that message will reappear in the cue and can be processed again. So, visibility timeout is generally used for error correction and automatic reprocessing.

Now, a delay cue is significantly different. With a delay cue, we configure a value called delay seconds on that cue. Now, this means that messages which are added to the cue will start off in an invisible state for that period of time. So, when messages are added, they're conceptually parked or invisible for that duration of time. They're not available on the cue. During this delay seconds period, any receive messages operation will return nothing. Once the period expires, the message will be visible on the cue. Now, the default is zero, and for a cue to be a delay cue, it needs to be set to a non-zero value, and the maximum is 15 minutes. You can also use message timers to configure this on a per message basis, and this has the same minimum of zero and maximum of 15 minutes. But it is important to know that you can't use this per message setting on FIFO cues. It's not supported.

Delay cues, in a way, are similar to visibility timeouts because both features make messages unavailable to consumers for a specific period of time. But the difference between the two is that for delay cues, a message is hidden automatically when it's first added to the cue. Using visibility timeouts, a message is initially visible, and it's only hidden after it's consumed from the cue and automatically reappears if that message isn't deleted. So, delay cues are generally used when you need to build in a delay in processing into your application. Maybe you need to perform a certain set of tasks before you begin processing a message, or maybe you want to add a certain amount of time between an action that a customer takes and for the processing of the message that represents that action. Visibility timeouts are used to support automatic reprocessing of problematic messages. So, it's important to understand that these two are completely different features.

Now, with that being said, that is everything I wanted to cover in this lesson. I'll make sure I include some links attached to this lesson which provide additional information, but this is what you'll need to understand for the exam and to get started in the real world. At this point, though, you can go ahead and complete the video, and when you're ready, I look forward to you joining me in the next lesson.

Welcome back, and in this lesson, I want to quickly step through the differences between standard SQSQs and FIFO SQSQs. So let's quickly jump in and get started. To get started with understanding some of the architectural differences between standard and FIFO Qs, I want you to think about FIFO Qs as single-lane highways and then think about standard Qs as multi-lane highways. Imagine the messages as cars driving along these highways.

What this means is that the performance of a FIFO Q, so the number of cars per second in this analogy and the number of messages per second in reality, is limited by the width of the road. FIFO Qs can handle 300 messages per second without batching and 3000 width. Now this is actually 300 transactions per second to the SQS API when using FIFO mode. Each transaction is one message, but with batching, it means that each transaction can contain 10 messages. Now it's worth mentioning at this point that there is a high throughput mode for FIFO, but at the time of creating this lesson, it's only available in preview.

Standard Qs, so multi-lane highways in this analogy, don't suffer from any real performance issues and can scale to a near-infinite number of transactions per second. FIFO Qs, as the name suggests, guarantees order. They're first in, first out, so what you're trading is performance for this preserved order. They also guarantee exactly once processing, removing the chance of duplicate message delivery. Now another odd restriction is that FIFO Qs have to have a FIFO suffix in order to be a valid FIFO Q. Now remember that one because I've seen it come up in the exam many times before.

Now FIFO Qs are great for workflow-based order processing, command ordering, so if you've got a system administrator who's entering commands into a processing system and you need the order of those commands to be maintained, then FIFO Qs are ideal, as well as any sequential iterative price adjustment calculations for sales order workflows. Now standard Qs, so the multi-lane highways of Qs, they're faster. Conceptually, think of this as multiple messages being carried on the highway at the same time, so the multi-lane part of this analogy. But because of this, there are a few important trade-offs. First, there's no rigid preservation of message ordering, it's best efforts only. And second, what's guaranteed is only at least once message delivery, meaning in theory messages can be delivered more than once, so any applications that use standard Qs need to be able to accommodate the potential for multiple of the same messages to be delivered.

Now standard Qs are ideal for decoupling application components or for workable architectures or to batch together items for future processing, so all of these are ideal use cases for standard SQSQs. Now that's everything I wanted to cover, I just wanted to make sure that for the exam, you understand the difference in architecture between these two different Q types. Thanks for watching, go ahead and complete the lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover the architecture of another really important product within AWS. It's something I've already mentioned in other lessons, and it's the Simple Queue Service, or SQS. So let's jump in and explore what the product provides and exactly how it works. Simple Queue Service, or SQS, provides managed message queues. And it's a public service, so it's accessible anywhere with access to the AWS public space endpoints, including private VPCs if they have connectivity to the services. It's fully managed, so it's delivered as a service. You create a queue, and the service delivers that queue as a service. Now, queues are highly available and highly performant by design, so you don't need to worry about replication and resiliency. It happens within a region by default.

Now, queues come in one of two types: standard queues and FIFO queues. FIFO queues guarantee an order, so if messages one, two, and three are added in that order to a FIFO queue, then when you receive messages, you'll also see them in order—so one, two, and then three. With a standard queue, this is best efforts, but there's always the possibility that messages could be received out of order. Now, FIFO queues do come with some other considerations, but more on that later. Now, the messages that are added to a queue can be up to 256 kilobytes in size. If you need to deal with any data that is larger, then you can store it on something like S3 and link to that object inside the message. Architecturally, though, ideally, you want to keep messages small because they're easier to process and manage at scale.

Now, the way that a queue works is that clients can send messages to that queue, and other clients can poll the queue. Polling is the process of checking for any messages on a queue, and when a client polls and receives messages, those messages aren't actually deleted from the queue. They're actually hidden for a period of time—the visibility timeout. The visibility timeout is the amount of time that a client can take to process a message in some way. So, if the client receives messages from the queue, and if it finishes processing whatever workload that that message represents, then it can explicitly delete that message from the queue, and that means that it's gone forever. But if a client doesn't explicitly delete that message, then after the visibility timeout, the message will reappear in the queue. Architecturally, this is a great way of ensuring fault tolerance because it means that if a client fails when it's processing a job, or maybe even fails completely, then the queue handles the default action to put the message back in the queue, which makes that message available for processing by a different client. So, the visibility timeout is really important, and it's something that features regularly on the exam. Just be aware that the visibility timeout is the amount of time that a message is hidden when it's received, and if it's not explicitly deleted, then it appears back in the queue to be processed again.

Now, SQS also has the concept of a dead letter queue, and this is a queue where problem messages can be moved to. For example, if a message is received five or more times and never successfully deleted, then one possible outcome of that can be to move the message to the dead letter queue. Dead letter queues allow you to do different sets of processing on messages that can be problematic. So, if messages are being added to the queue in a corrupt way, or if there's something specific about these messages that means different styles of processing are required, then you can have different workloads looking at the dead letter queue. Now, I've already talked about how queues can be used to decouple application components. One component adds things to the queue, another reads from the queue, and neither component needs to be aware of or worry about the other. But queues are also great for scaling. Auto-scaling groups can scale based on the length of the queue, and lambdas can be invoked when messages appear on a queue, and this allows you to build complex worker-pool-style architectures.

Now, this is a pretty common style of architecture that you might see, which involves a queue. So you might have two auto-scaling groups: one on the right is the web application pool, and the one on the left is a worker pool. So, a customer might upload a master video to the web application pool via a web app, and the master video is taken by this web application pool, and it's stored in a master video bucket, and a message is also added to an SQS queue. Now, the message itself has a link to the master video, so the S3 location that the master video is located at, and this avoids having to deal with unwieldy message sizes. At this point, that's all that the web pool needs to do, and that's where the responsibility ends for this particular part of the application. Now, the web pool is controlled by an auto-scaling group, and its scaling is based on the CPU load of the instances inside that auto-scaling group, meaning that it grows out as the load on the system increases. The scaling of the worker pool is based on the length of the SQS queue, so the number of messages in the queue. As the number of messages on the queue increases, the auto-scaling group scales out based on this number of messages. So, it adds additional EC2 instances to cope with the additional processing. So, instances inside this auto-scaling group, they all pool the queue and receive messages. These messages are linked to the master video, which is stored in the master bucket, which they also retrieve. Now, they perform some processing on that video, in this example generating different sizes of videos, and they store them in a different bucket, and then the original message that was on the queue is deleted.

Now, if the processing fails, or even if an instance fails, then it will be reprovisioned automatically by the auto-scaling group, and the message that it was working on will automatically reappear on the queue after the visibility timeout has expired. As the queue empties, the number of worker instances scales back in, all the way to zero if no processing workloads exist. So, the auto-scaling group that's running the worker pool is constantly looking for the length of the queue. When messages appear on the queue, the auto-scaling group for the worker pool scales out, adds additional instances, those instances poll the queue, retrieve the messages, download the master video from the master bucket, perform the transcode operations, store that in the transcode bucket, delete the message from the queue, and the size of the worker pool auto-scaling group will scale back in as that workload decreases. Now, this is an example of a worker-pool elastic architecture that's using an SQS queue. At this point, the responsibilities of the worker pool have finished. It doesn't have any visibility of or care about the health of the web pool. It purely responds to messages that appear inside the SQS queue. So, the effect of the SQS queue is to decouple these different components of this application and allow each of them to scale independently. Once the worker pool has finished its processing, then the web pool can retrieve the videos of different sizes from the transcode bucket and then present these to the user of our application.

Now, this video processing architecture is one that's generally used to illustrate exactly how queues function. So, a multi-part application where one part produces a workload and the other part scales automatically to perform some processing of that workload. It's actually a simplified version of the architecture that would generally be used in a production implementation of this. For workloads like this, where one job is logged and multiple different outputs are needed, generally we would use a more complicated version, which looks something like this. It has a similar architecture, but it uses SNS and SQS fan-out. And the way that that works is, once the master video is uploaded from our application user and placed into the master video bucket, a message is sent, but instead of the message going directly onto an SQS queue, the message is added onto an SNS topic. Now, this SNS topic has a number of subscribers. For each different video size required, there is one independent SQS queue configured as a subscriber to that topic. So, in this example, one for 480p, one for 720p, and one for 1080p. So, each size has its own queue and its own auto-scaling group, which scales based on the length of that individual queue. And this means that if the different workload types need different sizes or capabilities of instances, then they can independently scale.

S3 buckets are capable of generating an event when an object is uploaded to that bucket, but it can only generate one event. So, in order to take that one event and create multiple different events that can be used independently, you'll use this fan-out design. So, you'll take one single SNS topic with multiple subscribers, generally multiple SQS queues, and then that message will be added into each of those queues, allowing for multiple jobs to be started per object upload. Now, I want you to really remember this one for the exam. You can't see me right now, but I'm winking as much as I can. Really, really remember this one for the exam, this fan-out architecture, because it will come in handy for the exam, I promise you. But at this point, let's move on to the last few points that I want to cover before we finish this theory lesson.

I mentioned at the start of the lesson that there are two types of queues: standard and FIFO. It's important that you understand the differences, benefits, and limitations of both of these. So, think of standard queues like a multi-lane highway, and think of FIFO queues like a single-lane road with no opportunity to overtake. Standard queues guarantee at least once delivery, and they make no guarantees on the order of that delivery. FIFO queues both guarantee the order and guarantee exactly once delivery, and that's a critical difference. With standard queues, you could get the same message delivered twice on two different polls, and the order can be different. FIFO queues guarantee exactly once delivery, and also they guarantee to maintain the order of messages in the same order as they were added, so first in, first out.

Now, because FIFO queues are single-lane roads, their performance is limited: 3,000 messages per second with batching, and 300 per second without. So, FIFO queues don't offer exceptional levels of scaling because standard queues are more like multi-lane highways, and they can scale to a near-infinite level, because you can just continue adding additional lanes to that multi-lane highway. So, standard queues scale in a much more linear and fluid way. With SQS, you'll build on requests, and a request is not the same as a message. A request is a single request that you make to SQS. So, one single request can receive between one and ten messages, or zero, and anywhere up to 64 kilobytes of data in total. So, SQS is actually less efficient and less cost-effective the more frequently that you make requests, because you'll build based on requests, and requests can actually return zero messages. The more frequently that you poll an SQS queue, the less cost-effective the service is.

Now, why this matters is there are actually two ways to poll an SQS queue. You have short polling and long polling. Short polling uses one request, and it can receive zero or more messages. But if the queue has zero messages on that queue, then it still consumes a request, and it immediately returns zero messages. This means that if you only use short polling, keeping a queue close to zero length would require an almost constant stream of short polls. Each of these consuming a request, and each of these being a billable item based on the product. Now, long polling, on the other hand, is where you can specify wait time seconds, and this can be up to 20 seconds. If messages are available on the queue, when you lodge the request, then they will be received. Otherwise, it will wait for messages to arrive. Up to ten messages and 64 kilobytes will be counted as a single request, but it will wait for up to 20 seconds until messages do arrive on the queue. Long polling is how you should poll SQS because it uses fewer requests. It will sit waiting for messages to arrive on the queue if none currently exist.

One final point, because messages can live in an SQS queue for some time, anywhere up to 14 days, the product supports encryption at rest using KMS. So, this is server-side encryption. It's encryption of the data as it's stored persistently on disk. Now, data by default is encrypted in transit between SQS and any clients, but you need to understand the difference between encryption at rest and encryption in transit. They're not the same thing. Now, access to a queue is based on identity policies, or you can also use a queue policy. So, identity policies or queue policies can be used to control access to a queue from the same account, but queue policies only can allow access from external accounts. And a queue policy is just a resource policy, just like the ones that you've used earlier in the course on S3 buckets or SNS topics.

Now that's all of the theory that I wanted to cover about SQS queues. Thanks for watching. Go ahead and complete this video, and then once you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to go into a little bit more depth about API Gateway. Now we've got a lot to cover in a single lesson so let's jump in and get started. API Gateway is a service which lets you create and manage APIs. Now an API is an application programming interface, it's a way that applications communicate with each other. So for example if you run the Netflix application on your TV then it's using an API to communicate with the Netflix back-end services.

API Gateway acts as an endpoint or an entry point for applications looking to talk to your services, and architecturally it sits between applications which utilize APIs and the integrations which are the back-end services which provide the functionality of that API. Now API Gateway is highly available and scalable so you don't have to worry about either, it's delivered as a managed service. It handles authorizations so you can define who can access your APIs using the API Gateway, it can be configured to handle throttling so how often individuals can use APIs, it can perform caching to reduce the amount that your back-end services are called as part of the usage of your API, it supports cores so you can control security of cross-domain calls within browsers and it supports transformations and all of this within the API Gateway product.

It also supports the open API spec which makes it easy to create definition files for APIs so APIs can be imported into API Gateway and it also supports direct integration with AWS services. So for things like writing into DynamoDB, starting a step function or anything through to sending messages to SNS topics you might not even need any back-end compute so it's capable of directly integrating with a range of AWS services.

Now API Gateway is a public service and so it can act as the front-end for services running within AWS or on-premises and it can also be an effective migration product to provide a consistent front-end while the backing services are being moved from on-premises into AWS or even re-architected moving from monolithic compute services such as virtual servers through to serverless architectures using Lambda. Now lastly it can provide APIs that use HTTP, REST or even web socket-based APIs.

Now visually this is how the high-level architecture of API Gateway looks. We have API Gateway in the middle here and this is acting as the endpoint for the consumers of our API and this could be mobile applications or the APIs or even web applications loaded from static hosting within an S3 bucket. In any case these all connect to the API running on the API Gateway using the endpoint DNS name.

Now it's actually the API Gateway's job to act as an intermediary between clients and what are called integrations and these are the back-end services which provide the functionality to API Gateway. API Gateway is capable of connecting to HTTP endpoints running in AWS or on-premises, it can use Lambda for compute and this is something that's typically used within serverless architectures and as I mentioned previously it can even directly integrate with some AWS services such as DynamoDB, SNS and step functions.

Now there are three phases in most API Gateway interactions: the request phase which is where the client makes a request to the API Gateway and then this is moved through API Gateway to the service provided by the integrations, and then finally the response phase where the response is provided back to the client. The request phase at a high level does three things: it authorizes, validates and transforms incoming requests from the client into a form that the integration can handle and then the response takes the output from the integration, it transforms it, prepares it and then returns it through to the client.

API Gateway also integrates with CloudWatch to store logging and metric-based data for request and response side operations and it also provides a cache which improves performance for clients and also reduces the number of requests made to the back-end integrations. So that's the high-level architecture and through the remainder of this lesson I want to touch on a number of the pieces of functionality in a little bit more detail and we'll start with authentication.

API Gateway supports a range of authentication methods. Now you can allow APIs to be complete open access so no authentication is required but there are different types of authentication which are supported by the product and let's use the example of the Categorum application which is now serverless. API Gateway can use Cognito user pools for authentication, this is one of the supported methods. If this method is used then the client authenticates with Cognito and receives a Cognito token in return assuming a successful authentication, it passes that token in with the request to API Gateway and because of the tight integration which API Gateway has with Cognito it can natively validate the token.

So that's Cognito but API Gateway can also be extended to use Lambda-based authorization which used to be called custom authorization. With this flow we assume that the client has some form of bearer token something which asserts an identification and it passes this into API Gateway with the request. Now at this point API Gateway not knowing how to natively validate this authentication or authorization it calls a Lambda authorizer and it's the job of this function to validate the request. So it either does some custom compute maybe checking a local user store or it calls an ID provider an external provider of identification to check the ID. If this all comes back okay and the Lambda function is happy it returns to API Gateway an IAM policy and a principal identifier, API Gateway then evaluates the policy and it either sends the request on to a Lambda function so invoking the Lambda function or it returns a 403 access denied error if the access is denied.

Now IAM can also be used to authenticate and authorize with API Gateway by passing credentials in the headers but this level of detail is beyond what's required for the exam. I just think it's useful to give you the architecture visually so you can picture how all the components fit together.

At this point let's move on and talk about endpoint types. With API Gateway it's possible to configure a number of different endpoint types for your APIs. First we've got edge optimized and with edge optimized endpoint types any incoming requests are routed to the nearest cloud front pop or point of presence. We've also got regional endpoints and these are used when you have clients in the same region so this doesn't deploy out using the cloud front network instead you get a regional endpoint which clients can connect into so this is relatively low overhead it doesn't use the cloud front network and this is generally suitable when you have users or other services which consume your APIs in the same AWS region. Lastly we have private endpoint types and these are endpoints which are only accessible within a VPC via an interface endpoint so this is how you can deploy completely private APIs if you use the private endpoint type.

The next concept I want to talk about are API Gateway stages. When you deploy an API configuration in API Gateway you do so to a stage for example you might have the prod and dev stage for the Categorum application. Most things within API Gateway are defined based on a stage so in this case you could have the production application connecting to the prod stage and developers testing new additions via the dev stage. Each of these stages has its own unique endpoint URL as well as its own settings. Each of these stages can be deployed onto individually so you might have version one of the API configuration deployed into production and this uses version one of a lambda function as a backing integration and then we might have version two which is currently under development deployed into the dev stage and this also could use a separate backing lambda function containing the new code.

Now you can roll back deployments on a stage so they can be used for some pretty effective isolation and testing but what you can also do with API Gateway stages is to enable canary deployments on stages. What this means is that when enabled any new deployments which you make to that stage are actually deployed on a sub part of that stage the canary part of that stage and not the stage itself. So traffic distribution can be altered between the base stage and the canary based on a user configurable value and eventually the canary can be promoted to be the base stage and the process repeated.

In this example it means that version two of the API configuration can be tested by the development team and then canary can be enabled on production, version two can be deployed onto production and this will be deployed into the canary because canary is enabled on the production stage. We can adjust the distribution of traffic between the main production stage and its canary until we can completely happy and then we can promote the canary to be the full base stage and this process of development production cycles can then continue. If you're not happy with how a canary is performing, if it's got bugs or if it's negative in terms of performance then you can always remove it and return back to the base stage.

Now at this point I have to apologize I hate getting you to remember facts and figures but for the exam I genuinely think these facts and figures might help so do your best to note them down and remember them even if you only do it at a high level even if you only get the basics I think it will help you answer certain exam questions quicker and with less thought.

So to start with error codes generated by API gateway are generally in one of two categories: first we have 400 series error codes and these are client errors this suggests that something is wrong on the client side so something wrong either on the client or in terms of how it's making a request through to API gateway maybe permissions are wrong maybe headers are malformed anything that's on the client side, then we have 500 series errors and these are server errors so this indicates that there's a valid request but there's a back-end issue.

Now inside both of these categories there are a number of important requests that you need to remember the error code number four and I want to step through these on this part of the lesson. So 400 – 400 this is one that's really hard to diagnose because it can actually have many different root causes but if you do see a 400 error then you should at least be aware that it's a generic client side error, we've got 403 and this suggests an access denied error so either that the authorizer has executed and then indicates to API gateway that the request should be denied or the request has been filtered by something like the web application firewall.

Next we've got a 429 error code and this is an indication that throttling is occurring, I mentioned earlier that API gateway can be configured to throttle requests so if you're getting a 429 error it means that you've exceeded a configured throttling amount so 429 associate that with throttling. Now if you get a 502 error this is a bad gateway exception and this indicates that a bad output has been returned by whatever is providing the backing services so if you've got a lambda function servicing request your API then a 502 error suggests that that lambda is returning something that's invalid. A 503 error indicates service unavailable so this could indicate that the backing endpoint is offline or you're having some form of major service issues so 503 is definitely one to remember I have seen that come up in the exam. 504 indicates an integration failure now there is a limit of 29 seconds for any requests to API gateway so even though lambda has a timeout of 15 minutes if lambda is providing backing compute for an API gateway API then if that request takes longer than 29 seconds then this can generate a 504 error so you need to make sure that any lambda functions that are backing your APIs are capable of responding within that 29 second limit otherwise you might get 504 errors.

And I've included a link that's attached to this lesson which details all of the error codes as well as a little bit more detail if you do want to use it for extra reading. Now one final thing before we finish up with this in-depth lesson for API gateway and that's to talk about caching. Now you should be familiar with the general concept of caching at this point in the course as it relates to API gateway. We start in the middle with an API gateway stage and this is important because caching is configured per stage, this matters both for the exam and if you're developing this infrastructure for production situations.

Now what happens without a cache is that any users at the application make requests to the API gateway stage and there are some back-end integrations which service those requests. Without a cache those services would be used on each and every request. With caching though you define a cache on that stage, it can be anywhere from 500 mb to 237 gb in size, it caches things by default for 300 seconds and this can be configured from zero meaning disabled through to a maximum of 3600 seconds, and a point that you should know for the exam is that this cache can be encrypted.

Now using a cache means that calls will only be made to the back end when there's a cache miss and this means reduced load, reduced cost and improved performance because of the lower latency that caching provides. Okay so that's everything I wanted to cover in this in-depth lesson on API gateway, this is definitely a service where you need to be aware of much more in the developer and operation streams of AWS certifications. At this point though that is everything that I'm going to be talking about so go ahead complete this lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I'm going to be covering AWS Step Functions. To understand why Step Functions exist, we need to look at some of the problems with Lambda that it addresses. Step Functions address some of the limitations of Lambda, or not so much limitations, but design decisions that have been made with the Lambda product. No product is perfect, and it's important to understand the product limitations or the design decisions which have been implemented as a product has been created.

Now you know by now that Lambda is a function-as-a-service product, and the best practice is to create functions which are small, focused, and do one thing very well. What you should never be doing with Lambda is trying to put a full application inside a Lambda function, A because it's bad practice, and B because there's an execution duration limit of 15 minutes. A Lambda function cannot run past this 15-minute limit for its execution duration. Now you can, in theory, chain Lambda functions together so one Lambda function reaches its end and it directly invokes another, and by doing this, in theory, you can get another 15 minutes, but this gets messy at scale.

What you're doing is building a chain of functions in an attempt to create a long-running flow, and this isn't what Lambda's designed for. It's made worse due to the fact that Lambda runtime environments are stateless; each environment is isolated, cleaned each time, and any data needs to be transferred between the environments if you want to maintain any form of state, which is why you can't hold a state through different Lambda functions or different Lambda function invocations.

Imagine an example where you might have an order processing system — you can upload a picture of your pet, maybe a cat or a dog or a lizard, and have it printed on different types of material, maybe glass, metal or high-quality paper. This process can take more than 15 minutes, and it will involve lots of decision points, potentially manual human intervention. There's a state — the order, the process — it's all data that needs to persist, and doing it by chaining together lots of Lambda functions is really, really messy.

Step Functions as a service let you create what are known as state machines. Think of a state machine as a workflow — it has a start point and it has an end point, and in between there are states. States you can think of as things which occur inside the state machine — states can do things, they can decide things, and they all take in data, modify data, and output data. So states are the things inside these workflows. Conceptually, the state machine is designed to perform an activity or perform a flow which consists of lots of individual components and maintain the idea of data between those states.

Imagine that you're ordering something from an online retailer such as Amazon.com — so you complete the purchase, and behind the scenes, between you completing the purchase and you receiving your goods, lots of things happen behind the scenes. Your stock is located, it's physically picked, it's packed and verified, postage is booked, and when it's dispatched your order is flagged as being dispatched, and that's an example of a long-running order flow. With Amazon it might only take a few hours to move through this flow from beginning to end, but with something more bespoke it could take longer, and that's why the maximum duration for state machine executions within Step Functions is one year.

Now there are actually two types of workflows available within Step Functions — we've got Standard and Express. When you create a state machine, you need to choose between the two, and it influences some of the features — so the speed and the maximum duration. For the exam, you only need to remember that at a high level, Standard is the default and it has a one-year execution limit. Express — that's designed for high-volume event processing workloads such as IoT, streaming data processing and transformation, mobile application backends, or any of those types of workloads — and these can run for up to five minutes, so you would use Standard for anything that's long-running and Express for things that are highly transactional and need much more in terms of processing guarantees.

Now, state machines can be started in lots of different ways — a few examples are using the API Gateway, IoT rules, you might use EventBridge if you're wanting to use event-driven architectures, Lambda can initiate state machines, and you can even do it manually. Generally, state machines are used for backend processing, so something in your application will initiate a state machine execution. With state machines, you can use a template to create and export state machines once they're configured to your liking — it's called Amazon States Language or ASL, and it's based on JSON, and you'll use this yourself during the demo lesson which is coming up later in this section.

Now, state machines, like any other AWS services, are provided with permissions to interact with other AWS services by using IAM roles. The state machine assumes the role while running, and it gets credentials to interact with any AWS services that it needs to. Before we look at the state machine architecture visually, I want to focus on states themselves — I want you to understand the type of states that exist, so let's look at that next.

As a reminder, states are the things inside a workflow — the things which occur — so let's step through what states we have available. First we've got the Succeed and Fail states, and basically if the process through a state machine ever reaches one of these states, then it succeeds or it fails depending on which of these states it arrives at — that's nice and easy.

Next we've got the Wait state, and the Wait state will wait for a certain period of time or it will wait until a specific date and time. It's provided with this information as an input, and it holds or pauses the processing of the state machine workflow until the duration is passed or until that specific point in time.

Next we've got Choice — and Choice is a state which allows the state machine to take a different path depending on an input, and it's useful if you want a different set of behavior based on that input. For example, you might want a state machine to react differently depending on the stock levels of an item in an order, so the Choice state allows you to have a choice inside a state machine, and you'll be using the Choice state as part of the demo later in this section.

Next we've got the Parallel state, and the Parallel state allows you to create parallel branches within a state machine — so you might want to take a certain set of actions depending on an input, and that might use the Choice state, but one of those choices might be to perform multiple sets of things at the same time. So you might have one of the choices of a Choice state leading to the Parallel state, and that's exactly what you're going to implement in the demo lesson at the end of this section.

Next we've got the Map state, and a Map state accepts a list of things — an example might be a list of orders — and for each item in that list, the Map state performs an action or a set of actions based on that particular item. So if you have 10 items being ordered inside an order, you might have a Map state that performs a certain set of things 10 times — one for each of those items on that order.

Now these are all examples of states, but they are states which control the flow of things through a state machine. The last type of state that I want to talk about is a Task state, and a Task state represents a single unit of work performed by a state machine. So it's the Task states themselves that allow you to perform actions — it allows the state machine to actually do things.

So a Task state can be integrated with lots of different services — so things like Lambda, AWS Batch, DynamoDB, the Elastic Container Service, SNS, SQS, Glue, SageMaker, EMR, and lots of different AWS services — and when you configure this integration, that's how a state machine can actually perform work. So what it does to do the work itself — the architecture of a state machine is that it coordinates the work occurring, so a state machine has different states that control flow through that state machine, and then it has Task states which coordinate with other external services to perform that actual work.

Now let's look at how all of this fits together visually because it will make a lot more sense. For this example, we're going to use the scenario that we're going to look at in the demo lesson at the end of this section. The scenario that we have is a serious one — Bob has a cat called Whiskers who can never get enough cuddles. It's become so bad that poor Whiskers has had to design a Step Functions-powered serverless application to remind his human minion Bob every time a cuddle is required.

Whiskers wants to be in full control of the frequency of the cuddles, and there are times when Whiskers might need a cuddle within a few minutes, but sometimes it could be more than 15 minutes or even hours away. He wants to be able to notify his human minion when the next cuddle is needed however far away he is, and so there needs to be multiple ways of reminding Bob. Bob isn't always around, and so the reminder method needs to be flexible.

We need email reminders so that if Bob is at a computer he can receive the reminder, and we also need an SMS reminder so if Bob isn't at home he can immediately rush home to cuddle Whiskers. Now because Whiskers is a cat, and because he's fussy, the time between cuddles could be longer than 15 minutes, so we can't use Lambda — so we're going to use Step Functions. Step Functions work with a base entity called a state machine, and the Pet Cuddle-A-Tron will use one state machine.

Inside the state machine are a number of states — first we've got a Wait state called Timer, and Timer waits for a predefined amount of time, the time period that you set until the next cuddle is required. Then we have a Choice state, and the state machine is pretty flexible — it allows you to decide on three methods of notification: email-only notification, SMS-only notification, or both. The Choice state has three paths that it can direct progress down depending on which option is chosen.

The choices are three Task states — we've got Email Only, we have SMS Only, and we've got Email and SMS, and there are two Lambda functions — Email Reminder and SMS Reminder. Depending on the choice taken, one or both of these Lambda functions are invoked as part of the state machine execution. If the Email Only choice is taken, then logically this only invokes the Email Reminder Lambda, and this uses the Simple Email Service to send an email to Bob demanding a cuddle.

If the SMS Only choice is taken, then this performs the same action but for SMS only — so Bob will receive a text message with Whiskers' cuddle-based demands. If the Email and SMS choice is taken, then this performs both actions — it invokes both Lambda functions so Bob receives both an email and an SMS reminder.

Now the back end of this application is provided by the Step Function service in the form of a state machine, but the whole application end to end is actually implemented as a serverless application. Bob has a laptop and it downloads the client-side web application from an S3 bucket — so inside this S3 bucket we have HTML and JavaScript, and the JavaScript lets Bob's browser connect to a managed API hosted by the API Gateway.

The API Gateway is what Bob's browser communicates with, and this is backed up by a Lambda function, and the Lambda function is the thing that behind the scenes provides the compute service necessary to interact with the JavaScript running on Bob's laptop. The combination of both of these allows Bob's laptop to initiate the execution of the state machine every time he sets a cuddle reminder. So the state machine is actually invoked by Bob clicking on a button on a web page that's provided by this serverless application.

Now you'll see this when you open the Pet Cuddle-A-Tron application — it will just be a HTML page that's loaded from an S3 bucket, but it will ask you for a number of pieces of input. You'll get asked for the number of seconds until the next cuddle, as well as a custom message, and depending on the notification method that you pick, you'll need to enter either an email address or a phone number or both.

When you've entered all of the required information based on which method of notification you'll select, you'll click on one of three buttons — one for Email Only, one for SMS Only, and one for Both — and clicking on that button generates an event. This communicates with the API Gateway, it causes an invocation of the API Lambda function, and the API Lambda function passes all of the information entered on this serverless web app all the way through to the state machine.

The state machine begins its execution based on the options that you've selected — it waits for a certain period of time, and then it makes a choice based on your selected notification method, and then it invokes one or both Lambda functions that will either send you an email and SMS or both.

And this is the application that you're going to implement in the Pet Cuddle-A-Tron demo lesson in this section of the course. Now if this looks complicated, don't worry, because we'll be implementing this piece by piece, bit by bit, together. I'll be around every step of the way to guide you on exactly how to implement this fairly complex architecture inside AWS.

I promise you by the end of the demo lesson it will make complete sense. In summary, Step Functions let you create state machines, and state machines are long-running serverless workflows — they have a start and an end, and in between they have states, and states can be directional decision points, or they can be tasks which actually perform things on behalf of the state machine. And by using them, you can build complex workflows which integrate with lots of different AWS services. But at this point, that's it for the theory — so go ahead and complete this lesson, and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to cover the theory and architecture for the simple notification service or SNS. SNS is a key component of many architectures within AWS so it's one which you need to fully understand. So let's jump in and get started because I really want to make sure that you understand SNS end to end.

Simple notification service or SNS is a highly available, durable, secure, pub/sub messaging service. It's a public AWS service meaning to access it you need network connectivity with the public AWS endpoints, but the benefit of this is that it's accessible from anywhere that has that network connectivity. What it does at a high level is coordinate the sending and delivery of messages, and messages are payloads which are up to 256 kilobytes in size. Now I'm not mentioning the size because you need to know it exactly for the exam but more so so that you understand that you can't send an entire cat movie using the service. Architecturally, messages are not designed for large binary files.

Now the base entity of SNS is the SNS topic, and it's on these topics where permissions are controlled as well as where most of the configuration for SNS is defined. SNS has the concept of a publisher, and a publisher is the architectural name for something which sends messages to a topic. With a pub/sub architecture, publishers send things into a topic. Now as well as publishers, each topic can have subscribers and these by default receive all of the messages which are sent to the topic.

Now subscribers can come in many different forms. We've got things like HTTP and HTTPS endpoints, email addresses which can receive the message, SQS queues where each message is added to the queue as it's sent to the topic. Topics can also be configured with mobile push notification systems as subscribers so that messages sent to a topic are delivered to mobile phones as push notifications or as SMS messages. Even Lambda functions can be subscribed to a topic so that that Lambda function is invoked as messages are sent into the topic.

SNS is used across AWS products and services. CloudWatch uses it when alarms change state, CloudFormation uses it when stacks change state, and Auto Scaling groups can even be configured to send notifications to a topic when a scaling event occurs. SNS is one of those subjects which is a lot easier to understand if you look at it visually, so let's move on to an architecture diagram.

Now the SNS service as I just mentioned is a public space AWS service. It operates from the AWS public zone, and because of that the service can be accessed from the public internet assuming the entity trying to access it has the relevant AWS permissions. And assuming that a VPC is configured to be able to access public AWS endpoints, then SNS can be accessed from a VPC as well. SNS as a service runs from this public zone and you can create topics inside of SNS. For each topic, a wide variety of producers — so external APIs running on the public internet or CloudWatch or EC2 or Auto Scaling groups or CloudFormation stacks and many other AWS services — can publish messages into a topic.

The topic has subscribers, and things can be subscribers and producers at the same time, for example APIs. Any subscribers by default will receive all of the messages sent to the topic by publishers, but it's possible to apply a filter onto a subscriber which means that subscriber will only receive messages which are relevant to its particular functionality.

Another interesting architecture that I want to comment on just briefly is the fan out architecture, and this is when you have a single SNS topic with multiple SQSQs as subscribers — and we'll be covering SQSQs later in this section — but this is a way that you can create multiple related workloads. So if for example a message is sent to an SNS topic when a processing job arrives, that message can be added to multiple SQSQs which are configured as subscribers for that SNS topic. Now each of these Qs might perform the same related processing but using the pet tube as an example might work on a different variant, so there might be processing a different bitrate or a different video size. So using fan out is a great way of sending a single message to an SNS topic representing a single processing workload and then fan that out to multiple SQSQs to process that workload in slightly different and isolated ways.

Now the functionality that's offered by SNS is pretty important. It really is a foundational service for developing application architectures within the AWS platform. So SNS offers delivery status, so with a number of different types of subscribers you can confirm the status of delivery of messages to those subscribers. An example of some subscriber types that do support delivery status is HTTP or HTTPS endpoints, Lambda and SQS. As well as delivery status, SNS also supports delivery retries, so you've got the concept of reliable delivery within SNS.

SNS is also a highly available and scalable service within a region. So SNS is a regionally resilient service, so all the data that's sent to SNS is replicated inside a region. It's scalable inside that region so it can cope with a range of workloads from nothing all the way up to highly transactional workloads, and it's also highly available. So if particular availability zones fail, then an SNS topic will continue to function.

SNS is also capable of server-side encryption or SSE, which means that any data that needs to be stored persistently on disk can be done so in an encrypted form, so this is important if you do have any requirements which mandate the use of on-disk encryption. Now SNS topics are also capable of being used cross-account just like S3 buckets. You can apply a resource policy — in the case of an SNS topic this is a topic policy — it's exactly the same. It's a resource policy that you apply to the resource, the SNS topic, and you can configure from a resource perspective exactly what identities have access to that topic.

Now you'll need to know all of this architecture relating to SNS for the exam. And SNS really is one of those topics that you'll be using extensively as you deploy projects inside AWS, but for now that's everything that you need to know about SNS. You will, as we go through the course, get more and more experience with the products, but I wanted to illustrate all of the important pieces of architecture at this point. So go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover the serverless architecture. Serverless is a type of architecture which is relatively commonplace within AWS, mainly because AWS includes many products and services which support its use. The key thing to understand about the serverless architecture, aside from the fact that there are really servers running behind the scenes, is that it's not one single thing, and while serverless is an architecture, it's more a software architecture than a hardware architecture.

The aim with the serverless architecture—and where its name comes from—is that as a developer, architect, or administrator, you're aiming to manage few, if any, servers, because servers are things which carry overhead, such as cost, administration, and risk, and the serverless architecture aims to remove as much of that as possible. In many ways, serverless takes the best bits from a few different architectures, mostly microservices and event-driven architectures, and within serverless you break an application down into as many tiny pieces as possible, even beyond microservices, into collections of small and specialized functions.

These functions start up, do one thing really, really well, and then they stop. In AWS, logically, because of this, Lambda is used, but there are other platforms such as Microsoft Azure which has their own equivalent, namely Azure Functions, and from an architecture perspective, the actual technology which is used is less relevant. These functions which make up your application run in stateless and ephemeral environments, and why this matters is because if the application is architected to assume a clean and empty environment, then these functions can run anywhere.

Every time they run, they obtain the data that they need, they do something, and then optionally, they store the result persistently somehow or deliver that output to something else. The reason why Lambda is cheap is because it's scalable, each environment is easy to provision, and each environment is the same, so the serverless architecture uses this to its advantage, where each function that runs does so in an ephemeral and stateless environment.

Another key concept within serverless is that generally everything is event-driven, which means that nothing is running until it's required, and any function code that your application uses is only running on hardware when it's processing a system or customer interaction—an event. Serverless environments should use fast products such as Lambda for any general processing needs, since Lambda as a service is built based on execution duration, and functions only run when some form of execution is happening.

Because serverless is event-driven, it means that while not being used, a serverless architecture should be very close to zero cost until something in that environment generates an event, so serverless environments generally have no persistent usage of compute within that system. Now, where you need other systems beyond normal compute, a serverless environment should use, where possible, managed services—it shouldn't reinvent the wheel.

Examples are using S3 for any persistent object storage, or DynamoDB (which we haven't covered yet) for any persistent data storage, and third-party identity providers such as Google, Twitter, Facebook, or even corporate identities such as Active Directory, instead of building your own. Other services that AWS provides, such as Elastic Transcode, can be used to convert media files or manipulate these files in other ways.

With the serverless architecture, your aim should be to consume as a service whatever you can, code as little as possible, use function as a service for any general-purpose compute needs, and then use all of those building blocks together to create your application. Now, let's look at this visually, because I think an architecture diagram might make it easier to understand exactly what a serverless architecture looks like, so let's step through a simple serverless architecture, and we're going to do so visually.

I want your default position to be that unless we state otherwise, you're not using any self-managed compute—so no servers and no EC2 instances—unless we discuss otherwise, and that should be your starting position. At each step throughout this architecture, I'll highlight exactly why the parts are serverless and why it matters.

Now, we're going to use a slightly more inclusive example—this time, we're going to use PetTube, which was rebranded to be a little more inclusive after an uproar about it only being for cats. To start with, we've got Julie using her laptop, and she wants to upload some woofy holiday videos, so she browses to an S3 bucket that's running as a static website for the PetTube application, downloads some HTML, and that HTML has some JavaScript included within it.

One crucial part of the serverless architecture is that modern web browsers are capable of running client-side JavaScript inside the browser, and this is what actually provides the front end for the PetTube application—JavaScript that's running in the browser of the user that's downloaded from a static website S3 bucket. So at this point, the application has no self-managed compute that's being used—we've simply downloaded HTML from an S3 bucket with some included JavaScript that's now running in Julie's web browser.

Now, PetTube uses third-party identity providers for its authentication; like all good serverless applications, it doesn't use its own store of identity or its own store of users, which results in lower admin overhead, and also avoids the limit on the number of IAM users that can exist inside one AWS account, which is 5,000 IAM users per account. So if we used IAM users for authentication, then PetTube would be limited to 5,000 users, and each user of the application would need one additional account—one additional username and one additional password.

Instead of doing that, we use a third-party identity provider, and one that our users are already likely to have an account inside, so that reduces the number of accounts that our users are required to maintain. The JavaScript that's running in Julie's browser communicates with the third-party identity provider, and we're going to assume that we're using Google, and you'll have seen the screen that's generated if you've ever logged into Gmail or anything that uses Gmail logins—but this could just as easily be Twitter, Facebook, or any other third-party identity provider.

The key thing to understand is that Julie logs into this identity provider, and it's this identity provider that validates that the user claiming to be Julie is in fact Julie, so it checks her username and password, and if it's happy with the process—or if it's happy with the username and password combination that Julie's provided—then it returns to Julie an identity token, which proves that she's authenticated with the Google identity provider.

Now, AWS can't directly use third-party identities, and so the JavaScript that's running in Julie's browser communicates with an AWS service called Cognito, and Cognito swaps this Google identity token for temporary AWS credentials, which can be used to access AWS resources. So the JavaScript in Julie's browser now has available some temporary AWS credentials that it can use to interact with AWS, and so it uses these temporary credentials to upload a video of Woofy to an S3 bucket—this is the original bucket of our application, the bucket where the master videos go that our customers upload.

Notice that so far in this process, no self-managed compute or servers have been used to provision this service—we've performed all of these activities without using any compute servers or compute instances that we need to manage or design as solutions architects, since it's all delivered by using managed services such as S3, Cognito, and the Google identity provider.

Now, when the Woofy video arrives inside the originals bucket, that bucket is configured to generate an event which contains the details of the object that was uploaded, and it's set to send that event to and invoke a Lambda function to process that video. That Lambda function takes in the event and creates jobs within the Elastic Transcoder service, which is a managed service offered by AWS that can take in media and manipulate that media—one of the things it can do is transcode the media, generating media of different sizes from one master video file.

Multiple jobs get created, one for each size of video that's required, and the Elastic Transcoder gets the location of the original video as part of the initiation of the job and loads in that video at the start of each job processing cycle, so each job outputs an object to a transcoder bucket—one object for each different size of the original video—and in addition, details on each of the new videos are added to a database, in this case DynamoDB.

Again at this stage, notice that we still have no self-managed servers—the only resources that are consumed are storage space in S3 and DynamoDB, and any processing time used for the Lambda function and Elastic Transcoder jobs. With this architecture so far, we've allowed a customer to upload a master video, transcoded it into different video sizes, and at no point have we consumed any self-managed compute, EC2 instances, or any other long-running compute services—it’s all managed services or compute that’s used in Julie’s browser.

Now the last part of the architecture is where Julie, by clicking another part of the client site that's running inside her browser, can interact with another Lambda function—we’ll call this My Media—and this Lambda function will load data from the database, identify which objects in the transcode bucket are Julie’s, and return URLs for Julie to access, and this is how Julie can load up a web page which shows all of the videos that she’s uploaded to the PetTube application.

Now this is a simplified diagram—in reality, it’s a little bit more complex—for example, API Gateway would generally be used between any client-side processing and the Lambda functions, but conceptually this is actually how it works. We’ve got no self-managed servers, no self-managed database servers, and little, if any, costs that are incurred for base usage—it’s a fully consumption-based model that consumes compute only when it’s being used, when events are generated either from a system-side or a client-side, and it uses third-party services as much as possible.

Now there are many third-party services to choose from, and you can never expect to know them all end-to-end, but the key thing to understand about serverless is the way to do things, and I’ve covered that in this lesson. Later in the section, you’ll experience how to implement a serverless application within the demo lesson called PetCuddleatron, and this will show you how to implement a serverless application just like the one that’s on screen—it’s slightly less complex, but it’s one that uses many of the same architectural fundamentals, and it should start to really cement the theory that you’re learning right now.

Now before we move on to this demo, there are a few more services that I need to cover which the PetCuddleatron demo lesson will utilize. So for now, that’s it for this lesson—thanks for watching, go ahead and complete this video, and then when you’re ready, I’ll look forward to you joining me in the next.

Welcome back. In this lesson, I want to cover CloudWatch events. We've covered CloudWatch earlier in the course, which focused on metrics and monitoring, and we've also covered CloudWatch logs, which focused on the ingestion and management of logging data.

CloudWatch events delivers a near real-time stream of system events, and these events describe changes in AWS products and services. When an instance is terminated, started or stopped, these generate an event, and when any AWS products and services which are supported by CloudWatch events perform actions, they generate events that the product has visibility of.

Events Bridge is the service which is replacing CloudWatch events, and it can perform all of the same bits of functionality that CloudWatch events can produce, as it's got a superset of its functionality. In addition, Events Bridge can also handle events from third parties as well as custom applications.

They do both share the same basic underlying architecture, but AWS are now starting to encourage a migration from CloudWatch events over to Events Bridge. We've got a lot of architecture to cover, so let's jump in and get started.

Both Events Bridge and CloudWatch events perform at a high level the same basic task; they allow you to implement an architecture which can observe if X happens or if something happens at a certain time, so Y, then do Z. X is a supported service which generates an event, so it's a producer of an event, and Y can be a certain time or time period, and this is specified using the Unix Cron format, which is a flexible format letting you specify one or more times when something should occur, and Z is a supported target service to deliver the event to.

Events Bridge is basically CloudWatch events version two; it uses the same underlying APIs, and it has the same basic architecture, but AWS recommend that for any new deployments, you should use Events Bridge because it has a superset of the features offered by CloudWatch events. Things created in one are visible in the other for now, but this could change in the future, so as a general best practice, you should start using Events Bridge by default for any of the functions that you can use CloudWatch events for.

Now, both of these services actually operate using a default entity, which is known as an event bus, and both of them actually have a default event bus for a single AWS account. A bus in this context is a stream of events which occur from any supported service inside that AWS account.

Now, in CloudWatch events, there is only one event bus available, so it's implicit; it's not really exposed to the UI, it just exists. You interact with it, but because there's only one of them, it's not actually exposed as a visible thing; you just look for events and then send these events to targets when you want something to occur. So in CloudWatch events, there is only one event bus, and it's not exposed inside the UI.

In Event Bridge, you can create additional buses, either for your applications or third-party products and services, and you can interact with these buses in the same way as the account default event bus.

Now, with CloudWatch events and Event Bridge, you create rules, and these rules pattern match events which occur on the buses, and when they see an event which matches, they deliver that event to a target. Alternatively, you also have schedule-based rules which are essentially pattern-matching rules but which match a certain date and time or ranges of dates and times, so if you're familiar with the Unix Cron system, this is similar.

For a schedule rule, you define a Cron expression, and the rule executes whenever this matches and delivers this to a particular target. So the rule matches an event, and it routes that event to one or more targets which you define on that rule, and an example of one target is to invoke a specific Lambda function.

Now, architecturally, at the heart of Event Bridge is the default account event bus, which is a stream of events which are generated by supported services within the AWS account. Now, EC2 is an example of a supported service, and let's say in this case, we've got Bob changing the state of an EC2 instance, and he's changing the state from stopped to running.

When the instance changes state, an event gets generated which runs through the event bus. Event Bridge, which sits over the top of any event buses that it has exposure to, monitors all of the events which pass through this event bus.

Now, within Event Bridge or CloudWatch events, which I'm going to start calling just Event Bridge from now on because it makes it easier, but within Event Bridge, we have rules. Now, rules are created, and these are linked to a specific event bus, and the default is the account default event bus.

The two types of rules are pattern matching rules, and these match particular patterns of the events themselves as they pass through the event bus. We've also got scheduled rules which match particular cron-formatted times or ranges of times, and when this cron-formatted expression matches a particular time, the rule is executed, and in both of these cases, when a rule is executed, the rule delivers the particular event that it's matched through to one or more targets.

And of course, as I just mentioned, examples of these targets could be to invoke a lambda function. Now, events themselves are just JSON structures, and the data in the event structure can be used by the targets.

So in the example of a state change of an EC2 instance, the lambda function will receive the event JSON data, which includes which instance has changed state, what state it's changed into, as well as other things like the date and time when the change occurred.

So that's a theory of both CloudWatch events and the event bridge, and both of these products are used as a central point for managing events generated inside an AWS account and controlling what to do with those events.

So at this point, that is everything that I wanted to cover. Go ahead and complete this lesson, and then when you're ready, I look forward to you joining me in the next.

Welcome back and in part three of this series, I want to finish off and talk about some advanced elements of Lambda. Now we've got a lot to cover, so let's jump in and get started.

First, I want to talk about the ways a Lambda function can be invoked. We've got three different methods for invoking a Lambda function: we've got synchronous invocation, asynchronous invocation, and invocation using event source mappings. And I want to step through each of them visually so that you can understand in detail how they work because this is essential for the exam.

So let's start off with synchronous invocation of Lambda. With this model, you might start off with a command line or API directly invoking a Lambda function; the Lambda function is provided with some data and it executes that data. Now all this time, the command line or API is waiting for a response because it's synchronous — it needs to wait here until the Lambda function completes its execution. So the Lambda function finishes and it returns that data, whether it's a success or a failure.

Now synchronous invocation also happens if Lambda is used indirectly via the API gateway, which is the use case for many serverless architectures. So we might have some clients using a web application via API gateway and this proxies through to one or more Lambda functions; again, the Lambda function performs some processing all the while the client is waiting for a response within their web application. And then when the Lambda function responds, this goes back via the API gateway and back through to the client.

The common factors with both of these approaches is that the client sends a request which invokes Lambda and the result, be it a success or failure, is returned during that initial request — the client is waiting for any data to be returned. Another implication of a synchronous invocation is that any errors or retries have to be handled within the client. The Lambda function runs once, it returns something, and then it stops; if there's a problem or data isn't processed correctly, then the client needs to rerun that request — and this happens at the client side.

So synchronous invocation is generally used when it's a human directly or indirectly invoking a Lambda function. Next, let's look at asynchronous invocation, and this is typically used when AWS services invoke Lambda functions on your behalf. Let's use an example: an S3 bucket with S3 events enabled — so we upload a new image of whiskers to this S3 bucket, which causes an event to be generated and sent through to Lambda, and this is an asynchronous invocation.

So S3 isn't waiting around for any kind of response — it basically just forgets about it at this point. Once it sent that event through to Lambda, it doesn't continue waiting; it doesn't worry about this event at all. Now maybe as part of processing this image, it's generating a thumbnail or maybe performing some kind of analysis and storing that data into DynamoDB, but again, S3 isn't waiting around for any of this — it's asynchronous. Lambda is responsible for any reprocessing in the event that there's a failure, and this reprocessing value is configurable between zero and two times.

Now a key requirement for this is that the function code needs to be idempotent — and this is important. If you've never heard this term before, let me explain. Let's say that you had $10 in your bank account and I wanted to increase this value to $20. Now there are two ways that I could do this if I operated the bank: I could simply add $10 to your balance, increasing it from 10 to 20, or I could explicitly set the balance to 20.

Now if I set the balance to 20 and this operation failed at some undetermined point in this process, then I could simply rerun the process, safe in the knowledge that even running it again on your balance would only at worst set the value to $20 again — this is known as an idempotent operation. You can run it as many times as you want and the outcome will be the same.

Now if I performed the operation where I added $10 to your account and the operation failed, it could have failed before it added the $10 or after; if it failed after and I rerun the operation, well now you'd have $30 — and this is an example of something which is not idempotent.

When Lambda retries an operation it doesn't really provide any other information — the function just reruns. So logically in this example you would need to make sure that your function code isn't additive or subtractive — it just needs to perform its intended task; with this example it needs to set your balance to $20.

Generally when designing a Lambda function which is used in this way, the Lambda function needs to finish with a desired state — it needs to make something true. If you're using Lambda functions which are designed in a non-idempotent way, you can end up with some questionable results.

Now Lambda can be configured to send any events which it can't process after those automatic retries to a dead letter queue, which can be used for diagnostic processing. And a new feature of Lambda is the ability to create destinations — so events processed by Lambda functions can be delivered to another destination such as SQS, SNS, another Lambda function, and even EventBridge; and separate destinations can be configured based on successful processing or failures.

So this is asynchronous invocation — it's generally used by AWS services which are capable of generating events and sending those events to Lambda. It means that Lambda can automatically reprocess failed events and the original source of the event isn't waiting for processing to complete.

But there is a third type of invocation. The last type of invocation is known as Event Source Mapping, and this is typically used on streams or queues which don't generate events — so things where some kind of polling is required. Let's look at an example: let's say that we have a Kinesis data stream, and into this stream, a fleet of producer vans driving around scanning with LIDAR and imaging equipment are all producing data which is being put into a Kinesis stream.

Now Kinesis is a stream based product — generally consumers can read from a stream but it doesn't generate events when data is added, so historically this wouldn't have been an ideal fit for Lambda which is an event driven service. So what happens is that we have a hidden component called an event source mapping which is polling queues or streams looking for new data and getting back source batches — so batches of source data from this data source.

Now these source batches are then broken up as required based on a batch size and sent into a Lambda function as event batches. Now a single Lambda function invocation could in theory receive hundreds of events in a batch — it depends on how long each event takes to process. Remember Lambda has a 15 minute timeout so you need to carefully control this event batch size to ensure that the Lambda function doesn't terminate before completing this batch.

Now there's one really important thing that you need to understand about event source mapping. With a synchronous invocation an event is delivered to Lambda from the source and Lambda doesn't need permissions to the source service unless it actually wants to read more data from that source — for example, if an object is added to an S3 bucket, then S3 generates and delivers an event which contains details of that event (so which object was uploaded and perhaps some other metadata).

But unless you need to read additional data from S3 maybe to get the actual object, well then the Lambda function doesn't need S3 permissions. With event source mapping invocation, the source service isn't delivering an event — the event source mapping is reading from that source. And so the event source mapping uses permissions from the Lambda execution role to access the source service.

And this is really important to know because it does come up in the exam. So even if a Lambda function receives an event batch containing Kinesis data, even though the Lambda function doesn't directly read from Kinesis, the execution role needs Kinesis permissions because the event source mapping uses them on its behalf to retrieve that data.

Now any batches which consistently fail can be sent to an SQS queue or an SNS topic for further processing or analysis. Now that's the third type of invocation — this is event source mapping invocation, and that's the method used when Lambda functions are processing SQS queues, Kinesis streams, DynamoDB streams and even Amazon managed streaming for Apache Kafka. And this last one is something that we won't be covering within the course, but it's important to know all of the different types of products that use event source mapping based invocation.

With that being said that's all of the three types of invocation I wanted to cover — so let's move on to a different topic, this time Lambda versions. With Lambda functions it's possible to define specific versions of Lambda functions — so you could have different versions of the given function, for example, version one, version two and version three.

Now as it relates to Lambda, a version of a function is actually the code plus the configuration of that Lambda function — so the resources and any environment variables in addition to any other configuration information. Now when you publish a version, that version is immutable — it never changes once it's published, and it even has its own Amazon resource name. So once you publish a version you can no longer change that version.

There's also the concept of dollar latest, and dollar latest points at the latest version of a Lambda function — now this can obviously change as you publish later and later versions of the function, so this is not immutable. You can also create aliases — so for example, dev, stage and prod, and these can point at a particular version of a Lambda function, and these can be changed — so these aliases are not immutable.

So generally with large scale deployments of Lambda you'd be producing Lambda function versions for all of the major changes, and using aliases so that different components of your serverless application can point at those specific immutable version numbers — so that's important to know for the exam.

So the last thing I want to talk about is Lambda startup times, and to understand that you need to understand how Lambda functions are actually executed. Lambda code runs inside a runtime environment — and this is also referred to as an execution context; think of this as a small container which is allocated an amount of resource which runs your Lambda code.

When a Lambda function is first invoked — let's say by receiving an S3 event — this execution context needs to be created and configured, and this takes time. First the environment itself is created and this requires physical hardware; then any runtimes which are required are downloaded and installed — let's say this is for Python 3.8; then the deployment package is downloaded and then installed — and this takes time.

Now this process is known as a cold start, and all in, this process can take hundreds of milliseconds or more — which can be significant if a Lambda function is performing a task which touches a human who is expecting a response. Now if this is an S3 event, then maybe this extra time isn't such a big deal — but you need to be aware that this cold start occurs because an execution context is being created and configured, any prerequisites are being downloaded and installed, the deployment package is being downloaded and installed — and that's all before the function itself can execute.

Now if the same Lambda function is invoked again without too much of a gap, then it's possible that Lambda will use the same execution context — and this is known as a warm start. It doesn't need to set up the environment or download the deployment package because all of that is already contained within the execution context; this time the context just receives the event and immediately begins processing.

A warm start means the code can be running within milliseconds because there's no lengthy build process. A Lambda function which invokes again fairly soon after a cold start can reuse an execution context — but if too long a time period goes between invocations, then the context can be deleted which results in another cold start.

Also one function invocation runs at a time per context — so if you need 20 invocations of a function at once, then this can result in 20 cold starts. Now you can make this process more efficient — you can actually use a feature known as provisioned concurrency where you can inform AWS in advance. An execution context can be provisioned for you in advance for Lambda invocations.

You might use these when you know that you have periods of high load on a serverless application or if you're preparing for a new production release of a serverless application and want to pre-create all of these execution environments. Now there are also other things that you can do to improve performance — you can use the temp space to pre-download things within an execution context.

For example, maybe you're using some animal images as part of your processing — well, if another function uses the same execution context, then it too will have access to those same animal images without having to download them a second time. Now you do need to be careful because your functions need to be able to cope with the environment being new and clean every time — they can never assume the presence of anything.

From a code perspective, you can create other things like database connections outside of the Lambda function handler code. So when you create a Lambda function, generally most things go within the Lambda function handler — but if you create anything outside of the Lambda function handler, then these will be made available for any future function invocations in the same context.

So anything that you define within a Lambda function handler is limited to that one specific invocation of that Lambda function, but for anything which you anticipate there being a potential for reuse, you can declare that outside of the Lambda function handler — and in theory, that will be available for any other invocations of the Lambda function which occur within that same execution context.

But again, you need to make sure that your function doesn't require or expect that — every single time a function invokes, it should be absolutely fine with recreating everything. You should by default assume that execution contexts are stateless and any invocation of a Lambda function is going to be operating in a completely freshly created environment, but if you want to be efficient, your functions should also be able to reuse common aspects that persist through different function invocations.

Now again, these are all deep dive things that you need to be aware of for the exam. I've covered a lot of these elements across all three parts of this Lambda deep dive mini series, but at this point, that's everything I wanted to cover in part three — and this is the last part of this mini series. So thanks for watching. Go ahead and complete this video, and when you're ready, I look forward to you joining me in the next lesson.

Welcome back to part two of this lesson series going into a little bit more depth on Lambda. In this part of the series I'm going to be talking about Lambda networking, Lambda permissions and Lambda monitoring. Now this is a lot to cover in one lesson so let's jump in and get started.

Lambda has two networking modes and you need to be aware of both of them for the exam. First we have public which is the default and then second we have VPC networking. Now you need to understand the architecture of both of them so let's step through them in a little bit more detail.

For public networking we start with an AWS environment and inside it a single Lambda function. Now this is part of a wider application, let's say the Categorum Enterprise application running in a VPC, which uses Aurora for the database, EC2 for compute, and the Elastic file system for shared file storage. Now this is the default configuration for Lambda where it's running in the public AWS network, so Lambda using this configuration can access public space AWS services such as SQS and DynamoDB or internet-based services such as IMDB if the Lambda function wanted to fetch the latest details of cat-themed movies and TV shows.

So Lambda running by default using public networking means that it has network connectivity to public space AWS services and the public internet; it can connect to both of those from a networking perspective, and as long as it has the required methods of authentication and authorization then it can access all of those services. Now public networking offers the best performance for Lambda because no customer-specific networking is required—Lambda functions can run on shared hardware and networking with nothing specific to one particular customer—but this does mean that any Lambda functions running with this default have no access to services running within a VPC unless those services are configured with public addressing as well as security rules to allow external access, so this is a big limitation that you need to understand for the exam.

So the architecture on screen now—this Lambda function could not access Aurora, EC2, or the Elastic File system unless they had public addressing and the security was configured to allow that access, so in this example without configuration changes the Lambda function could access public services but would have no access to anything running inside the VPC. Now in most cases in my experience Lambda is used with this public networking model, but there are situations where this isn't enough and for those situations Lambda can be configured to run inside a VPC.

Let's look at how. This time we have the same architecture—so a VPC running within AWS—but this time the Lambda function is configured to run inside a private subnet at the bottom. Now this is the same subnet where the Catergram Enterprise infrastructure is running from, and for the exam specifically the key thing to understand about Lambdas running inside a VPC is that they obey all of the same rules as anything else running in a VPC because they're actually running within that VPC.

So to start with, this means that Lambda functions running inside a VPC can freely access other VPC-based resources assuming any network ACLs and security groups allow that access, but the flip side of this means they can't access things outside of the VPC unless networking configuration exists within the VPC to allow this external access. So by default with this architecture the Lambda function couldn't access DynamoDB or any internet-based endpoints such as with this example IMDB.

Now if you face any exam questions or you need to design any solutions which involve Lambda functions running within a VPC, then just treat them like anything else running in that VPC. So this means that you could use a VPC endpoint, for example a gateway endpoint, to provide access to DynamoDB; because the Lambda function is running within the VPC it could utilize a gateway endpoint to access DynamoDB, or in the case that the Lambda function needed access to AWS public services or the internet, you could deploy a NAT gateway in a public subnet and then attach an internet gateway to the VPC.

Remember Lambda running within a VPC behaves like any other VPC-based service—the same gateways and configurations are needed to allow VPC-based Lambda functions to communicate with the AWS public zone and the public internet. Now you also need to give your Lambda functions EC2 network permissions via the execution role, which I'll cover very soon because the Lambda service needs to create network interfaces within your VPC, it requires these permissions, and this architecture of using network interfaces within a VPC is what I want to quickly cover now.

Now there used to be disadvantages to running Lambda in a VPC—significant disadvantages—and the reason was the networking architecture that Lambda used. VPC-based Lambda functions don't actually run within your VPC; the way they work is similar to Fargate, so we have AWS and there's a Lambda service VPC and a customer VPC.

Now let's keep things simple and say that we only have three Lambda functions. Now the way that this historically worked is that each of these Lambda functions when invoked would create an elastic network interface within the customer VPC and traffic would flow between this service VPC and the customer VPC. Now the problem is that configuring these elastic network interfaces on a per-function, per-invocation basis would take time and add delay to the execution of the Lambda function code.

In addition, this architecture doesn't scale well because parallel function executions or concurrency required additional elastic network interfaces, and the more popular a system became the worse the problem became—with larger systems you had more and more performance issues and more and more issues with keeping VPC capacity available for larger and larger numbers of ENIs.

Now luckily this is the old architecture—this is the way that Lambda used to handle this private networking—it's not how it works anymore. With the new way, instead of requiring an elastic network interface per function execution, AWS analyzes all of the functions running in a region in an account and builds up a set of unique combinations of security groups and subnets.

So for every unique one of those, one ENI is required in the VPC. So if all your functions used a collection of subnets but the same security groups, then one network interface would be required per subnet; if they all used the same subnet and all used the same security group, then all of your Lambda functions could use the single elastic network interface. So a single connection between the Lambda Service VPC and your VPC is created for every unique combination of security groups and subnets used by your Lambda functions.

Now the network interfaces using this architecture are created when you configure the Lambda function, and typically this might take 90 seconds, but this is done once—so when you create the function or when you update the network and configuration, this network and configuration is created or updated—and that means that it isn't required every single time a Lambda function is invoked, so it doesn't delay your function invocations.

Now this means that you can use private networking at scale without increasing the number of elastic network interfaces required, so where it used to be a bad idea performance-wise to use VPC-based Lambdas, this is no longer the case.

So that's networking—so this is how you configure Lambda functions if you need them to have access to private VPC services—and it's important that you understand both the public and VPC networking model especially for the exam, because you will face questions on the exam about executing Lambda functions within a VPC.

Again one really important hint that I will provide is just treat Lambda functions running in a VPC like any other VPC-based resource, and by now you should know how to architect a VPC so that services running in that VPC have access to everything that they need, so just treat Lambda functions in the same way.

Now let's look at the security of Lambda functions. When it comes to Lambda permissions, there are actually two key parts of the permissions model that you need to understand—one of them is pretty well known and that's covered at the associate level, the other not so much.

Now let's start with a typical Lambda environment—this is a runtime environment, the thing where your Lambda functions execute within—so this is running a runtime, in this case Python 3.8, it's allocated some resources and the code loads and runs within this environment.

Now for this environment to access any AWS products and services it needs to be provided with an execution role—this is a role which is assumed by Lambda and by doing so the code within the environment gains the permissions of that role based on the role's permissions policy—so a role is created which has a trust policy which trusts Lambda, and the permissions policy that that role has is used to generate the temporary credentials that the Lambda function uses to interact with other resources.

So in many ways this is just the same as an EC2 instance role—so this governs what permissions the function receives, which might be something like loading data from DynamoDB and storing output data into S3.

Now this is the most well-known aspect of Lambda permissions, but there is another part—Lambda actually has resource policies. Now this in many ways is like a bucket policy on S3; it controls who can interact with a specific Lambda function.

It's this resource policy which can be used to allow external accounts to invoke a Lambda function or certain services to use a Lambda function such as SNS or S3. The resource policy is something changed when you integrate other services with Lambda, and you can manually change it via the CLI or the API; unless something's changed between creating this lesson and when you're watching it, it currently can't be changed using the console UI, so this is only something which can be manipulated using the CLI or the API.

So that's how security works within a Lambda function. Now one more thing that I want to cover before finishing up with part two is logging.

So Lambda uses CloudWatch, CloudWatch Logs, and X-Ray for various aspects of its logging and monitoring—so any logging information generated from Lambda executions, that goes into CloudWatch Logs, so the output of Lambda functions, any messages that you output to the log, any errors, details on the duration of the execution—that's all stored into CloudWatch Logs.

Any metrics—so details such as invocation successes or failure numbers, any retries, anything to do with latency—that's all stored in CloudWatch, so CloudWatch is the thing that stores metrics, and this is important to understand: logging goes into CloudWatch Logs, and any details on the number of invocations, successes or failures, anything around metrics goes straight into CloudWatch.

Now Lambdas can also be integrated into X-Ray, which I cover elsewhere in the course, and this can be used to add distributed tracing capability—so if you need to trace the path of a user or the path of a session through a serverless application which uses Lambda, then you can use the X-Ray service.

Now I don't expect this to feature heavily on the exam but just remember the terms X-Ray and distributed tracing because that might come in handy for one or two exam questions if these topics do crop up.

Now one really important thing to remember for the exam is that for Lambda to be able to log into CloudWatch Logs to generate the output of any of the executions, you need to give Lambda permissions via the execution role—so there's actually a pre-built policy and role within AWS specifically designed to give Lambda functions the basic permissions that they require to log information into CloudWatch Logs.

And one really common exam scenario is where you're trying to diagnose why a Lambda function is not working—there's nothing in CloudWatch Logs—and one possible answer is that it doesn't have the required permissions via the execution role.

Now that's everything I wanted to cover in part two of this Lambda in-depth mini series—so we've covered networking, both public and private, we've covered security, and we've covered logging—so go ahead and complete this lesson and when you're ready I look forward to you joining me in part three.

Welcome back and in this multi-part lesson mini-series, I want to talk about AWS Lambda. Lambda is a function as a service or a fast product. This means that you provide specialized short running and focused code to Lambda and it takes care of running it and billing you only for what you consume. So a Lambda function is a piece of code which Lambda runs and every Lambda function is using a supported runtime. So an example of a supported runtime is Python 3.8. So when you create a Lambda function, you need to define which runtime that piece of code uses. Now, when you provide your code to Lambda, it's loaded into and executed within a runtime environment. And this runtime environment is specifically created to run code using a certain runtime, a certain language. So when you create a Lambda function that uses the Python 3.8 runtime, then the runtime environment that's created is itself specifically designed to run Python 3.8 code.

Now, when you create a Lambda function, you also define the amount of resource that a runtime environment is provided with. So you directly allocate a certain amount of memory and based on that amount of memory, a certain amount of virtual CPU is allocated, but this is indirect. You don't get to choose the amount of CPU. This is based on the amount of memory. Now, the key thing to understand about Lambda as a service, because it's a function as a service product, because it's designed for short running and focused functions, you only actually build for the duration that a function runs. So based on the amount of resource allocated to an environment and based on the duration that that function runs for per invocation, that determines how much you'll build for the Lambda product. So you'll build for the duration of function executions.

Now, Lambda is a key part of serverless architectures running within AWS. And over this section of the course, you're going to get some experience of how you can use Lambda to create serverless or event-driven architectures. Architecturally, the way that Lambda works is this. You define a Lambda function. Now, you can think of a Lambda function as a unit of configuration. Yes, you can also use the term Lambda function to describe the actual code. But when you think of a Lambda function, think of it as the code plus all the associated wrappings and configuration. Your Lambda function at its most basic is a deployment package which Lambda executes. So when you create a Lambda function, you define the language which the function is written in. You provide Lambda with a deployment package and you set some resources. And whenever the Lambda function is invoked, what actually happens is the deployment package is downloaded and executed within this runtime environment.

Now, Lambda supports lots of different runtimes. Some of the common ones are various different versions of Python. We also have Ruby. We've got Java. We've also got Go and there's also C# as well as various versions of Node.js. Now, you can also create custom ones using Lambda layers. And many of these are created by the community. For the exam though, one really important point is that if you see or hear the term Docker, consider this to mean not Lambda. So Docker is an anti-pattern for Lambda. Now, Lambda does now support using Docker images, but this is distinct from the word Docker. If you hear the term Docker in the exam, then it generally will be referring to traditional containerized computing. So that's using a specific Docker image to spin up a container and use it in a containerized compute environment such as ECS.

Now, you can also use container images with Lambda. Now, that's a different process. That means that you're using your existing container build processes, the same ones that you use to create Docker images. But instead, you're creating specific images designed to run inside the Lambda environment. So don't confuse Docker container images and Docker with images used for Lambda. They're two different things. The only thing that they share is that you can use your existing build processes to build Lambda images. Now, custom runtimes could allow languages such as Rust, which is a very popular community-based language to work within the product. So if you search using Google or any other popular search engine, you'll be able to find lots of languages which have been added by the community using the Lambda layer functionality. And I'll be talking about that elsewhere in the course.

Now, you select the runtime to use when creating the function, and this determines the components which are available inside the runtime environment. So Python code, for instance, requires Python of a certain version to be installed in addition to various Python modules. Conceptually, think about it like this. Every time a Lambda function is invoked, which means to execute that function, a new runtime environment is created with all of the components that that Lambda function needs. Let's say, for example, a Python 3.8-based Lambda function. So the code loads, it's executed, and then it terminates. Next time, a new clean environment is created, it does the same thing, and then it terminates. Lambda functions are stateless, which means no data is left over from a previous invocation. Every time a function is invoked, it's a brand new invocation, a brand new environment. Now, I'm going to be talking about this in part 3 of this series, because this isn't always the case, but you have to assume that it is architecturally. So your code running within Lambda needs to be able to work 100% of the time if it's a new environment. Lambda runtime environments have no state. Now, there are some situations where a function might be invoked multiple times within the same environment. And I'll be talking about that in part 3 of this series. But as a base level, a default, assume that every time a Lambda function is invoked, it's inside a brand new runtime environment.

Now, you also define the resources that Lambda functions use, and this determines how much resource the runtime environment gets. Now, you directly define the memory. And this is anywhere from 128 MB to 10,240 MB in one MB steps. Now, you don't directly control the amount of virtual CPU. This scales with the memory. So 1769 MB of memory gives you one VCPU of allocation, and it's linear. So the less memory means less virtual CPUs, and more memory means additional VCPU capacity. The runtime environment also has some disk space allocation. 512 MB is mounted as forward slash TMP within the runtime environment. This is the default amount, but it can scale to 10,240 MB. Now, you can use this, but keep in mind, you have to assume that it's blank every single time a Lambda function is invoked. This should only be viewed as temporary space.

Lambda functions can run for up to 900 seconds or 15 minutes. And this is known as the function timeout. This is important because for anything beyond 15 minutes, you can't use Lambda directly. And that's a really important figure to know for the exam. You know by now I'm not a fan of people memorizing facts and figures, but this is definitely one that you need to remember for the exam. So 15 minutes is a critical amount of time for a Lambda function. You can use other things, such as step functions, to create longer running workflows, but one invocation of one function has a maximum of 15 minutes or 900 seconds.

Now, we're going to be covering security in more detail in part two, as well as networking. But the security for a Lambda function is controlled using execution roles. And these are IAM roles, assumed by the Lambda function, which provides permissions to interact with other AWS products and services. So any permissions which a Lambda function needs to be provided with are delivered by creating an execution role and attaching that to a specific Lambda function.

Now, just a few final things before we finish up some common uses of Lambda. So Lambda forms a core part of the delivery of serverless applications within AWS. And generally this uses products such as S3, API gateway, and Lambda. So these three together are often used to deliver serverless applications. Lambda can also be used for file processing, using S3, S3 events, and Lambda. So a very common example that's used in training is watermarking images. So have images uploaded to S3, generate an S3 event, invoke a Lambda function, which applies a watermark, and then terminates. And you're only billed for the compute resources used during those Lambda function invocations. You can also use Lambda for database triggers. So this is using DynamoDB, as well as DynamoDB streams, and then Lambda. So Lambda can be invoked any time data is inserted, modified, or deleted from a DynamoDB table with streams enabled. And this is another powerful architecture.

You can also use Lambda to implement a form of serverless cron. So you can use EventBridge or CloudWatch events to invoke Lambda functions at certain times of day, or certain days of week, to perform certain scripted activities. And this is something that traditionally you would need to run on something like an EC2 instance, but using Lambda means that you're only billed for the amount of time that these functions are executing. So this is another really common use case. And then finally, you can perform real-time stream data processing. So Lambda's can be configured to invoke whenever data is added to a Kinesis stream. And this can be useful because Lambda is really scalable. And so it can scale with the amount of data being streamed into a Kinesis stream. And again, this is another really common architecture for any businesses that are streaming large quantities of data into AWS, and they require some form of real-time processing.

Now that's everything that I wanted to cover in part one of this series. Remember, it's a three-part mini-series, part two and part three, are going to introduce some more advanced concepts. Specifically, though, is that you'll need for the exam. But at this point, go ahead, complete this lesson, and then when you're ready, I'll look forward to you joining me in the next.

Welcome back. This is part two of this lesson, and we’re going to continue immediately from the end of part one. So let's get started.

Now, the previous architecture can be evolved by using queues. A queue is a system that accepts messages. Messages are sent onto a queue and can be received or polled off the queue. In many queues, there's ordering, meaning that in most cases, messages are received off the queue in a first-in, first-out (FIFO) architecture, though it's worth noting that this isn't always the case.

Using a queue-based decoupled architecture, CatTube would look something like this: Bob would upload his newest video of whiskers laying on the beach to the upload component. Once the upload is complete, instead of passing this directly onto the processing tier, it does something slightly different. It stores the master 4K video inside an S3 bucket and adds a message to the queue detailing where the video is located, as well as any other relevant information, such as what sizes are required. This message, because it’s the first message in the queue, is architecturally at the front of the queue. At this point, the upload tier, having uploaded the master video to S3 and added a message to the queue, finishes this particular transaction. It doesn’t talk directly to the processing tier and doesn't know or care if it’s actually functioning. The key thing is that the upload tier doesn't expect an immediate answer from the processing tier. The queue has decoupled the upload and processing components.

It's moved from a synchronous style of communication where the upload tier expects and needs an immediate answer and waits for that answer, to asynchronous communications. Here, the upload tier sends the message and can either wait in the background or just continue doing other things while the processing tier does its job. While this process is going on, the upload component is probably getting additional videos being uploaded, and they’re added to the queue along with the whiskers video processing job. Other messages that are added to the queue are behind the whiskers job because there is an order in this queue: it is a FIFO queue.

At the other side of the queue, we have an auto-scaling group, which has been configured with a minimum size of 0, a desired size of 0, and a maximum size of 1,337. Currently, it has no instances provisioned, but it has auto-scaling policies that provision or terminate instances based on what's called the queue length, which is the number of items in the queue. Because there are messages on the queue added by the upload tier, the auto-scaling group detects this and increases the desired capacity from 0 to 2. As a result, instances are provisioned by the auto-scaling group. These instances start polling the queue and receive messages that are at the front of the queue. These messages contain the data for the job and the location of the S3 bucket and the object in that bucket. Once these jobs are received from the queue by these processing instances, they can retrieve the master video from the S3 bucket.

The jobs are processed by the instances, and once they are completed, the messages are deleted from the queue, leaving only one job in the queue. At this point, the auto-scaling group may decide to scale back because of the shorter queue length, so it reduces the desired capacity from 2 to 1, which terminates one of the processing instances. The instance that remains polls the queue and receives the last message. It completes the processing of that message, performs the transcoding on the videos, and leaves zero messages in the queue. The auto-scaling group realizes this and scales back the desired capacity from 1 to 0, resulting in the termination of the last processing EC2 instance.

Using a queue architecture to place a queue between two application tiers decouples those tiers. One tier adds jobs to the queue and doesn’t care about the health or the state of the other tier. The other tier can read jobs from the queue, and it doesn't care how they got there. This is unlike the previous example where application load balancers were used between tiers. While this did allow for high availability and scaling, the upload tier in the previous example still synchronously communicated with one instance of the processing tier. With the queue architecture, no communication happens directly between the components. The components are decoupled and can scale independently and freely. In this case, the processing tier uses a worker fleet architecture that can scale anywhere from zero to a near-infinite number of instances based on the length of the queue.

This is a really powerful architecture because of the asynchronous communications it uses. It's an architecture commonly used in applications like CatTube, where customers upload things for processing, and you want to ensure that a worker fleet behind the scenes can scale to perform that processing. You might be asking why this matters in the context of event-driven architectures, and I’m getting there, I promise.

If you continue breaking down a monolithic application into smaller and smaller pieces, you'll eventually end up with a microservice architecture, which is a collection of, as the name suggests, microservices. Microservices do individual things very well. In this example, we have the upload microservice, the processing microservice, and the store and manage microservice. A full application like CatTube might have hundreds or even thousands of these microservices. They might be different services, or there might just be many copies of the same service, like in this example, which is fortunate because it's much easier to diagram. The upload service is a producer, the processing node is a consumer, and the data store and manage microservice performs both roles.

Logically, producers produce data or messages, and consumers, as the name suggests, consume data or messages. There are also microservices that can do both things. The things that services produce and consume architecturally are events. Queues can be used to communicate events, as we saw with the previous example, but larger microservices architectures can get complex quickly. Services need to exchange data between partner microservices, and if we do this with a queue architecture, we'll logically have many queues. While this works, it can be complicated. Keep in mind that a microservice is just a tiny self-sufficient application. It has its own logic, its own store of data, and its own input/output components.

Now, if you hear the term "event-driven architecture," I don’t want you to be too apprehensive. Event-driven architectures are simply a collection of event producers, which might be components of your application that directly interact with customers, parts of your infrastructure like EC2, or systems monitoring components. These are bits of software that generate or produce events in reaction to something. If a customer clicks submit, that might be an event. If an error occurs during the upload of the whiskers holiday video, that's an event. Producers are things that produce events, and the inverse of this is consumers—pieces of software that are ready and waiting for events to occur. When they see an event they care about, they take action. This might involve displaying something for a customer, dispatching a human to resolve an order packing issue, or retrying an upload.

Components or services within an application can be both producers and consumers. Sometimes a component might generate an event, for example, a failed upload, and then consume events to force a retry of that upload. The key thing to understand about event-driven architectures is that neither the producers nor the consumers are sitting around waiting for things to occur. They're not constantly consuming resources or running at 100% CPU load, waiting for things to happen. Producers generate events when something occurs, such as when a button is clicked, an upload works, or when it doesn’t work. These producers produce events, but consumers aren’t waiting around for those events. They have those events delivered, and when they receive an event, they take an action, then stop. They're not constantly consuming resources.

Applications would be really complex if every software component or service needed to be aware of every other component. If every application component required a queue between it and every other component to put events into and access them from, the architecture would be really complicated. Best practice event-driven architectures have what's called an event router, a highly available central exchange point for events. The event router has an event bus, which you can think of as a constant flow of information. When events are generated by producers, they're added to this event bus, and the router can deliver them to event consumers.

The WordPress system we’ve used so far has been running on an EC2 instance, which is essentially a consistent allocation of resources. Whether the WordPress system is under low load or large load, we’re still billed for that EC2 instance, consuming resources. Now, imagine a system with lots of small services all waiting for events. If events are received, the system springs into action, allocating resources and scaling components as needed. It deals with those events, then returns to a low or no resource usage state, which is the default. Event-driven architectures only consume resources when needed. There’s nothing constantly running or waiting for things to happen. We don’t constantly poll, hoping for something to happen. We have producers that generate events when something happens. For example, on Amazon.com, when you click "order," it generates an event, and actions are taken based on that event. But Amazon.com doesn’t constantly check your browser every second to see if you've clicked "submit."

So, in summary, a mature event-driven architecture only consumes resources while handling events. When events are not occurring, it doesn’t consume resources. This is one of the key components of a serverless architecture, which I’ll talk about more later in this section.

I know this has been a lot of theory, but I promise you, as you continue through the course, it will really make sense why I introduced this theory in detail at this point. It will help you with the exam, too. In the rest of this section, we’ll be covering more AWS-specific and practical topics, but they’ll all rely on your knowledge of this evolution of systems architecture.

Thanks for watching this video. You can go ahead and finish it off, and when you’re ready, I look forward to you joining me in the next lesson.

Welcome back, and in this first technical lesson of this section of the course, we'll be stepping through what an event-driven architecture is and comparing it to other architectures available within AWS. As a solutions architect, this matters because you're the one who needs to design a solution using a specific architecture around a given set of business requirements, so you need to have a good base level understanding of all of the different types of architectures available to you within AWS. You can't build something unless you fully understand the architectures, so let's jump in and get started because we've got a lot to cover.

Now, to help illustrate how an event-driven architecture works, let's consider an example. And the example that I want to use is a popular online video sharing platform that you've all probably heard of. Yes, that's right, it's CatTube. One of the popular ways that CatTube is used is for people to upload holiday videos of their cats. So Bob uploads a 4k quality video of whiskers on holiday to CatTube. Now at this point, CatTube begins some processing and it generates lots of different versions of that video at various different quality levels, for example, 1080p, 720p, and 480p. Now this is only part of the application, but it happens to be the most intensive in terms of resource usage. The website also needs to display videos, manage playlists and channels, and store and retrieve data to and from a database.

Now, there are a few ways that we could architect this solution. Historically, the most popular systems architecture was known as a monolithic architecture. Now think of this as a single black box with all of the components of the application within it. So in this example, I'm just showing a subset, but we've got the upload component where Bob uploads his collection of videos where whiskers is on holiday, the processing component which does the conversion of videos, and then we have the store and manage component which interacts with the underlying persistent storage. Now this architecture has a number of considerations, a number of important things to keep in mind. Because it's all one entity, it fails together as an entity. If one component fails, it impacts the whole thing end to end. If uploading fails, it could also affect processing as well as store and manage. Logically, you know that they're separate things, you know that uploading is different than processing, which is different than store and manage, but if they're all contained in a single monolithic architecture, one code base, one big monolithic component, then the failure of any part of that monolith can affect everything else.

The other thing to consider when talking about monoliths is they also scale together. They're highly coupled. All of the components generally expect to be on the same server directly connected and have the same code base. You can't scale one without the other. Generally, with monolithic architectures, you need to vertically scale the system because everything expects to be running on the same piece of compute hardware. And finally, and this is one of the most important aspects of monolithic architectures that you need to be aware of, they generally build together. All of the components of a monolithic architecture are always running and because of that, they always incur charges. Even if the processing engine is doing nothing, even if no videos are being uploaded, the system capacity has to be enough to run all of them. And so they always have allocated resources, even if they aren't consuming them. So using a monolithic architecture tends to be one of the least cost-effective ways to architect systems, ranging from small to enterprise scale.

Now we've seen earlier in the course how we can evolve a monolithic design into a tiered one. With a tiered architecture, the monolith is broken apart. What we have now is a collection of different tiers and each of these tiers can be on the same server or different servers. With this architecture, the different components are still completely coupled together because each of the tiers connects to a single endpoint of another tier. The upload tier needs to be able to send data directly at the processing tier, and again, this could be on the same server or a different server. With the WordPress example that you looked at earlier in the course, we separated the database component of the monolithic application onto its own RDS instance and left the EC2 instance running the Apache web server and the WordPress application. But both of those services still needed to communicate with each other. They were very tightly coupled.

Now, the immediate benefit of a tiered architecture versus a monolith is that these individual tiers can be vertically scaled independently. Put simply, you can increase the size of the server that's running each of these application tiers. What this means is that if the processing tier, for example, requires more CPU capacity, then it can be increased in size to cope with that additional load without having to increase the size of the upload or the store and manage tiers. But this architecture can be evolved even more. Instead of each tier directly connecting to each other tier, we can utilize load balances located between each of the tiers. Remember in the previous section I mentioned internal load balances. This is an example of when internal load balances are useful. It means that in this example the upload tier is no longer communicating with a specific instance of the processing tier. And it means that the store and manage tier is not communicating with a specific instance of the processing tier. Both of them are going via a load balancer. And if you remember from the section of the course where I talked about load balances, this means it's abstracted. It allows for horizontal scaling, meaning additional processing tier instances can be added. Communication occurs via the load balances, so the upload and store and manage tiers have no exposure to the architecture of the processing tier, whether it's one instance or a hundred. This means that the processing tier is now able to be scaled horizontally by adding additional instances, and it's now highly available. If one instance fails, the load balancer just redistributes the connections across the working instances. So by abstracting away from individual instance architecture for the individual tiers, using load balances now means we can scale each tier independently, either vertically or horizontally.

Now, this architecture isn't perfect for two main reasons. First, the tiers are still coupled. The upload tier, for example, expects and requires the processing tier to exist and to respond. While the load balancer means that we can have multiple instances for the processing tier, for example, the processing tier has to exist. If it fails completely, then the upload tier itself will fail because the upload tier expects at least one instance of the processing tier to answer it. If there's a backlog in processing, if the processing tier slows down and it starts to take longer to accept jobs for processing, then that can also impact the upload tier and the customer experience. The other issue with this architecture is that even if there's no jobs to be processed, the processing tier has to have something running. Otherwise, there'll be a failure when the upload tier attempts to add an upload job. So it's not possible to scale the individual tiers of the application back down to zero because the communication is synchronous. The upload tier expects to perform a synchronous communication with the processing tier. It expects to ask for a job to be entered and it requires an answer. So while the tiered architecture improves things, it doesn't solve all of the problems.

Okay, so this is the end of part one of this lesson. It was getting a little bit on the long side and so I wanted to add a break. It's an opportunity just to take a rest or grab a coffee. Part two will be continuing immediately from the end of part one. So go ahead, complete the video, and when you're ready, join me in part two.

Welcome back! In this lesson, I want to talk in a little bit of detail about gateway load balancers. These are a relatively new addition to the load balancer family and are designed for very specific sets of use cases, which I'll cover in this lesson. We have a lot of architectural theory to cover, so let's jump in and get started straight away.

Before we talk about gateway load balancers, I want to step through the type of situation where you might choose to use one. Consider this architecture: the Categorum Application Server in a public subnet communicating with the public internet. Now, what's missing here is some kind of inspection-based security appliance, something which can check data for any exploits to protect our application server. If this is an important application, which it is because it involves cats, we can improve the architecture by adding a security appliance, which would be a transparent security device. It would sit in the flow of traffic inbound and outbound, transparently reviewing traffic as it enters the application from the public internet, protecting the application against any known exploits, and then filtering any traffic on the way back out. For example, detecting and preventing any information leakage.

This works well assuming that we don't really have to think about scaling. The issue comes when we grow or shrink our application. Remember, AWS pushes the concept of elasticity, where applications can grow and shrink based on increasing and decreasing load on a system. When you need to deal with a growing and shrinking number of application instances and where this growth is extreme, you need an appropriate number of security appliances. This can be complex and prone to failures.

Now, this solution is tightly coupled, where the application and security instances are tied together. The failure of one can impact the other. It doesn't scale well even in a single application environment, and it's even more complex if you're trying to build multi-tenant applications. It's in this type of situation where you need to use some kind of security appliance at scale and have flexibility around network architecture. That's when you might choose to use a gateway load balancer. Over the remainder of this lesson, I want to step through what they do, how they function, and how to use them.

A gateway load balancer is a product that AWS has developed to help you run and scale third-party security appliances, such as firewalls, intrusion detection systems, intrusion prevention systems, or even data analysis tools. You might use these, for example, to perform inbound and outbound transparent traffic inspection or protection. AWS has a lot of awesome networking products, but there are many large businesses that use third-party security and networking products. You might do this because you have existing skills with those products and want to use them inside AWS, or you might have a formal requirement to use those products or a specific feature or set of features that only one specific vendor can deliver.

In those cases, you'll need to use a third-party appliance. To do that at scale in a manageable way, you'll need to use a gateway load balancer. At a high level, a gateway load balancer has two major components. First, gateway load balancer endpoints, which run from a VPC where the traffic you want to monitor, filter, or control originates from or is destined to. In the example I'll be using, this would be the VPC where the Categorum Application Instance is hosted. Gateway load balancer endpoints are much like interface endpoints within VPCs, which you've experienced so far, but with some key improvements that I'll talk about in a second.

The second component is the gateway load balancer (GWLB) itself. This load balancer sends packets across multiple back-end instances, which are just normal EC2 instances running security software. In order for this type of architecture to work, the gateway load balancer needs to forward packets without any alteration. The security appliance needs to review packets as they're sent or received—after all, that's the whole point. These packets have source and destination IP addresses that might be okay on the original network but might not work on the network where the security appliances are hosted. So, gateway load balancers use a protocol called Geneva, a tunneling protocol. A tunnel is created between the gateway load balancer and the back-end instances (the security appliances). Packets are encapsulated and sent through this tunnel to the appliances.

Now, let's review this visually, which should help you understand how all the components fit together. Let's say that we have a laptop, and this is accessing the Categorum application. I'm keeping this simple for now and not including any VPC boundaries. I'll show you this in a moment. Traffic leaves the source laptop, moves into a VPC through an internet gateway, and arrives at a gateway load balancer endpoint. Gateway load balancer endpoints are like a normal VPC interface endpoint, with one major difference: they can be added to a route table as the next hop, allowing them to be part of traffic flows controlled by that route table.

So, traffic via a route table is directed at this endpoint, and the traffic flows through to the gateway load balancer. Gateway load balancers work similarly to a network load balancer but integrate with gateway load balancer endpoints and encapsulate all traffic that they handle using the Geneva protocol. This means that packets are unaltered—they have the same source IP, destination IP, source port, destination port, and contents as when they were created and sent. This allows the security appliances to scan the packets, review them for any security issues, block them as required, perform analysis, or adjust them as needed. When finished, the packets are returned over the same tunnel, encapsulated back to the load balancer, where the Geneva encapsulation is removed, and the packets move back to the gateway load balancer endpoint and through to the intended destination.

The benefits of this architecture are that gateway load balancers will load balance across security appliances, so you can horizontally scale. The gateway load balancer manages flow stickiness, so one flow of data will always use one appliance. This is useful because it allows that appliance to monitor the state of flows through a system. It provides abstraction, meaning you can use multiple security appliances to provide resilience. If one fails, packets are just moved over to another available security appliance. In this way, it's much like other load balancers within AWS.

Just before we finish up with this lesson, I wanted to provide a more detailed typical architecture where you might use a gateway load balancer. This is the Category application, running in a pair of private subnets at the bottom, behind an application load balancer which is running in a pair of public subnets. Off to the right, we have a separate VPC running a set of security appliances inside an auto-scaling group, so this can grow and shrink based on load to the application. Now, what I want to do now is step through traffic flow through this architecture and show you how the gateway load balancer architecture works to ensure we can scale this security platform.

We start at the top with a client accessing the web application. This flow will arrive at the application load balancer, which uses public addressing. Logically, it first hits the internet gateway. The internet gateway is configured with an ingress route table, also known as a gateway route table, which influences what happens as traffic arrives at the VPC. In this case, our packets are destined for the public IP that the application load balancer on the right is using. The internet gateway first translates the destination public IP address to the corresponding private IP of that application load balancer, which will be running inside the 10.16.96.0/20 subnet.

The third route is used because it's the most specific route for the 10.16.96.0/20 range, and traffic is sent toward the gateway load balancer endpoint in the right availability zone. Gateway load balancer endpoints are like interface endpoints, but they can be the targets within routes. The gateway load balancer endpoint receives these packets and moves them to the gateway load balancer itself, running in the security VPC. At this point, the packets still have the original IP addressing, and this would normally be a problem, since the security VPC might be using a different or conflicting IP range. However, while the source and destination addressing remain the same, the packets are encapsulated using the Geneva protocol and sent through unaltered to the security appliance chosen by the gateway load balancer.

Once the analysis is complete, the packets are returned encapsulated to the gateway load balancer. The encapsulation is stripped, and they are returned via the endpoint to the Category VPC. Since the original IP addressing is maintained, the route table on the top public subnet is used, which has a local route for the VPC-side range. The most specific route is used, and packets flow through to the application load balancer and from there to the chosen application instance. The logic for this is decided by the application load balancer.

The return path uses the same logic. Data leaves the application instance in response to the initial communication from the laptop and will return via the application load balancer. The load balancer is in a subnet with a local route, but the default route goes toward the gateway load balancer endpoint in the same availability zone. Since traffic is going back to the client device that originally accessed the Category application, it will have a public IP destination IP address, so the default route will be used. This means the packets will flow back to the gateway load balancer endpoint and then through to the gateway load balancer, where they'll be encapsulated, passed through to the appliances, then back to the load balancer, de-encapsulated, and passed back to the gateway load balancer endpoint.

Once they’re back at the gateway load balancer endpoint, the subnet has the internet gateway as the default route. This will be used, and traffic moves through the internet gateway, where its source IP will be changed to the corresponding public one of the application load balancer, then sent to the original client device.

And that's it: transparent inline network security done in a scalable, resilient, and abstracted way. I'll be talking more about some of the more nuanced features in other lessons, but for now, that's the basics of gateway load balancers. In terms of architecture, they share many elements with network and application load balancers, including the target group architecture, but they have a very specific purpose: network security at scale. With that said, that's everything I wanted to cover in this video. Go ahead and complete the lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this brief lesson, I want to cover two features of the Elastic Load Balancer series of products, and those features are SSL offload and session stickiness. Now, you'll need to be aware of the architecture of both of these for the exam. The implementation details aren't required; the theory of the architecture is what matters, so let's jump in and get started. Now, there are three ways that a load balancer can handle secure connections, and these three ways are bridging, pass-through, and offload. Each of these comes with their pros and cons, and for the exam and to be a good solutions architect, you need to understand the architecture and the positives and negatives of them all, so let's step through each of these in turn.

So, first, we've got bridging mode, and this is actually the default mode of an application load balancer. With bridging mode, one or more clients make one or more connections to a load balancer, and that load balancer is configured so that its listener uses HTTPS, and this means that SSL connections occur between the client and the load balancer. So, they're decrypted, known as terminated, on the load balancer itself, and this means that the load balancer needs an SSL certificate which matches the domain name that the application uses, and it also means, in theory, that AWS does have some level of access to that certificate, and that's important if you have strong security frameworks that you need to stay inside of. So, if you're in a situation where you need to be really careful about where your certificates are stored, then potentially, you might have a problem with bridged mode. Once the secure connection from the client has been terminated on the load balancer, the load balancer makes second connections to the backend compute resources (EC2 instances in this example). Remember, HTTPS is just HTTP with a secure wrapper. So, when the SSL connection comes from the client to the front-facing listener side of the load balancer, it gets terminated, which essentially means that the SSL wrapper is removed from the unencrypted HTTP that's inside. So, the load balancer has access to the HTTP, which it can understand and use to make decisions. So, the important thing to understand is that an application load balancer in bridging mode can actually see the HTTP traffic. It can take actions based on the contents of HTTP, and this is the reason why this is the default mode for the application load balancer. And it's also the reason why the application load balancer requires an SSL certificate because it needs to decrypt any data that's being encrypted by the client, it needs to decrypt it first, then interpret it, then create new encrypted sessions between it and the backend EC2 instances.

Now, this also means that the EC2 instances will need matching SSL certificates, so certificates that match the domain name that the application is using. So, the Elastic Load Balancer will re-encrypt the HTTP within a secure wrapper and deliver this to the EC2 instances, which will use the SSL certificate to decrypt that encrypted connection. So, they both need the SSL certificates to be located on the EC2 instances, as well as needing the compute to be able to perform those cryptographic operations. So, in bridging mode (which is the default), every EC2 instance at the backend needs to perform cryptographic operations, and for high-volume applications, the overhead of performing these operations can be significant. So, the positives of this method is that the Elastic Load Balancer gets to see the unencrypted HTTP and can take actions based on what's contained in this plain-text protocol. The method does have negatives, though, because the certificate does need to be stored on the load balancer itself, and that's a risk, and then the EC2 instances also need a copy of that certificate, which is an admin overhead, and they need the compute to be able to perform the cryptographic operations. So, those are two pretty important negatives that can play a part in which connection method you select for any architectures that you design.

Now, next we have SSL pass-through, and this architecture is very different. With this method, the client connects, but the load balancer just passes that connection along to one of the backend instances; it doesn't decrypt it at all. The connection encryption is maintained between the client and the backend instances. The instances still need to have the SSL certificates installed, but the load balancer doesn't. Specifically, it's a network load balancer which is able to perform this style of connection architecture. The load balancer is configured to listen using TCP, so this is important. It means that it can see the source and destination IP addresses and ports, so it can make basic decisions about which instances send traffic to (i.e., the process of performing the load balancing), but it never touches the encryption. The encrypted connection exists as one encrypted tunnel between the client all the way through to one of the backend instances. Now, using this method means that AWS never needs to see the certificate that you use; it's managed and controlled entirely by you. You can even use a Cloud HSM appliance (which I'll talk about later in the course) to make this even more secure. The negative, though, is that you don't get to perform any load balancing based on the HTTP part because that's never decrypted. It's never exposed to the network load balancer, and the instances still need to have the certificates and still need to perform the cryptographic operations, which uses compute.

Now, the last method that we have is SSL offload, and with this architecture, clients connect to the load balancer in the same way using HTTPS. The connections use HTTPS and are terminated on the load balancer, and so it needs an SSL certificate which matches the name that's used by the application, but the load balancer is configured to connect to the backend instances using HTTP, so the connections are never encrypted again. What this means is that from a customer perspective, data is encrypted between them and the load balancer, so at all times while using the public internet, data is encrypted, but it transits from the load balancer to the EC2 instances in plain-text form. It means that while a certificate is required on the load balancer, it's not needed on the EC2 instances. The EC2 instances only need to handle HTTP traffic, and because of that, they don't need to perform any cryptographic operations, which reduces the per-instance overhead and also potentially means you can use smaller instances. The downside is that data is in plain-text form across AWS's network, but if this isn't a problem, then it's a very effective solution.

So, now that we've talked about the different connection architectures, now let's quickly talk about stickiness. Connection stickiness is a pretty important concept to understand for anybody designing a scalable solution using load balancers. Now, let's look at an example architecture. We have our customer Bob, a load balancer, and a set of backend EC2 instances. If we have no session stickiness, then for any sessions which Bob or anyone else makes, they're distributed across all of the backend instances based on fair balancing and any health checks. So, generally, this means a fairly equal distribution of connections across all backend instances. The problem with this approach, though, is that if the application doesn't handle sessions externally, every time Bob lands on a new instance, it would be like he's starting again. He would need to log in again and fill his shopping cart again. Applications need to be designed to handle state appropriately; an application which uses stateless EC2 instances where the state is handled in, say, DynamoDB can use this non-sticky architecture and operate without any problems. But if the state is stored on a particular server, then you can't have sessions being fully load balanced across all of the different servers because every time a connection moves to a different server, it will impact the user experience.

Now, there is an option available within Elastic Load Balancers called session stickiness, and within an application load balancer, this is enabled on a target group. Now, what this means is that if enabled, the first time that a user makes a request, the load balancer generates a cookie called AWSALB, and this cookie has a duration which you define when enabling the feature, and a valid duration is anywhere between 1 second and 7 days. If you enable this option, it means that every time a single user accesses this application, the cookie is provided along with the request, and it means that for this one particular cookie, sessions will be sent always to the same backend instance. So, in this case, all connections will go to EC2-2 for this one particular user. Now, this situation of sending sessions to the same server will happen until one of two things occur. The first thing is that if we have a server failure, so in this example, if EC2-2 fails, then this one particular user will be moved over to a different EC2 instance. And the second thing which can occur to change this session stickiness is that the cookie can expire. As soon as the cookie expires and disappears, the whole process will repeat over again, and the user will receive a new cookie and be allocated a new backend instance.

Session stickiness is designed to allow an application to function using a load balancer if the state of the user session is stored on an individual server. The problem with this method is that it can cause uneven load on backend servers because a single user, even if he or she is causing significant amounts of load, will only ever use one single server. Where possible, applications should be designed to use stateless servers, so holding the session or user state somewhere else, so not on the EC2 instance, but somewhere else like DynamoDB. And if you do that, if you host the session externally, it means that the EC2 instances are completely stateless, and load balancing can be performed automatically by the load balancer without using cookies in a completely fair and balanced way.

So, that's everything I wanted to cover about connection stickiness, and that's now the end of this lesson. I just wanted to quickly cover two pretty important techniques that you might need to be aware of for the exam. So, at this point, go ahead and complete the video, and when you're ready, as always, I'll look forward to you joining me in the next lesson.

Welcome back, and in this lesson, I want to talk about Auto Scaling Groups and health checks. Now, this is going to be fairly brief, but it's something that's really important for the exam, so let's jump in and get started. Auto Scaling Groups assess the health of instances within that group using health checks, and if an instance fails a health check, it is replaced within the Auto Scaling Group, which is a method of automatically healing the instances within the group. Now, there are three different types of health checks that can be used with Auto Scaling Groups: EC2, which is the default, ELB checks that can be enabled on an Auto Scaling Group, and custom health checks.

With EC2 checks, which are the default, any of these statuses is viewed as unhealthy: essentially, anything but the instance running is considered unhealthy. So, if the instance is stopping, stopped, terminated, shutting down, or impaired (meaning it doesn't have two out of two status checks), it is viewed as unhealthy. We also have the option of using load balancer health checks, and for an instance to be viewed as healthy when this option is used, the instance needs to be both running and passing the load balancer health check. This is important because if you're using an application load balancer, these checks can be application-aware. You can define a specific page of the application to be used as a health check, and you can do text pattern matching, which can be checked using an application load balancer. So, when you integrate this with an Auto Scaling Group, the checks that the Auto Scaling Group is capable of performing become much more application-aware.

Finally, we have custom health checks, where an external system can be integrated to mark instances as healthy or unhealthy. This allows you to extend the functionality of the Auto Scaling Group health checks by implementing a process specific to your business or using an external tool. Now, I also want to introduce the concept of a health check grace period. By default, this is 300 seconds or 5 minutes, and this is essentially a configurable value that needs to expire before health checks take effect on a specific instance. So, in this particular case, if you select 300 seconds, it means that the system has 5 minutes to launch, perform any bootstrapping, and complete any application startup procedures or configuration before it can fail a health check. This is really useful if you're performing bootstrapping with your EC2 instances that are launched by the Auto Scaling Group.

Now, this is an important concept because it does come up on the exam and is often a cause of an Auto Scaling Group continuously provisioning and then terminating instances. If you don't have a sufficiently long health check grace period, you can be in a situation where the health checks start taking effect before the applications have finished configuring, and at that point, the instance will be viewed as unhealthy, terminated, and a new instance will be provisioned, and that process will repeat over and over again. So, you need to know how long your application instances take to launch, bootstrap, and perform any configuration processes, and that's how long you need to set your health check grace period to be.

Now, that's everything I wanted to cover in this brief theory lesson. I just wanted to make sure you understand the options that you have available for health checks within Auto Scaling Groups. With that being said, go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to quickly cover a pretty advanced feature of Auto Scaling Groups, and that's Auto Scaling Group Lifecycle Hooks. Let's jump in and take a look at what these are and how they work. Lifecycle hooks allow you to configure custom actions that can occur during Auto Scaling Group actions, meaning you can define actions during either instance launch transitions or instance terminate transitions. When an Auto Scaling Group scales out or in, it will either launch or terminate instances, and normally, this process is completely under the control of the Auto Scaling Group. As soon as it makes a decision to provision or terminate an instance, this process happens with no ability for you to influence the outcome. However, with lifecycle hooks, when you create them, instances are paused within the launch or terminate flow, waiting in this state until either a configurable timeout expires (the default being 3600 seconds), after which the process continues or is abandoned, or you explicitly resume the process using the "complete lifecycle action" after performing the desired activity. Additionally, lifecycle hooks can be integrated with EventBridge or SNS notifications, enabling your systems to perform event-driven processing based on the launch or termination of EC2 instances within an Auto Scaling Group.

Visually, let's start with a simple Auto Scaling Group. If we configure instance launch and terminate hooks, this is what it might look like: normally, when an Auto Scaling Group scales out, an instance will be launched and initially placed in a pending state. Once it completes, it moves to the "in service" state, but this doesn’t give us any opportunity to perform custom activities. If we hook into this transition with a lifecycle hook, the instance would move from "pending" to "pending wait," staying in this state until the custom actions are performed. An example might be loading or indexing data, which could take some time, and during this time, the instance remains in the "pending wait" state. Once the process is done, the instance moves to "pending proceed," and then to "in service." This is the process when configuring a lifecycle hook for the instance launch transition. The same happens in reverse when we define an instance terminate hook: normally, the instance would move from "terminating" to "terminated," with no opportunity for custom actions. However, with a lifecycle hook, the instance moves from "terminating" to "terminating wait," where it stays for a timeout period (default 3600 seconds), or until we explicitly call the "complete lifecycle action" operation. This period could be used to back up data, logs, or clean up the instance prior to termination. Once the timeout expires or we call the "complete lifecycle action," the instance moves from "terminating wait" to "terminating proceed," and then to "terminated." Finally, lifecycle hooks integrate with SNS for transition notifications, and EventBridge can also be used to initiate other processes in an event-driven way. That’s everything I wanted to cover about lifecycle hooks, so at this point, go ahead and complete this lesson, and when you're ready, I look forward to you joining me in the next one.

Welcome back and in this lesson I want to cover in a little bit more detail something I've touched on earlier and that's Auto Scaling Group Scaling Polices, so let's just jump in and get started.

One thing many students get confused over is whether scaling policies are required on an Auto Scaling Group, and now you'll see in demos elsewhere in the course that this is not the case; they can be created without any Auto Scaling Policies and they work just fine. When created without any scaling policies, it means that an Auto Scaling Group has static values for min size, max size, and desired capacity. Now if you hear the term manual scaling, that actually refers to when you manually adjust these values, which is useful in testing or urgent situations or when you need to hold capacity at a fixed number of instances, for example, as a cost control measure.

Now in addition to manual scaling, we also have different types of dynamic scaling which allow you to scale the capacity of your Auto Scaling Group in response to changing demand. There are a few different types of dynamic scaling and I want to introduce them here and then cover them in a little bit more detail. At a high level, each of these adjusts the desired capacity of an Auto Scaling Group based on a certain criteria. First, we have simple scaling, and with this one you define actions which occur when an alarm moves into an alarm state. For example, by adding one instance if CPU utilization is above 40% or removing one instance if CPU utilization is below 40%, this helps infrastructure scale out and in based on demand. The problem is that this scaling is inflexible; it's adding or removing a static amount based on the state of an alarm, so it's simple but not all that efficient.

Step scaling increases or decreases the desired capacity based on a set of scaling adjustments known as step adjustments that vary based on the size of the alarm breach. So you can define upper and lower bounds, for example, you can pick a CPU level which you want, say 50%, and you can say that if the actual CPU is between 50 and 60%, then do nothing; if the CPU is between 60 and 70%, then add one instance, or if the CPU is between 70 and 80%, add two instances, and then finally, the CPU is between 90 and 100%, then add three instances, and you can do the same in reverse. The same step changes as CPU is below 50%, only removing rather than adding instances. Now generally step scaling is always better than simple because it allows you to adjust better to changing load patterns on the system.

Next we have target tracking, which comes with a predefined set of metrics. Currently, this is CPU utilization, average network in, average network out, and ALB request count per target. Now the premise is simple enough: you define an ideal value, so the target that you want to track against for that metric, for example, you might say that you want 50% CPU on average. The auto scaling group then calculates the scaling adjustment based on the metric and the target value all automatically. The auto scaling group keeps the metric at the value that you want and it adjusts the capacity as required to make that happen, so the further away the actual value of the metric is from your target value, the more extreme the action, either adding or removing compute. Then lastly, it's possible to scale based on an SQS queue and this is a common architecture for a workload where you can increase or decrease capacity based on the approximate number of messages visible, so as more messages are added to the queue, the auto scaling group increases in capacity to process messages, and then as the queue empties, the group scales back to reduce costs.

Now one really common area of confusion is the difference between simple scaling and step scaling. AWS recommends step scaling versus simple at this point in time but it's important to understand why, so let's take a look visually. Let's start with some simple scaling and I want to explain this using the same auto scaling group but at three points in time. The auto scaling group is initially configured with a minimum of one, a maximum of four, and a desired of one, and that means right now we're going to have one out of a maximum of four instances provisioned and operational, and let's also assume that the current average CPU is 10%. Now with simple scaling, we create or use an existing alarm as a guide. Let's say that we decide to use the average CPU utilization, so we create two different scaling rules. The first, which says that if average CPU is above 50%, then add two instances, and another which removes two instances if the CPU is below 50%. With this type of scaling, if the CPU suddenly jumped to say 60%, then the top rule would apply and this rule would add two instances, changing the desired capacity from one to three. This value is still within the minimum of one and the maximum of four, and so two additional instances would be provisioned with room for a fourth. If the CPU usage dropped to say 10%, then the second rule would apply and the desired capacity would be reduced by two or set to the minimum, so in this case, it would change from three to one. Two instances would be terminated and the auto scaling group would be running with one instance and a capacity for three more as required. Now this works but it's not very flexible. Whatever the load, whether it's 1% over what you want or 50% over, two instances are added, and the same is used in reverse. Whether it's 1% below what you want or 50% below, the same two instances are always removed, so with simple scaling, you're adding or removing the same amount no matter how extreme the increases and decreases in the metric that you're monitoring.

With step scaling, it's more flexible. So with step scaling, you're still checking an alarm but for step scaling, you can define rules with steps, so you can define an alarm which alarms when the CPU is above 50% and one which alarms when the CPU is below 50%, and you can create steps which adjust capacity based on how far away from that value it is. So in this case, if the CPU usage is between 50 and 59%, do nothing, between 60 and 69%, add one, between 70 and 79%, add two, and then between 80 and 100%, add three, and the same in reverse: so between 40 and 49%, do nothing, between 30 and 39%, remove one, between 20 and 29%, remove two, and then between 0 and 19%, remove three. So let's say that we had an auto scaling group at six points in time, so we start with the auto scaling group on the left and let's say that it has 5% load and let's say that we have the same minimum, one, maximum four, as the previous example. The policy is trying to remove three instances with this level of CPU, but as the auto scaling group has the minimum of one, the auto scaling group starts with one instance with a capacity for a further three as required. If our application receives a massive amount of incoming load, let's say that the CPU usage increases to 100%, and this is an extreme example, but based on the scaling policy, this would add three instances, taking us to the maximum value of four, so our auto scaling group now has four instances running, which is also the maximum value for that group. Now at this point, with the same amount of incoming load, the increased number of instances is probably going to reduce the average CPU. Let's say that it reduces it to 55%, well, this causes no change in instances, and neither added or removed because anything in the range of 40 to 59% means zero change. Next, say that the load on the system reduces, so CPU drops to 5%, and this removes three instances, dropping the desired capacity down to one with the option for a further three instances as required. Next, the average CPU stays at 5%, but the minimum of the auto scaling group is one, so the number of instances stay the same even though the step scaling rule should attempt to remove three instances at this level, so we always have the minimum number of instances as defined within the minimum value of the auto scaling group. Now maybe we end the day with some additional load on the system, let's say for example that the CPU usage goes to 60%, and this adds one additional instance, so you should be able to see by now that step scaling is great for variable load where you need to control how systems scale out and in. It allows you to handle large increases and decreases in load much better than simple scaling, so based on how extreme the increase or decrease is determines how many units of compute are added or removed; it's not static like simple scaling, and that's the main difference between simple and step: the ability to scale in different ways based on how extreme the load changes are.

With that being said though, that's everything I wanted to cover in this lesson. Go ahead and complete the video, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this lesson I'm going to be covering EC2, auto scaling groups, which is how we can configure EC2 to scale automatically based on demand placed on the system. Auto scaling groups are generally used together with elastic load balances and launch templates to deliver elastic architectures. Now we've got a lot to cover, so let's jump in and get started.

Auto scaling groups do one thing — they provide auto scaling for EC2. Strictly speaking, they can also be used to implement a self-healing architecture as part of that scaling or in isolation. Auto scaling groups make use of configuration defined within launch templates or launch configurations, and that's how they know what to provision. An auto scaling group uses one launch configuration or one specific version of a launch template which is linked to it. You can change which of those is associated, but it's one of them at a time, and so all instances launched using the auto scaling group are based on this single configuration definition, either defined inside a specific version of a launch template or within a launch configuration.

Now, an auto scaling group has three super important values associated with it — the minimum size, the desired capacity, and the maximum size — and these are often referred to as min, desired, and max, and can often be expressed as x, y, or z. For example, 1, 2, 4 means 1 minimum, 2 desired, and 4 maximum. An auto scaling group has one foundational job which it performs — it keeps the number of running EC2 instances the same as the desired capacity, and it does this by provisioning or terminating instances. So, the desired capacity always has to be more than the minimum size and less than the maximum size.

If you have a desired capacity of 2 but only one running EC2 instance, then the auto scaling group provisions a new instance. If you have a desired capacity of 2 but have three running EC2 instances, then the auto scaling group will terminate an instance to make these two values match. You can keep an auto scaling group entirely manual so there's no automation and no intelligence — you just update values and the auto scaling group performs the necessary scaling actions.

Normally though, scaling policies are used together with auto scaling groups. Scaling policies can update the desired capacity based on certain criteria, for example CPU load, and if the desired capacity is updated, then as I've just mentioned, it will provision or terminate instances.

Visually, this is how it looks: we have an auto scaling group, and these run within a VPC across one or more subnets. The configuration for EC2 instances is provided either using launch templates or launch configurations, and then on the auto scaling group we specify a minimum value — in this case 1 — and this means there will always be at least one running EC2 instance, in this case the cat pictures blog. We can also set a desired capacity, in this example 2, and this will add another instance if a desired capacity is set which is higher than the current number of instances. If this is the case, then instances are added. Finally, we could set the maximum size — in this case to 4 — which means that two additional instances could be provisioned, but they won't immediately be because the desired capacity is only set to 2 and there are currently two running instances.

We could manually adjust the desired capacity up or down to add or remove instances which would automatically be built based on the launch template or launch configuration. Alternatively, we could use scaling policies to automate that process and scale in or out based on sets of criteria.

Architecturally, auto scaling groups define where instances are launched. They're linked to a VPC, and subnets within that VPC are configured on the auto scaling group. Whatever subnets are configured will be used to provision instances into. When instances are provisioned, there's an attempt to keep the number of instances within each availability zone even. So in this case, if the auto scaling group was configured with three subnets and the desired capacity was also set to three, then it's probable each subnet would have one EC2 instance running within it — but this isn't always the case. The auto scaling group will try and level capacity where available.

Scaling policies are essentially rules — rules which you define which can adjust the values of an auto scaling group — and there are three ways that you can scale auto scaling groups. The first is not really a policy at all — it's just to use manual scaling, and I just talked about doing that. This is where you manually adjust the values at any time and the auto scaling group handles any provisioning or termination that's required.

Next there's scheduled scaling, which is great for sale periods where you can scale out the group when you know there's going to be additional demand or when you know a system won't be used so you can scale in outside of business hours. Scheduled scaling adjusts the desired capacity based on schedules, and this is useful for any known periods of high or low usage. For the exam, if you have known periods of usage, then scheduled scaling is going to be a great potential answer.

Then we have dynamic scaling, and there are three subtypes. What they all have in common is they are rules which react to something and change the values on an auto scaling group. The first is simple scaling — and this, well, it's simple. This is most commonly a pair of rules — one to provision instances and one to terminate instances. You define a rule based on a metric, and an example of this is CPU utilization. If the metric, for example CPU utilization, is above 50% then adjust the desired capacity by adding one, and if the metric is below 50% then remove one from the desired capacity. Using this method you can scale out (meaning adding instances) or scale in (meaning terminating instances) based on the value of a metric.

Now, this metric isn't limited to CPU — it can be many other metrics including memory or disk input/output. Some metrics need the CloudWatch agent to be installed. You can also use some metrics not on the EC2 instances — for example, maybe the length of an SQS queue (which we'll cover elsewhere in the course) or a custom performance metric within your application such as response time.

We also have stepped scaling, which is similar, but you define more detailed rules, and this allows you to act depending on how out of normal the metric value is. So maybe add one instance if the CPU usage is above 50%, but if you have a sudden spike of load maybe add three if it's above 80%, and the same could happen in reverse. Step scaling allows you to react quicker the more extreme the change in conditions. Step scaling is almost always preferable to simple — except when your only priority is simplicity.

And then lastly we have target tracking, and this takes a slightly different approach — it lets you define an ideal amount of something, say 40% aggregate CPU, and then the group will scale as required to stay at that level, provisioning or terminating instances to maintain that desired amount or that target amount. Not all metrics work for target tracking, but some examples of ones that are supported are average CPU utilization, average network in, average network out, and the one that's relevant to application load balancers — request count per target.

Now lastly there's a configuration on an auto scaling group called a cooldown period, and this is a value in seconds. It controls how long to wait at the end of a scaling action before doing another. It allows auto scaling groups to wait and review chaotic changes to a metric and can avoid costs associated with constantly adding or removing instances — because remember, there is a minimum billable period since you'll be billed for at least the minimum time every time an instance is provisioned, regardless of how long you use it for.

Now auto scaling groups also monitor the health of instances that they provision. By default, this uses the EC2 status checks. So if an EC2 instance fails, EC2 detects this, passes this on to the auto scaling group, and then the auto scaling group terminates the EC2 instance — then it provisions a new EC2 instance in its place. This is known as self-healing, and it will fix most problems isolated to a single instance. The same would happen if we terminated an instance manually — the auto scaling group would simply replace it.

Now there's a trick with EC2 and auto scaling groups — if you create a launch template which can automatically build an instance, then create an auto scaling group using that template, set the auto scaling group to use multiple subnets in different availability zones, then set the auto scaling group to use a minimum of one, a maximum of one, and a desired of one, then you have simple instance recovery. The instance will recover if it's terminated or if it fails. And because auto scaling groups work across availability zones, the instance can be reprovisioned in another availability zone if the original one fails. It's cheap, simple, and effective high availability.

Now auto scaling groups are really cool on their own, but their real power comes from their ability to integrate with load balancers. Take this example: Bob is browsing to the cat blog that we've been using so far, and he's now connecting through a load balancer. And the load balancer has a listener configured for the blog and points at a target group. Instead of statically adding instances or other resources to the target group, then you can use an auto scaling group configured to integrate with the target group.

As instances are provisioned within the auto scaling group, then they're automatically added to the target group of that load balancer. And then as instances are terminated by the auto scaling group, then they're removed from that target group. This is an example of elasticity because metrics which measure load on a system can be used to adjust the number of instances. These instances are effectively added as load balancer targets, and any users of the application, because they access via the load balancer, are abstracted away from the individual instances and they can use the capacity added in a very fluid way.

And what's even more cool is that the auto scaling group can be configured to use the load balancer health checks rather than EC2 status checks. Application load balancer checks can be much richer — they can monitor the state of HTTP or HTTPS requests. And because of this, they're application aware, which simple status checks which EC2 provides are not.

Be careful though — you need to use an appropriate load balancer health check. If your application has some complex logic within it and you're only testing a static HTML page, then the health check could respond as okay even though the application might be in a failed state. And the inverse of this — if your application uses databases and your health check checks a page with some database access requirements — well, if the database fails then all of your health checks could fail, meaning all of your EC2 instances will be terminated and reprovisioned when the problem is with the database, not the instances. And so you have to be really careful when it comes to setting up health checks.

Now the next thing I want to talk about is scaling processes within an auto scaling group. So you have a number of different processes or functions performed by the auto scaling group, and these can be set to either be suspended or they can be resumed.

So first we've got launch and terminate, and if launch is set to suspend, then the auto scaling group won't scale out if any alarms or schedule actions take place. And the inverse is if terminate is set to suspend, then the auto scaling group will not terminate any instances. We've also got add to load balancer, and this controls whether any instances provisioned are added to the load balancer. Next we've got alarm notification, and this controls whether the auto scaling group will react to any CloudWatch alarms. We've also got AZ rebalance, and this controls whether the auto scaling group attempts to redistribute instances across availability zones.

We've got health check, and this controls whether instance health checks across the entire group are on or off. We've also got replace unhealthy, which controls whether the auto scaling group will replace any instances marked as unhealthy. We've got scheduled actions, which controls whether the auto scaling group will perform any scheduled actions or not. And then in addition to those, you can set a specific instance to either be standby or in service, and this allows you to suspend any activities of the auto scaling group on a specific instance.

So this is really useful — if you need to perform maintenance on one or more EC2 instances, you can set them to standby, and that means they won't be affected by anything that the auto scaling group does.

Now before we finish, I just want to talk about a few final points, and these are really useful for the exam. Auto scaling groups are free — the only costs are for the resources created by the auto scaling group, and to avoid excessive costs, use cooldowns within the auto scaling group to avoid rapid scaling.

To be cost-effective, you should also think about using more smaller instances, because this means you have more granular control over the amount of compute and therefore costs that are incurred by your auto scaling group. So if you have two larger instances and you need to add one, that's going to cost you a lot more than if you have 20 smaller instances and only need to add one. Smaller instances mean more granularity, which means you can adjust the amount of compute in smaller steps, and that makes it a more cost-effective solution.

Now auto scaling groups are used together with application load balancers for elasticity, so the load balancer provides the level of abstraction away from the instances provisioned by the auto scaling group, so together they're used to provision elastic architectures.

And lastly, an auto scaling group controls the when and the where — so when instances are launched and which subnets they're launched into. Launch templates or launch configurations define the what — so what instances are launched and what configuration those instances have.

Now at this point, that's everything I wanted to cover in this lesson — it's been a huge amount of theory for one lesson, but these are really essential concepts that you need to understand for the exam. So go ahead and complete this lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back and in this lesson I want to cover two features of EC2, launch configurations and launch templates; now they both perform a similar thing, but launch templates came after launch configurations and include extra features and capabilities. Now I want this lesson to be fairly brief, as launch configurations and launch templates are actually relatively easy to understand, and what we're going to be covering in the next lesson is auto scaling groups which utilize either launch configurations or launch templates. So I'll try to keep this lesson as focused as possible, but let's jump in and get started.

Launch configurations and launch templates at a high level perform the same task: they allow the configuration of EC2 instances to be defined in advance, with documents which let you configure things like the AMI to use, the instance type and size, the configuration of the storage which instances use, and the key pair which is used to connect to that instance. They also let you define the networking configuration and security groups that an instance uses, configure the user data which is provided to the instance, and the IAM role which is attached to the instance used to provide the instance with permissions. Everything which you usually define at the point of launching an instance, you can define in launch configurations and launch templates.

Now both of these are not editable; you define them once and that configuration is locked. Launch templates, as the newer of the two, allow you to have versions, but for launch configurations, versions aren't available. Launch templates also have additional features or allow you to control features of the newer types of instances—things like T2 or T3 unlimited CPU options, placement groups, capacity reservations, and things like elastic graphics.

AWS recommend using launch templates at this point in time because they're a super set of launch configuration; they provide all of the features that launch configuration provides and more. Architecturally, launch templates also offer more utility. Launch configurations have one use: they're used as part of auto scaling groups which we'll be talking about later in this section. Auto scaling groups offer automatic scaling for EC2 instances, and launch configurations provide the configuration of those EC2 instances which will be launched by auto scaling groups. And as a reminder, they're not editable nor do they have any versioning capability; if you need to adjust the configuration inside a launch configuration, you need to create a new one and use that new launch configuration.

Now launch templates—they can also be used for the same thing, so providing EC2 configuration which is used within auto scaling groups—but in addition, they can also be used to launch EC2 instances directly from the console or the CLI, so good old Bob can define his instance configuration in advance and use that when launching EC2 instances.

Now you'll get the opportunity to create and use launch templates in the series of demo lessons later in this section; for now, I just wanted to cover all of the theory back to back so you can appreciate how it all fits together.

That's everything though that I wanted to cover in this lesson about launch configurations and launch templates. In the next lesson, I'll be talking about auto scaling groups which are closely related; both of them work together to allow EC2 instances to scale in response to the incoming load on a system. But for now, go ahead and finish this video and when you're ready, I look forward to speaking to you in the next.

Welcome back, and in this lesson, I want to cover application and network load balances in a little bit more detail. It's critical for the exam that you understand when to pick application load balances and when to pick network load balances, as they're both used for massively different situations. Now, we do have a lot to cover, so let's jump in and get started.

I want to start by talking about consolidation of load balances. Historically, when using classic load balances, you connected instances directly to the load balancer or you integrated an auto scaling group directly with that load balancer, an architecture which looked something like this: a single domain name, categor.io, using a single classic load balancer with an attached single SSL certificate for that domain, and then an auto scaling group is attached to that, with the classic load balancer distributing connections over those instances.

The problem is that this doesn't scale because classic load balancers don't support SNI, and you can't have multiple SSL certificates per load balancer, meaning every single unique HTTPS application that you have requires its own classic load balancer, which is one of the many reasons that classic load balancers should be avoided. In this example, we have Catergram and Dogagram, both of which are HTTPS applications, and the only way to use these is to have two different classic load balancers.

Compare this to the same application architecture, with both applications—Catergram and Dogagram—this time using a single application load balancer. This one handles both applications, and we can use listener-based rules, which I’ll talk about later in the lesson, where each of these listener-based rules can have an SSL certificate handling HTTPS for both domains. Then we can have host-based rules which direct incoming connections at multiple target groups that forward these on to multiple auto scaling groups, which is a two-to-one consolidation—halving the number of load balancers required to deliver these two different applications.

But imagine how this would look if we had a hundred legacy applications and each of these used a classic load balancer; moving from version one to version two offers significant advantages, and one of those is consolidation. So now I just want to focus on some of the key points about application load balancers—things which are specific to the version two or application load balancer.

First, it's a true layer seven load balancer and it's configured to listen on either HTTP or HTTPS protocols, which are layer seven application protocols that an application load balancer understands and can interpret information carried using both. Now, the flip side is that the application load balancer can't understand any other layer seven protocols—so things such as SMTP, SSH, or any custom gaming protocols are not supported by a layer seven load balancer like the application load balancer, and that's important to understand.

Additionally, the application load balancer has to listen using HTTP or HTTPS listeners; it cannot be configured to directly listen using TCP, UDP, or TLS, and that does have some important limitations and considerations that you need to be aware of, which I’ll talk about later on in this lesson.

Because it's a layer seven load balancer, it can understand layer seven content—so things like the type of the content, any cookies used by your application, custom headers, user location, and application behavior—meaning the application load balancer is able to inspect all of the layer seven application protocol information and make decisions based on that, something that the network load balancer cannot do. It has to be a layer seven load balancer, like the application load balancer, to understand all of these individual components.

An important consideration about the application load balancer is that any incoming connections—HTTP or HTTPS (and remember HTTPS is just HTTP transiting using SSL or TLS)—in all of these cases, whichever type of connection is used, are terminated on the application load balancer. This means that you can't have an unbroken SSL connection from your customer through to your application instances—it’s always terminated on the load balancer, and then a new connection is made from the load balancer through to the application.

This matters to security teams, and if your business operates in a strict security environment, this might be very important and, in some cases, can exclude using an application load balancer. It can't do end-to-end unbroken SSL encryption between a client and your application instances, and it also means that all application load balancers which use HTTPS must have SSL certificates installed on the load balancer, because the connection has to be terminated there and then a new connection made to the instances.

Application load balancers are also slower than network load balancers because additional levels of the networking stack need to be processed, and the more levels involved, the more complexity and the slower the processing. So if you're facing any exam questions that are really strict on performance, you might want to look at network load balancers instead.

A benefit of application load balancers is that, because they're layer seven, they can evaluate the application health at layer seven—in addition to just testing for a successful network connection, they can make an application layer request to the application to ensure that it's functioning correctly.

Application load balancers also have the concept of rules, which direct connections arriving at a listener—so if you make a connection to a load balancer, what it does with that connection is determined by rules, which are processed in priority order. You can have many rules affecting a given set of traffic, and they’re processed in priority order, with the last one being the default catch-all rule, though you can add additional rules, each of which can have conditions.

Conditions inside rules include checking host headers, HTTP headers, HTTP request methods, path patterns, query strings, and even source IP, meaning these rules can take different actions depending on the domain name requested (like categor.io or dogogram.io), the path (such as images or API), the query string, or even the source IP address of any customers connecting to that application load balancer.

Rules can also have actions—these are the things the rules do with traffic: they can forward that traffic to a target group, redirect it to something else (maybe another domain name), provide a fixed HTTP response (like an error or success code), or perform authentication using OpenID or Cognito.

Visually, this is how it looks: a simple application load balancer deployment with a single domain, categor.io, using one host-based rule with an attached SSL certificate. The rule uses host header as a condition and forward as an action, forwarding any connections for categor.io to the target group for the categor application.

If you want additional functionality, let’s say that you want to use the same application load balancer for a corporate client trying to access categor.io—maybe users of Bowtie Incorporated using the 1.3.3.7 IP address are attempting to access it, and you want to present them with an alternative version of the application. You can handle that by defining a listener rule where the condition is the source IP address of 1.3.3.7, and the action forwards traffic to a separate target group—an auto scaling group handling a second set of instances dedicated to this corporate client.

Because the application load balancer is a layer seven device, it can see inside the HTTP protocol and make decisions based on anything in that protocol or up to layer seven. Also, the connection from the load balancer to the instances for target group two will be a separate set of connections—highlighted by a slightly different color—because HTTP connections from enterprise users are terminated on the load balancer, with a separate connection to the application instances. There’s no option to pass through encrypted connections to the instances—it must be terminated—so if you need unbroken encrypted connections, you must use a network load balancer.

Since it’s a layer seven load balancer, you can use rules that work on layer seven protocol elements, like routing based on paths or headers, or redirecting traffic at the HTTP level. For example, if this ALB also handles traffic for dogogram.io, you could define a rule that matches dogogram.io and, as an action, configure a redirect toward categor.io—the obviously superior website. These are just a small subset of features available within the application load balancer, and because it's layer seven, you can perform routing decisions based on anything observable at that level, making it a really flexible product.

Before finishing, let’s take a look at network load balancers. They function at layer four, meaning they can interpret TCP, TLS, and UDP protocols, but have no visibility or understanding of HTTP or HTTPS. They can't interpret headers, see cookies, or handle session stickiness from an HTTP perspective, as that requires cookie awareness—which a layer four device doesn’t have.

Network load balancers are incredibly fast, capable of handling millions of requests per second with about 25% of the latency of application load balancers, since they don't deal with upper layers of the stack. They’re ideal for non-HTTP or HTTPS protocols—such as SMTP (email), SSH, game servers, or financial applications that don’t use web protocols.

If exam questions refer to non-web or non-secure web traffic that doesn’t use HTTP/HTTPS, default to network load balancers. One downside is that health checks only verify ICMP and basic TCP handshaking, not application awareness, so no detailed health checking is possible.

A key benefit is that they can be allocated static IPs, which is useful for white-listing—corporate clients can white-list NLB IPs to let them pass through firewalls, which is great for strict security environments. They can also forward TCP directly to instances, and because network layers build on top of each other, the network load balancer doesn’t interrupt any layers above TCP, allowing unbroken encrypted channels from clients to application instances.

This is essential to remember for the exam—using network load balancers with TCP listeners is how you achieve end-to-end encryption. They're also used for PrivateLink to provide services to other VPCs—another crucial exam point.

To wrap up, let’s do a quick comparison. I find it easier to remember when to use a network load balancer, and if it’s not one of those cases, default to application load balancers for their added flexibility. Use network load balancers if you need unbroken encryption between client and instance, static IPs for white-listing, the best performance (millions of RPS and low latency), non-HTTP/HTTPS protocols, or PrivateLink.

For everything else, use application load balancers—their functionality is often valuable in most scenarios. That’s everything I wanted to cover about application and network load balancers for the exam. Go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back. This is part two of this lesson, and we're going to continue immediately from the end of part one, so let's get started.

This time, we have a typical multi-tiered application. We start with a VPC and inside that two availability zones. On the left, we also have an Internet Facing Low Balancer. Then we have a Web Instance Auto Scaling Group providing the front-end capability of the application. Then we have another Low Balancer, this time an internal Low Balancer, with only private IP addresses allocated to the nodes. Next, we have an Auto Scaling Group for the application instances. These are used by the web servers for the application. Then on the right, we have a pair of database instances. In this case, let's assume they're both Aurora database instances. So we have three tiers, Web, Application and Database.

Now, without Load Balancers, everything would be tied to everything else. Our user, Bob, would have to communicate with a specific instance in the web tier; if this failed or scaled, then Bob's experience would be disrupted. The instance that Bob is connected to would itself connect to a specific instance in the application tier, and if that instance failed or scaled, then again, Bob's experience would be disrupted.

What we can do to improve this architecture is to put Load Balancers between the application tiers to abstract one tier from another. And how this changes things is that Bob actually communicates with an ELB node, and this ELB node sends this connection through to a particular web server. But Bob has no knowledge of which web server he's actually connected to because he's communicating via a Load Balancer. If instances are added or removed, then he would be unaware of this fact because he's abstracted away from the physical infrastructure by the Load Balancer.

Now, the web instance that Bob is using would need to communicate with an instance of the application tier, and it would do this via an internal Load Balancer. And again, this represents an abstraction of communication. So in this case, the web instance that Bob is connected to isn't aware of the physical deployment of the application tier; it's not aware of how many instances exist, nor which one it's actually communicating with. And then at this point, to complete this architecture, the application server that's being used would use the database tier for any persistent data storage needs.

Now, without using Load Balancers with this architecture, all the tiers are tightly coupled together. They need an awareness of each other. Bob would be connecting to a specific instance in the web tier; this would be connecting to a specific instance in the application tier, and all of these tiers would need to have an awareness of each other. Load Balancers remove some of this coupling; they loosen the coupling. And this allows the tiers to operate independently of each other because of this abstraction. Crucially, it allows the tiers to scale independently of each other.

In this case, for example, it means that if the load on the application tier increased beyond the ability of two instances to service that load, then the application tier could grow independently of anything else—in this case scaling from two to four instances. The web tier could continue using it with no disruption or reconfiguration because it's abstracted away from the physical layout of this tier, because it's communicating via a Load Balancer. It has no awareness of what's happening within the application tier.

Now, we're going to talk about these architectural implications in depth later on in this section of the course. But for now, I want you to be aware of the architectural fundamentals. And one other fundamental that I want you to be completely comfortable with is cross zone load balancing, and this is a really essential feature to understand.

So let's look at an example visually: Bob accessing a WordPress blog, in this case, The Best Cats. And we can assume because this is a really popular and well-architected application that it's going to be using a load balancer. So Bob uses his device and browsers to the DNS name for the application, which is actually the DNS name of the load balancer.

We know now that a load balancer by default has at least one node per availability zone that it's configured for. So in this example, we have a cut down version of the Animals for Life VPC, which is using two availability zones. So in this case, an application load balancer will have a minimum of two nodes, one in each availability zone. And the DNS name for the load balancer will direct any incoming requests equally across all of the nodes of the load balancer.

So in this example, we have two nodes, one in each availability zone. Each of these nodes will receive a portion of incoming requests based on how many nodes there are. For two nodes, it means that each node gets 100% divided by two, which represents 50% of the load that's directed at each of the load balancer nodes.

Now, this is a simple example. In production situations, you might have more availability zones being used, and at higher volume, so higher throughput, you might have more nodes in each availability zone. But this example keeps things simple. So however much incoming load is directed at the load balancer DNS name, each of the load balancer nodes will receive 50% of that load.

Now, originally load balancers were restricted in terms of how they could distribute the connections that they received. Initially, the way that it worked is that each load balancer node could only distribute connections to instances within the same availability zone.

Now, this might sound logical, but consider this architecture where we have four instances in availability zone A and one instance in availability zone B. This would mean that the load balancer node in availability zone A would split its incoming connections across all instances in that availability zone, which is four ways. And the node in availability zone B would also split its connections up between all the instances in the same availability zone. But because there's only one, that would mean 100% of its connections to the single EC2 instance.

Now, with this historic limitation, it means that node A would get 50% of the overall connections and would further split this down four ways, which means each instance would be allocated 12.5% of the overall load. Node B would also receive 50% of the overall load, and normally it would split that down across all instances also in that same availability zone. But because there's only one, that one instance would get 100% of that 50%. So all of the instances in availability zone A would receive 12.5% of the overall load, and the instance in availability zone B would receive 50% of the overall load.

So this represents a substantially uneven distribution of the incoming load because of this historic limitation of how load balancer nodes could distribute traffic. And the fix for that was a feature known as cross zone load balancing.

Now, the name gives away what this does. It simply allows every load balancer node to distribute any connections that it receives equally across all registered instances in all availability zones. So in this case, it would mean that the node in availability zone A could distribute connections to the instance in AZB, and the node in AZB could distribute connections to instances in AZA. And this represents a much more even distribution of incoming load. And this is known as cross zone load balancing, the ability to distribute or load balance across availability zones.

Now, this is a feature which originally was not enabled by default. But if you're deploying an application load balancer, this comes enabled as standard. But you still need to be aware of it for the exam because it's often posed as a question where you have a problem—an uneven distribution of load—and you need to fix it by knowing that this feature exists. So it's really important that you understand it for the exam.

So before we finish up with this lesson, I just want to reconfirm the most important architectural points about elastic load balancers. If there are only a few things that you take away from this lesson, these are the really important points.

Firstly, when you provision an elastic load balancer, you see it as one device which runs in two or more availability zones, specifically one subnet in each of those availability zones. But what you're actually creating is one elastic load balancer node in one subnet in each availability zone that that load balancer is configured in. You're also creating a DNS record for that load balancer which spreads the incoming requests over all of the active nodes for that load balancer. Now you start with a certain number of nodes, let's say one node per availability zone, but it will scale automatically if additional load is placed on that load balancer.

Remember by default, cross-own load balancing means that nodes can distribute requests across to other availability zones, but historically this was disabled, meaning connections potentially would be relatively imbalanced. But for application load balancers, cross-own load balancing is enabled by default.

Now load balancers come in two types. Internet facing, which just means that the nodes are allocated with public IP version 4 addresses. That's it. It doesn't change where the load balancer is placed, it just influences the IP addressing for the nodes of that load balancer. Internal load balancers are the same, only their nodes are only allocated private IP addresses.

Now one of the most important things to remember about load balancers is that an internet facing load balancer can communicate with public instances or private instances. EC2 instances don't need public IP addressing to work with an internet facing load balancer. An internet facing load balancer has public IP addresses on its nodes, it can accept connections from the public internet and balance these across both public and private EC2 instances. That's really important to understand for the exam, so you don't actually need public instances to utilize an internet facing load balancer.

Now load balancers are configured via listener configuration, which as the name suggests controls what those load balancers listen to. And again, I'll be covering this in much more detail later on in this section of the course.

And then lastly, remember the confusing part about load balancers: they require eight or more free IP addresses per subnet that they get deployed into. Strictly speaking, this means that a /28 subnet would be enough, but the AWS documentation suggests a /27 in order to allow scaling.

For now, that's everything that I wanted to cover, so go ahead and complete this lesson. And then when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this lesson, I want to talk about the architecture of elastic load balancers. Now I'm going to be covering load balancers extensively in this part of the course, so I want to use this lesson as a sort of foundation. I'm going to cover the high level logical and physical architecture of the product and either refresh your memory on some things or introduce some of the finer points of load balancing for the first time, and both of these are fine.

Now, before we start, it's the job of a load balancer to accept connections from customers and then to distribute those connections across any registered backend compute; it means that the user is abstracted away from the physical infrastructure, and it means that the amount of infrastructure can change, so increase or decrease in number without affecting customers. And because the physical infrastructure is abstracted, it means that infrastructure can fail and be repaired, all of which is hidden from customers.

So with that quick refresher done, let's jump in and get started covering the architecture of elastic load balancers. Now I'm going to be stepping through some of the key architectural points visually, so let's start off with a VPC, which uses two availability zones, AZA and AZB, and then in those availability zones, we've got a few subnets, two public and some private. Now let's add a user, Bob, together with a pair of load balancers.

Now, as I just mentioned, it's the job of a load balancer to accept connections from a user base and then distribute those connections to backend services; for this example, we're going to assume that those services are long running compute or EC2, but as you'll see later in this section, that doesn't have to be the case, as elastic load balancers, specifically application load balancers, support many different types of compute services—it's not only EC2.

Now, when you provision a load balancer, you have to decide on a few important configuration items: the first, you need to pick whether you want to use IP version four only or dual stack, and dual stack just means using IP version four and the newer IP version six. You also need to pick the availability zones which the load balancer will use; specifically, you're picking one subnet in two or more availability zones.

Now, this is really important because this leads in to the architecture of elastic load balancers, so how they actually work; based on the subnets that you pick inside availability zones, when you provision a load balancer, the product places into these subnets one or more load balancer nodes. So what you see as a single load balancer object is actually made up of multiple nodes, and these nodes live within the subnets that you pick.

So when you're provisioning a load balancer, you need to select which availability zones it goes into, and the way you do this is by picking one and one only subnet in each of those availability zones. So in the example that's on screen now, I've picked to use the public subnet in availability zone A and availability zone B, and so the product has deployed one or more load balancer nodes into each of those subnets.

Now when a load balancer is created, it actually gets created with a single DNS record; it's an A record, and this A record actually points at all of the elastic load balancer nodes that get created with the product. So any connections that are made using the DNS name of the load balancer are actually made to the nodes of that load balancer, and the DNS name resolves to all of the individual nodes.

It means that any incoming requests are distributed equally across all of the nodes of the load balancer, and these nodes are located in multiple availability zones and they scale within that availability zone, and so they're highly available. If one node fails, it's replaced; if the incoming load to the load balancer increases, then additional nodes are provisioned inside each of the subnets that the load balancer is configured to use.

Now another choice that you need to make when creating a load balancer, and this is really important for the exam, is to decide whether that load balancer should be internet facing or whether it should be internal; this choice, so whether to use internet facing or internal, controls the IP addressing for the load balancer nodes. If you pick internet facing, then the nodes of that load balancer are given public addresses and private addresses; if you pick internal, then the nodes only have private IP addresses.

So that's the only difference; otherwise, they're the same architecturally—they have the same nodes and the same load balancer features, and the only difference between internet facing and internal is whether the nodes are allocated public IP addresses. Now the connections from our customers which arrive at the load balancer nodes, the configuration of how that's handled is done using a listener configuration; as the name suggests, this configuration controls what the load balancer is listening to—so what protocols and ports will be accepted at the listener or front side of the load balancer?

Now there's a dedicated lesson coming up later in this section which focuses specifically on the listener configuration; at this point, I just wanted to introduce it. So at this point, Bob has initiated connections to the DNS name associated with the load balancer, and that means that he's made connections to load balancer nodes within our architecture.

Now at this point, the load balancer nodes can then make connections to instances that are registered with this load balancer, and the load balancer doesn't care about whether those instances are public EC2 instances—so allocated with a public IP address—or they're private EC2 instances—so instances which reside in a private subnet and only have private addressing.

I want to keep reiterating this because it's often a point of confusion for students who are new to load balancers: an internet-facing load balancer—and remember this means that it has nodes that have public addresses so it can be connected to from the public internet—can connect both to public and private EC2 instances. Instances that are used do not have to be public.

Now this matters because in the exam, when you face certain questions which talk about how many subnets or how many tiers are required for an application, it does test your knowledge that an internet-facing load balancer does not need private or public instances—it can work with both of those. The only requirement is that load balancer nodes can communicate with the back-end instances, and this can happen whether the instances have allocated public addressing or whether they're private only instances.

The important thing is that if you want a load balancer to be reachable from the public internet, it has to be an internet-facing load balancer because logically it needs to be allocated with public addressing. Now load balancers in order to function need eight or more free IP addresses in the subnets that they're deployed into; now strictly speaking, this means a /28 subnet, which provides a total of 16 IP addresses, but minus the five reserved by AWS, this leaves 11 free per subnet.

But AWS suggests that you use a /27 or larger subnet to deploy an elastic load balancer in order that it can scale. Keep in mind that strictly speaking, both a /28 and /27 subnets are both correct in their own ways to represent the minimum subnet size for a load balancer; AWS do suggest in their documentation that you need a /27, but they also say you need a minimum of eight free IP addresses.

Now logically, a /28, which leaves 11 free, won't give you the room to deploy a load balancer and back end instances, so in most cases, I try to remember /27 as the correct value for the minimum for a load balancer. But if you do see any questions which show a /28 and don't show a /27, then /28 is probably the right answer.

Now internal load balancers are architecturally just like internet facing load balancers, except they only have private IPs allocated to their nodes, and so internal load balancers are generally used to separate different tiers of applications. So in this example, our user Bob connects via the internet facing load balancer to the web server, and then this web server can connect to an application server via an internal load balancer, and this allows us to separate application tiers and allow for independent scaling.

So let's look at this visually. Okay, so this is the end of part one of this lesson; it was getting a little bit on the long side and I wanted to give you the opportunity to take a small break, maybe stretch your legs or make a coffee. Now part two will continue immediately from this point, so go ahead, complete this video, and when you're ready, I'll look forward to you joining me in part two.

Welcome back and in this lesson I want to spend a few minutes just covering the evolution at the Elastic Load Balancer product; it's important for the exam and real world usage that you understand its heritage and its current state. Now this is going to be a super quick lesson because most of the detail I'm going to be covering in dedicated lessons which are coming up next in this section of the course, so let's jump in and take a look.

Now there are currently three different types of Elastic Load Balancers available within AWS; if you see the term ELB or Elastic Load Balancers then it refers to the whole family, all three of them. Now the load balancers are split between version 1 and version 2; you should avoid using the version 1 load balancer at this point and aim to migrate off them onto version 2 products which should be preferred for any new deployments, and there are no scenarios at this point where you would choose to use a version 1 load balancer versus one of the version 2 types.

Now the load balancer product started with the classic load balancer known as CLB which is the only version 1 load balancer and this was introduced in 2009, so it's one of the older AWS products. Now classic load balancers can load balance HTTP and HTTPS as well as lower level protocols but they aren't really layer 7 devices, they don't really understand HTTP and they can't make decisions based on HTTP protocol features; they lack much of the advanced functionality of the version 2 load balancers and they can be significantly more expensive to use.

One common limitation is that classic load balancers only support one SSL certificate per load balancer which means for larger deployments you might need hundreds or thousands of classic load balancers and these could be consolidated down to a single version 2 load balancer, so I can't stress this enough for any questions or any real world situations you should default to not using classic load balancers.

Now this brings me on to the new version 2 load balancers; the first is the application load balancer or ALB and these are truly layer 7 devices so application layer devices, they support HTTP, HTTPS and the web socket protocols, and they're generally the type of load balancer that you'd pick for any scenarios which use any of these protocols.

There's also network load balancers or NLBs which are also version 2 devices but these support TCP, TLS which is a secure form of TCP and UDP protocols, so network load balancers are the type of load balancer that you would pick for any applications which don't use HTTP or HTTPS; for example if you wanted to load balance email servers or SSH servers or a game which used a custom protocol so didn't use HTTP or HTTPS then you would use a network load balancer.

In general version 2 load balancers are faster and support target groups and rules which allow you to use a single load balancer for multiple things or handle the load balancing different based on which customers are using it. Now I'm going to be covering the capabilities of each of the version 2 load balancers separately as well as talking about rules but I wanted to introduce them now as a feature.

Now for the exam you really need to be able to pick between network load balancers or application load balancers for a specific situation so that's what I want to work on over the coming lessons; for now though this has just been an introduction lesson that talks about the evolution of these products and that's everything that I wanted to cover in this lesson, so go ahead complete lesson and when you're ready I'll look forward to you joining me in the next.

Welcome back. In this lesson, I want to talk about the regional and global AWS architecture, so let's jump in and get started. Now throughout this lesson, I want you to think about an application that you're familiar with, which is global, and for this example, I'll be talking about Netflix, because this is an application that most people have at least heard of. Now, Netflix can be thought of as a global application, but it's also a collection of smaller regional applications which make up the Netflix global platform, so these are discrete blocks of infrastructure which operate independently and are duplicated across different regions around the world.

As a solutions architect, when we're designing solutions, I find that there are three main types of architectures: small scale architectures which will only ever exist in one region or one country, then systems which also exist in one region or country but where there's a DR requirement so if that region fails for some reason, then it fails over to a second region, and then lastly, systems that operate within multiple regions and need to operate through failure in one or more of those regions.

Now, depending on how you architect systems, there are a few major architectural components which will map onto AWS products and services, so at a global level, first we have global service location and discovery—when you type Netflix.com into your browser, what happens and how does your machine discover where to point at?

Next, we've got content delivery—how does the content or data for an application get to users globally, and are there pockets of storage distributed globally or is it pulled from a central location?

Lastly, we've got global health checks and failover—detecting if infrastructure in one location is healthy or not and moving customers to another country as required, so these are the global components.

Next, we have regional components starting with the regional entry point, then we have regional scaling and regional resilience and then the various application services and components, so as we go through the rest of the course, we're going to be looking at specific architectures and as we do, I want you to think about them in terms of global and regional components— which parts can be used for global resilience and which parts are local only.

So let's take a look at this visually starting with the global elements, and let's keep using Netflix as an example and say that we have a group of users who are starting to settle down for the evening and want to watch the latest episode of Ozarks, so the Netflix client will use DNS for the initial service discovery, and Netflix will have configured the DNS to point at one or more service endpoints.

Let's keep things simple at this point and assume that there is a primary location for Netflix in a US region of AWS, maybe US East One, and this will be used as the primary location and if this fails, then Australia will be used as a secondary. Now, another valid configuration would be to send customers to their nearest location—in this case, sending our TV fans to Australia—but in this case, let's just assume we have a primary and a secondary region.

So this is the DNS component of this architecture and Route 53 is the implementation within AWS, and because of its flexibility, it can be configured to work in any number of ways. The key thing for this global architecture, though, is that it has health checks, so it can determine if the US region is healthy and direct all sessions to the US while this is the case or direct sessions to Australia if there are problems with the primary region.

Now regardless of where infrastructure is located, a content delivery network can be used at the global level, and this ensures that content is cached locally as close to customers as possible, and these cache locations are located globally and they all pull content from the origin location as required.

So just to pause here briefly, this is a global perspective—the function of the architecture at this level is to get customers through to a suitable infrastructure location, making sure any regional failures are isolated and sessions moved to alternative regions, and it attempts to direct customers at a local region, at least if the business has multiple locations, and lastly, it attempts to improve caching using a content delivery network such as CloudFront.

If this part of our architecture works well, customers will be directed towards a region that has infrastructure for our application, and let's assume this region is one of the US ones. At this point, the traffic is entering one specific region of the AWS infrastructure, and depending on the architecture, this might be entering into a VPC or using public space AWS services, but in either case, now we're architecturally zoomed in, and so we have to think about this architecture now in a regional sense.

The most effective way to think about systems architecture is a collection of regions making up a whole—if you think about AWS products and services, very few of them are actually global, most of them run in a region, and many of those regions make up AWS.

Now it's efficient to think in this way, and it makes designing a large platform much easier. For the remainder of this course, we're going to be covering architecture in depth—how things work, how things integrate, and what features products provide.

Now the environments that you will design will generally have different tiers, and tiers in this context are high level groupings of functionality or different zones of your application.

Initially, communications from your customers will generally enter at the web tier—generally this will be a regional based AWS service such as an application load balancer or API gateway, depending on the architecture that the application uses.

The purpose of the web tier is to act as an entry point for your regional based applications or application components, and it abstracts your customers away from the underlying infrastructure, meaning that the infrastructure behind it can scale or fail or change without impacting customers.

Now the functionality provided to the customer via the web tier is provided by the compute tier, using services such as EC2, Lambda, or containers which use the elastic container service, so in this example, the load balancer will use EC2 to provide compute services through to our customers.

Now we'll talk throughout the course about the various different types of compute services which you can and should use for a given situation, but the compute tier though will consume storage services, another part of all AWS architectures, and this tier will use services such as EBS, which is the elastic block store, EFS, which is the elastic file system, and even S3 for things like media storage.

You'll also find that many global architectures utilize CloudFront, the global content delivery network within AWS, and CloudFront is capable of using S3 as an origin for media, so Netflix might store movies and TV shows on S3 and these will be cached by CloudFront.

Now all of these tiers are separate components of an application and can consume services from each other, and so CloudFront can directly access S3 in this case to fetch content for delivery to a global audience.

Now in addition to file storage, most environments require data storage and within AWS this is delivered using products like RDS, Aurora, DynamoDB and Redshift for data warehousing, but in order to improve performance, most applications don't directly access the database—instead, they go via a caching layer, so products like ElastiCache for general caching or DynamoDB Accelerator known as DAX when using DynamoDB.

This way, reads to the database can be minimized, and applications will instead consult the cache first and only if the data isn't present in the cache will the database be consulted and the contents of the cache updated.

Now caching is generally in memory, so it's cheap and fast—databases tend to be expensive based on the volume of data required versus cache and normal data storage, so where possible, you need to offload reads from the database into the caching layer to improve performance and reduce costs.

Now lastly, AWS have a suite of products designed specifically to provide application services—so things like Kinesis, Step Functions, SQS and SNS, all of which provide some type of functionality to applications, either simple functionality like email or notifications, or functionality which can change an application's architecture such as when you decouple components using queues.

Now as I mentioned at the start of this lesson, you're going to be learning about all of these components and how you can use them together to build platforms. For now, just think of this as an introduction lesson—I want you to get used to thinking of architectures from a global and regional perspective as well as understanding that application architecture is generally built using components from all of these different tiers: the web tier, the compute tier, caching, storage, the database tier and application services.

Now at this point, that's all of the theory that I wanted to go through—remember, this is just an introduction lesson, so go ahead, finish this lesson and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this video, I want to talk at a high level about the AWS Backup product. Now, this is something that you need to have an awareness of for most of the AWS exams and to get started in the real world, but it's not something that you need to understand in depth for all of the AWS certifications. So let's jump in and cover the important points of the product.

So AWS Backup is a fully managed data protection service. At this level of study, you can think about it as a backup and restore product, but it also includes much more in the way of auditing and management oversight. The product allows you to consolidate the management and storage of your backups in one place, across multiple accounts and multiple regions if you configure it that way, so that's important to understand the product is capable of being configured to operate across multiple accounts. So this utilizes services like Control Tower and organizations to allow this, and it's also capable of copying data between regions to provide extra data protection. But the main day-to-day benefit that the product provides is this consolidation of management and storage within one place, so instead of having to configure backups of RDS in one place, DynamoDB in another, and organize some kind of script to take regular EBS snapshots, AWS Backup can do all this on your behalf.

Now, AWS Backup is capable of interacting with a wide range of AWS products, so many AWS services are fully supported—various compute services, so EC2 and VMware running within AWS, block storage such as EBS, file storage products such as EFS and the various different types of FSX, and then most of the AWS database products are supported such as Aurora, RDS, Neptune, DynamoDB and DocumentDB—and then even object storage is supported using S3. Now, all of these products can be centrally managed by AWS Backup, which means both the storage and the configuration of how the backup and retention operates.

Now, let's step through some of the key concepts and components of the AWS Backup product. First, we have one of the central components, and that's backup plans; it's on these where you can configure the frequency of backups, so how often backups are going to occur every hour, every 12 hours, daily, weekly or monthly. You can also use a cron expression that creates snapshots as frequently as hourly. Now, if you have any business backup experience, you might recognize this—if you select weekly, you can specify which days of the week you want backups to be taken, and if you specify monthly, you can choose a specific day of the month.

Now, you can also enable continuous backups for certain supported products, and this allows you to use a point-in-time restore feature, so if you've enabled continuous backups, then you can restore a supported service to a particular point in time within a window. Now, you can configure the backup window as well within backup plans, so this controls the time that backups begin and the duration of that backup window. You can configure life cycles, which define when a backup is transitioned to cold storage and when it expires—when you transition a backup into cold storage, it needs to be stored there for a minimum of 90 days.

Backup plans also set the vault to use—and more on this in a second—and they allow you to configure region copy, so you can copy backups from one region to another. Next, we have backup resources, and these are logically what is being backed up—so whether you want to back up an S3 bucket or an RDS database, that's what a resource is, what resources you want to back up.

Next, we have vaults, and you can think of vaults as the destination for backups; it's here where all the backup data is stored, and you need to configure at least one of these. Now, vaults by default are read and write, meaning that backups can be deleted, but you can also enable AWS backup vault lock—and this is not to be confused by Glacier or object locking. AWS backup vault lock enables a write once read many, known as WORM mode, for the vault—once enabled, you get a 72-hour cool-off period, but once fully active, nobody, including AWS, can delete anything from the vault, and this is designed for compliance-style situations.

Now, any data retention periods that you set still apply, so backups can age out, but setting this means that it's not possible to bypass or delete anything early, and the product is also capable of performing on-demand backups as required, so you're not limited to only using backup plans. Some services also support a point-in-time recovery method, and examples of this include S3 and RDS, and this means that you can restore to the state of that resource at a specific date and time within the retention window.

Now, with all of these features, the product is constantly evolving, and rather than have this video be out of date the second something changes, I've attached a few links which detail the current state of many of these features, and I'd encourage you to take a look when you want to understand the product's up-to-date capabilities when you're watching this video.

Now, this is all you need to understand as a base foundation for AWS Backup for all of the AWS exams. If you need additional knowledge—so more theory detail in general, perhaps more specialized deep-dive knowledge on the security elements of the product, or maybe some practical knowledge—then there will be additional videos. These will only be present if you need this additional knowledge for the particular course that you're studying—if you only see this video, don't worry, it just means that this is all you need to know.

At this point, though, that is everything I wanted to cover, so 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'm going to be covering a really useful product within AWS, the Elastic File System, or EFS. It's a product which can prove useful for most AWS projects because it provides network-based file systems which can be mounted within Linux EC2 instances and used by multiple instances at once. For the Animals for Life WordPress example that we've been using throughout the course so far, it will allow us to store the media for posts outside of the individual EC2 instances, which means that the media isn't lost when instances are added and removed, and that provides significant benefits in terms of scaling as well as self-healing architecture. In summary, we're moving the EC2 instances to a point where they're closer to being stateless.

So let's jump in and step through the EFS architecture. The EFS service is an AWS implementation of a fairly common shared storage standard called NFS, the Network File System, specifically version 4 of the Network File System. With EFS, you create file systems which are the base entity of the product, and these file systems can be mounted within EC2 Linux instances. Linux uses a tree structure for its file system; devices can be mounted into folders in that hierarchy, and EFS file system, for example, could be mounted into a folder called forward slash NFS forward slash media. What's more impressive is that EFS file systems can be mounted on many EC2 instances, so the data on those file systems can be shared between lots of EC2 instances.

Now keep this in mind as we talk about evolving the architecture of the Animals for Life WordPress platform. Remember, it has a limitation that the media for posts, so images, movies, audio, they're all stored on the local instance itself; if the instance is lost, the media is also lost. EFS storage exists separately from an EC2 instance, just like EBS exists separately from EC2. Now EBS is block storage, whereas EFS is file storage, but Linux instances can mount EFS file systems as though they are connected directly to the instance.

EFS is a private service by default; it's isolated to the VPC that it's provisioned into. Architecturally, access to EFS file systems is via mount targets, which are things inside a VPC, but more on this next when we step through the architecture visually. Now even though EFS is a private service, you can access EFS file systems via hybrid networking methods that we haven't covered yet, so if your VPC is connected to other networks, then EFS can be accessed over those, using VPC peering, VPN connections, or AWS Direct Connect, which is a physical private networking connection between a VPC and your existing on-premises networks. Now don't worry about those hybrid products, I'll be covering all of them in detail later in the course.

For now though, just understand that EFS is accessible outside of a VPC using these hybrid networking products as long as you configure this access. So let's look at the architecture of EFS visually. Architecturally, this is how it looks: EFS runs inside a VPC, in this case the Animals for Life VPC. Inside EFS, you create file systems and these use POSIX permissions. If you don't know what this is, I've included a link attached to the lesson which provides more information. Super summarized though, it's a standard for interoperability which is used in Linux, so a POSIX permissions file system is something that all Linux distributions will understand.

Now the EFS file system is made available inside a VPC via mount targets and these run from subnets inside the VPC. The mount targets have IP addresses taken from the IP address range of the subnet that they're inside, and to ensure high availability, you need to make sure that you put mount targets in multiple availability zones, just like NAT gateways for a fully highly available system; you need to have a mount target in every availability zone that a VPC uses. Now it's these mount targets that instances use to connect to the EFS file systems.

Now it's also possible, as I touched on on the previous screen, that you might have an on-premises network and this generally would be connected to a VPC using hybrid networking products such as VPNs or Direct Connect, and any Linux-based server that's running on this on-premises environment can use this hybrid networking to connect through to the same mount targets and access EFS file systems.

Now before we move on to a demo where you'll get the practical experience of creating a file system and accessing it from multiple EC2 instances, there are a few things about EFS which you should know for the exam. First, EFS is for Linux-only instances; from an official AWS perspective, it's only officially supported using Linux instances. EFS offers two performance modes, general purpose and max IO. General purpose is ideal for latency-sensitive use cases, web servers, content management systems, it can be used for home directories or even general file serving as long as you're using Linux instances. Now general purpose is the default and that's what we'll be using in this section of the course within the demos.

Max IO can scale to higher levels of aggregate throughput and operations per second but it does have a trade-off of increased latencies, so max IO mode suits applications that are highly parallel; so if you've got any applications or any generic workloads such as big data, media processing, scientific analysis, anything that's highly parallel, then it can benefit from using max IO — but for most use cases just go with general purpose.

There are also two different throughput modes, bursting and provisioned. Bursting mode works like GP2 volumes inside EBS so it has a burst pool, but the throughput of this type scales with the size of the file systems, so the more data you store in the file system the better performance that you get. With provisioned, you can specify throughput requirements separately from size, so this is like the comparison between GP2 and IO1; with provisioned, you can specify throughput requirements separate from the amount of data you store, so that's more flexible but it's not the thing that's used by default — generally you should pick bursting.

Now for the exam, you don't need to remember the raw numbers but I have linked some in the lesson description if you want additional information, so you can see the different performance characteristics of all of these different options.

Now Amazon EFS file systems have two storage classes available: we've got infrequent access or IA, and that storage class is a lower cost storage class which is designed for storing things that are infrequently accessed — so if you need to store data in a cost effective way but you don't intend to access it often, then you can use infrequent access. Next we've got standard, and the standard storage class is used to store frequently accessed files; it's also the default and you should consider it the default when picking between the different storage classes. Conceptually, these mirror the trade-offs of the S3 object storage classes — use standard for data which is used day to day and infrequent access for anything which isn't used on a consistent basis. And just like S3, you have the ability to use life cycle policies which can be used to move data between classes.

Okay, so that's the theory of EFS. It's not all that difficult a product to understand but you do need to understand it architecturally for the exam, and so to help with that it's now time for a demo. I want you to really understand how EFS works — it's something that you probably will use if you use AWS for any real world projects. Now the best way to understand it is to use it, and so that's what we're going to do in the next lesson which is a demo. You're going to have the opportunity to create an EFS file system, provision some EC2 instances, and then mount that file system within both EC2 instances, create a test file and see that that's accessible from both of those instances, proving that EFS is a shared network file system.

But at this point, that's all of the theory that I wanted to cover, so go ahead finish up this video and when you're ready I look forward to you joining me in the demo lesson.