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.

Welcome back, and in this lesson, I want to cover a service which starts to feature more and more on the exam: the database migration service known as DMS. Now, this lesson is an extension of my lesson from the Associate Architect course, so even if you've taken that course and watched that lesson, you should still watch this lesson fully. Now, this product is something which, as well as being on the exam, if you're working as a Solutions Architect in the AWS space and if your projects involve databases, you will extensively use this product. It's something that you need to be aware of regardless, so let's jump in and get started.

Database migrations are complex things to perform. Normally, if we exclude the vendor tooling which is available, it's a manual process end to end. It usually involves setting up replication, which is pretty complex, or it means taking a point-in-time backup and restoring this to the destination database. But how do you handle changes which occur between taking that backup and when the new database is live? How do you handle migrations between different databases? These are all things where DMS comes in handy. It's essentially a managed database migration service. The concept is simple enough: it starts with a replication instance, which runs on EC2. This instance runs one or more replication tasks. You need to define a source and destination endpoints, which point at the source and target databases, and the only real restriction with the service is that one of the endpoints must be running within AWS. You can't use the product for migrations between two on-premises databases. Now, you don't actually need to have any experience using the product, but there will be a demo lesson elsewhere in this section which gives you some practical exposure. For this theory lesson though, we need to focus on the architecture, so let's continue by reviewing that visually.

Using DMS is simple enough architecturally. You start with a source and target database, and one of those needs to be within AWS. The databases themselves can use a range of compatible engines, such as MySQL, Aurora, Microsoft SQL, MariaDB, MongoDB, PostgreSQL, Oracle, Azure SQL, and many more. Now, in between these, conceptually is the database migration service, known as DMS, which uses a replication instance—essentially an EC2 instance with migration software and the ability to communicate with the DMS service. Now on this instance, you can define replication tasks, and each of these replication instances can run multiple replication tasks. Tasks define all of the options relating to the migration, but architecturally, two of the most important things are the source and destination endpoints, which store the replication information so that the replication instance and task can access the source and target databases. So a task essentially moves data from the source database, using the details in the source endpoint, to the target database using the details stored in the destination endpoint configuration.

The value from DMS comes in how it handles those migrations. Now, jobs can be one of three types. We have full load migrations, and these are used to migrate existing data. So, if you can afford an outage long enough to copy your existing data, then this is a good one to choose. This option simply migrates the data from your source database to your target database, and it creates the tables as required. Next, we have full load plus CDC, and this stands for change data capture, and this migrates existing data and replicates any ongoing changes. This option performs a full load migration, and at the same time, it captures any changes occurring on the source. After the full load migration is complete, then captured changes are also applied to the target. Eventually, the application of changes reaches a steady state, and at this point, you can shut down your applications, let the remaining changes flow through to the target, and then restart your applications and point them at the new target database. Finally, we've got CDC only, and this is designed to replicate only data changes. In some situations, it might be more efficient to copy existing data using a method other than AWS DMS. Also, certain databases, such as Oracle, have their own export and import tools, and in these cases, it might be more efficient to use those tools to migrate the initial data and then use DMS simply to replicate the changes starting at the point when you do that initial bulk load. So, CDC only migrations are actually really effective if you need to bulk transfer the data in some way outside of DMS.

Now lastly, DMS doesn't natively support any form of schema conversion, but there is a dedicated tool in AWS, known as the schema conversion tool, or SCT, and the sole purpose of this tool is to perform schema modifications or schema conversions between different database versions or different database engines. So, this is a really powerful tool that often goes hand-in-hand with migrations which are being performed by DMS. Now, DMS is a great tool for migrating databases from on-premises to AWS. It's a tool that you will get to use for most larger database migrations, so as a solutions architect, it's another tool which you need to understand end-to-end in the exam. If you see any form of database migration scenario, as long as one of the databases is within AWS and as long as there are no weird databases involved which aren't supported by the product, then you can default to using DMS. It's always a safe default option for any database migration questions. If the question talks about a no-downtime migration, then you absolutely should default to DMS.

Now, at this point, let's talk in a little bit more detail about a few aspects of DMS which are important. First, I want to talk about the schema conversion tool, or SCT, in a little bit more detail. So, this is actually a standalone application, which is only used when converting from one database engine to another. It can be used as part of migrations where the engines being migrated from and to aren't compatible, and another use case is that it can be used for larger migrations when you need to have an alternative way of moving data between on-premises and AWS, rather than using a data link. Now, SCT is not used—and this is really important—it's not used for movements of data between compatible database engines. For example, if you're performing a migration from an on-premises MySQL server to an AWS-based RDS MySQL server, then the engines are the same. Even though the products are different, the engines are the same, and so SCT would not be used. SCT works with OLTP databases such as MySQL, Microsoft SQL, and Oracle, and also OLAP databases such as Teradata, Oracle, Vertica, and even Green Plum. Now, examples of the types of situations where the schema conversion tool would be used include things like on-premises Microsoft SQL through to AWS RDS MySQL migrations because the engine changes from Microsoft SQL to MySQL, and then we could also use SCT for an on-premises Oracle to AWS-based Aurora database migration, again because the engines are changing.

Now, there is another type of situation where DMS can be used in combination with SCT, and that's for larger migrations. So, DMS can often be involved with large-scale database migrations, so things which are multi-terabytes in size. And for those types of projects, it's often not optimal to transfer the data over the network. It takes time, and it consumes network capacity that might be used heavily for normal business operations. So, DMS is able to utilize the Snowball range of products which are available for bulk transfer of data into and out of AWS. So, you can use DMS in combination with Snowball, and this actually uses the schema conversion tool. So, this is how it works. So, step one, you use the schema conversion tool to extract the data from the database and store it locally and then move this data to a Snowball device which you've ordered from AWS. Step two is that you ship that device back to AWS, they load that data into an S3 bucket, and then DMS migrates from S3 into the target store. So, the target database, if you decide to use change data capture, then you can also migrate changes since the initial bulk transfer. These also use S3 as an intermediary before being written to the target database by DMS. So, DMS normally will transfer the data over the network; it can transfer over direct connect or a VPN or even a VPC peer. But if the data volumes that you're migrating are bigger than you can practically transfer over your network link, then you can order a Snowball and use DMS together with SCT to make that transfer much quicker and more effective.

Now, the rule to remember for the exam is that SCT is only used for migrations when the engine is changing, and the reason why SCT is used here is because you're actually migrating a database into a generic file format, which can be moved using Snowballs. And so, this doesn't break the rule of only doing it when the database engine changes because you are essentially changing the database. You're changing it from whatever engine the source uses, and you're storing it in a generic file format for transfer through to AWS on a Snowball device. Now, that's everything that I wanted to cover in this lesson, and this has been an extension of the coverage which I did at the Associate Architect level. You are going to get the chance to experience this product practically in a demo, but in this lesson, I just wanted to cover the theory. So, thanks for watching. Go ahead and complete this lesson, and when you're ready, I look forward to you joining me in the next.

Welcome back, and in this video, I want to talk about a feature of RDS called RDS proxy, which is something important to know in its own right but also supports many other architectures involving RDS. Now we've got a lot to cover, so let's jump in and get started. Before we talk about how RDS proxy works, let's step through why you might want to use the product. First, opening and closing connections to databases takes time and consumes resources, which is often the bulk of many smaller database operations. If you only want to read and write a tiny amount, the overhead of establishing a connection can be significant, and this can be especially obvious when using serverless because if you have a lot of lambda functions invoking or accessing an RDS database, for example, that's a lot of connections to constantly open and close, especially when you're only billed for the time that you're using compute, as with lambda.

Now, another important element is that handling failure of database instances is hard. How long should you wait for the connection to work? What should your application do while waiting? When should it consider it a failure? How should it react? And then how should it handle the failover to the standby instance in the case of RDS? Doing all of this within your application adds significant overhead and risk. A database proxy is something that can help, but maybe you don't have any database proxy experience, and even if you do, can you manage them at scale? Well, that's where RDS proxy adds value. At a high level, what RDS proxy does, or indeed any database proxy, is change your architecture. Instead of your application connecting to a database every time it needs to use it, instead, they connect to a proxy, and the proxy maintains a pool of connections to the database that are open for the long term. Then, any connections to the proxy can use this already established pool of database connections. It can actually do multiplexing, where it can maintain a smaller number of connections to a database versus the connections to the proxy, multiplexing requests over the connection pool between the proxy and the database, so you can have a smaller number of actual connections to the database versus the connections to the database proxy, and this is especially useful for smaller database instances where resources are at a premium.

So, in terms of how an architecture might look using RDS proxy, let's start with this: a VPC in US East One with three availability zones and three subnets in each of those availability zones. In AZB, we have a primary RDS instance replicating to a standby running in AZC. Then we have Categoram, our application, running in the web subnets in the middle here, and the application makes use of some lambda functions, which are configured to use VPC networking and run from the subnet in availability zone B, and so there's a lambda ENI in that subnet. Without RDS proxy, the Categoram application servers will be connecting directly to the database every time they need to access data, and additionally, every time one of those lambda functions is invoked, they would need to directly connect to the database, which would significantly increase their running time. With RDS proxy, though, things change. The proxy is a managed service, and it runs only from within a VPC, in this case, across all availability zones A, B, and C. Now, the proxy maintains a long-term connection pool, in this case, to the primary node of the database running in AZB. These connections are created and maintained over the long term, and they're not created and terminated based on individual application needs or lambda function invocations. Our clients, in this case, the Categoram EC2 instances and lambda functions, connect to the RDS proxy rather than directly to the database instances, and these connections are quick to establish and place no load on the database server because they're between the clients and the proxy.

Now, at this point, the connections between the RDS proxy and database instances can be reused, meaning that even if we have constant lambda function invocations, they can reuse the same set of long-running connections to the database instances. More so, multiplexing is used so that a smaller number of database connections can be used for a larger number of client connections, and this helps reduce the load placed on the database server even more. RDS proxy even helps with database failure or failover events because it abstracts these away from the application. The clients we have can connect to the RDS proxy instances and wait even if the connection to the backend database isn't operational, and this is a situation that might occur during failover events from the primary to the standby. In the event that there is a failure, the RDS proxy can establish new connections to the new primary in the background, and the clients stay connected to the same endpoint, the RDS proxy, and they just wait for this to occur.

So, that's a high-level example architecture. Let's look at when you might want to use RDS proxy, and this is more for the exam, but you need to have an appreciation for the types of scenarios where RDS proxy will be useful. You might decide to use it when you have errors such as too many connection errors, because RDS proxy helps reduce the number of connections to a database, and this is especially important if you're using smaller database instances such as T2 or T3, so anything small or anything burst-related. Additionally, it's useful when using AWS Lambda because you're not having the per-invocation database connection setup, usage, and termination. It can reuse a long-running pool of connections maintained by the RDS proxy, and it can also use existing IAM authentication, which the Lambda functions have access to via their execution role.

Now, RDS proxy is also useful for long-running applications such as SaaS apps where low latency is critical. So, rather than having to establish database connections every time a user interaction occurs, they can use this existing long-running connection pool. RDS proxy is also really useful where resilience to database failure is a priority. Remember, your clients connect to the proxy, and the proxy connects to the backend databases, so it can significantly reduce the time for a failover event and make it completely transparent to your application. This is a really important concept to grasp because your clients are connected to the single RDS proxy endpoint, even if a failover event happens in the background. Instead of having to wait for the database C name to move from the primary to the standby, your applications are transparently connected to the proxy, and they don't realize it's a proxy; they think they're connecting to a database. The proxy, though, is handling all of the interaction between them and the backend database instances.

Now, before we finish up, I want to cover some key facts about RDS proxy—think of these as the key things that you need to remember for the exam. RDS proxy is a fully managed database proxy that's usable with RDS and Aurora. It's auto-scaling and highly available by default, so you don't need to worry about it, and this represents a much lower admin overhead versus managing a database proxy yourself. Now, it provides connection pooling, which significantly reduces database load, and this is for two main reasons. Firstly, we don't have the constant opening and closing of database connections, which does put unnecessary stress on the database, but in addition, we can also multiplex to use a lower number of connections between the proxy and the database relative to the number of connections between the clients and the proxy, so this is really important.

Now, RDS proxy is only accessible from within a VPC, so you can't access this from the public internet; it needs to occur from a VPC or from private VPC-connected networks. Access to the RDS proxy uses a proxy endpoint, and this is just like a normal database endpoint; it's completely transparent to the application. An RDS proxy can also enforce SSL/TLS connections, so it can enforce these to ensure the security of your applications, and it can reduce failover time by over 60% in the case of Aurora. This is somewhere in the region of a 66 to 67% improvement versus connecting to Aurora directly. Critically, it abstracts the failure of a database away from your application, so the application connected to an RDS proxy will just wait until the proxy makes a connection to the other database instance. So, during a failover event, where we're failing over from the primary to the standby, the RDS proxy will wait until it can connect to the standby and then just continue fulfilling requests from client connections, and so it abstracts away from underlying database failure.

Now, at this point, that is everything I wanted to cover in this high-level lesson on RDS proxy, 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 an advanced feature of Amazon Aurora, multi-master rights. This feature allows an Aurora cluster to have multiple instances capable of performing both reads and writes, which is in contrast with the default mode for Aurora that only allows one writer and many readers. So let's get started and look at the architecture.

Just to refresh where we are, the default Aurora mode is known as single master, and this equates to one read-write instance, so one database instance that can perform read and write operations, and then in addition, it can also have zero or more read-only replicas. An Aurora cluster running in the default mode of single master has a number of endpoints which are used to interact with the database. We've got the cluster endpoint, which can be used for read or write operations, and then we've got another endpoint, a read endpoint, that's used for load balancing reads across any of the read-only replicas inside the cluster.

An important consideration with an Aurora cluster running in single master mode is that failover takes time. For a failover to occur, a replica needs to be promoted from read-only mode to read-write mode. In multi-master mode, all of the instances by default are capable of both read and write operations, so there isn't this concept of a lengthy failover if one of the instances fails in a multi-master cluster. At a high level, a multi-master Aurora cluster might seem similar to a single master one, with the same cluster structure, the same shared storage, and multiple Aurora provisioned instances existing in the cluster. The differences start with the fact that there is no cluster endpoint to use; an application is responsible for connecting to instances within the cluster. There's no load balancing across instances with a multi-master cluster; the application connects to one or all of the instances in the cluster and initiates operations directly.

So that's important to understand—there is no concept of a load-balanced endpoint for the cluster. An application can initiate connections to one or both of the instances inside a multi-master cluster. Now, the way that this architecture works is that when one of the read-write nodes inside a multi-master cluster receives a write request from the application, it immediately proposes that data be committed to all of the storage nodes in that cluster. It proposes that the data it receives to write is committed to storage. At this point, each node that makes up the cluster either confirms or rejects the proposed change. It rejects it if it conflicts with something that's already in flight, for example, another change from another application writing to another read-write instance inside the cluster.

What the writing instance is looking for is a quorum of nodes to agree, a quorum of nodes that allow it to write that data, at which point it can commit the change to the shared storage. If the quorum rejects it, then it cancels the change with the application and generates an error. Now, assuming that it can get a quorum to agree to the write, then that write is committed to storage and it's replicated across every storage node in the cluster just as it is with a single master cluster, but—and this is the major difference with a multi-master cluster—that change is then replicated to other nodes in the cluster. This means that those other writers can add the updated data into their in-memory caches, and this means that any reads from any other instances in the cluster will be consistent with the data that's stored on shared storage because instances' cached data needs to be updated inside any in-memory caches of any other instances within the multi-master cluster.

So that's what this replication does. Once the instance on the right has got agreement to commit that change to the cluster's shared storage, it replicates that change to the instance on the left, the instance on the left updates its in-memory cache, and then if that instance is used for any read operations, it's always got access to the up-to-date data.

Now, to understand some of the benefits of multi-master mode, let's look at a single master failover situation. In this scenario, we have an Aurora single master cluster with one primary instance performing reads and writes and one replica which is only performing read operations. Now, Bob is using an application, and this application connects to this Aurora cluster using the cluster endpoint. The cluster endpoint at this stage points to the primary instance, which is the one that's used for read and write operations and always points at the primary instance.

If the primary instance fails, then access to the cluster is interrupted, so immediately we know that this application cannot be fault-tolerant because access to the database is now disrupted. At this point, though, the cluster will realize that there is a failure event and it will change the cluster endpoint to point at the replica, which the cluster decides will be the new primary instance, but this failover process takes time. It's quicker than normal RDS because each replica shares the cluster storage and they can be more replicas, but it can take time. The configuration change to make one of the other replicas the new primary instance inside the cluster is not an immediate change—it causes disruption.

Now, let's contrast this with multi-master. With multi-master, both instances are able to write to the shared storage; they're both writers. The application can connect with one or both of them, and let's assume at this stage that it connects to both. Both instances are capable of read and write operations, the application could maintain connections to both, and be ready to act if one of them fails, but when that writer fails, it could immediately just send 100 percent of any future data operations to the writer which is working perfectly. There would be little if any disruption. If the application is designed in this way—it's designed to operate through this failure—the application could almost be described as fault-tolerant. So, an Aurora multi-master cluster is one component that is required in order to build a fault-tolerant application. It's not a guarantee, and it's not always a thousand percent fault-tolerant, but it is the foundation of being able to build a fault-tolerant application because the application can maintain connections to multiple writers at the same time.

In terms of the high-level benefits, it offers better and much faster availability. The failover events can be performed inside the application, and it doesn't even need to disrupt traffic between the application and the database because it can immediately start sending any write operations to another writer. It can be used to implement fault tolerance, but the application logic needs to manually load balance across the instances—it's not something that's handled by the cluster. With that being said, though, that's everything I wanted to cover in this lesson. It's not something I expect to immediately feature in detail on the exam, so we can keep it relatively brief. 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 quickly cover the Aurora Global Database Product, which allows you to create global level replication using Aurora from a master region to up to five secondary AWS regions. Now, the name probably gives away the function, but to avoid any confusion, global databases allow you to create global-level replication using Aurora from a master region to up to five secondary AWS regions. This is one of the things which you just need an awareness of for the exam; I don't expect it to feature heavily, but I want you to be aware of exactly what functionality Aurora Global Database provides.

So, to keep this lesson as brief as possible, let's quickly jump in and look at the architecture first. This is a common architecture that you might find when using Aurora Global Databases. We've got an environment here which operates from two or more regions. We've got a primary region, US East One on this example on the left. This primary region offers similar functionality to a normal Aurora cluster, with one read and write instance and up to 15 read-only replicas in that cluster.

Global databases introduce the concept of secondary regions, and the example that's on screen is AP Southeast 2, which is the Sydney region on the right of your screen, and these can have up to 16 replicas. The entire secondary cluster is read-only, so in this example, all 16 replicas would be read-only replicas. The entire secondary cluster during normal operations is read-only. Now, the replication from the primary region to secondary regions occurs at the storage layer, and replication is typically within one second from the primary to all of the secondaries. Applications can use the primary instance in the primary region for write operations and then the replicas in the primary or the replicas in the secondary regions for read operations.

So, that's the architecture, but what's perhaps more important for the exam is when you would use global databases. So let's have a look at that next. Aurora Global Databases are great for cross-region disaster recovery and business continuity. You can basically create a global database, set up multiple secondary regions, and then if you do have a disaster that affects an entire AWS region, you can make these secondary clusters act as primary clusters so they can do read-write operations. It offers a great solution for cross-region disaster recovery and business continuity, and because of the one-second replication time between the primary region and secondary regions, it makes sure that both the RPO and RTO values are really low.

If you do perform a cross-region failover, they're also great for global read scaling. So, if you want to offer low latency to any international areas where you have customers, remember that low latency generally equates to really good performance. If you want to offer low-latency performance improvements to international customers, you can create lots of secondary regions replicated from a primary region, and then the application can sit in those secondary regions and just perform read operations against the secondary clusters, providing your customers with great performance.

Again, it's important to understand that Aurora Global Databases, the replication occurs at the storage layer, and it's generally around one second or even less between regions from the primary region to all secondary regions. It's also important to understand that this is one-way replication from the primary to the secondary regions; it is not bidirectional replication, and replication has no impact on database performance because it occurs at the storage layer. So no additional CPU usage is required to perform the replication tasks. It happens at the storage layer.

Secondary regions can have 16 replicas. If you think about Aurora, normally it can have one read and write primary instance and then up to 15 read replicas for a total of 16, so it makes sense that secondary regions, because they don't have this read-write primary instance, all of the replicas inside a secondary can be read replicas. So, it can have a total of 16 replicas per secondary region, and all of these can be promoted to read-write if you do have any disaster situations. Currently, there is a maximum of five secondary regions, though just like most things in AWS, this is likely to change.

Now again, for the exam, I don't expect this particular product to feature extensively, but I do want you to have an awareness so that when it does begin to be mentioned in the exam or if you need to use it in production, you have a starting point by understanding the architecture. With that being said, though, that is everything that I wanted to cover in this theory lesson. So, go ahead, complete the video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this lesson, I want to cover Aurora Serverless. Aurora Serverless is a service which is to Aurora what Fargate is to ECS. It provides a version of the Aurora database product where you don't need to statically provision database instances of a certain size or worry about managing those database instances. It's another step closer to a database as a service product. It removes one more piece of admin overhead, the admin overhead of managing individual database instances. From now on, when you're referring to the Aurora product that we've covered so far in the course, you should refer to it as Aurora provisioned versus Aurora Serverless, which is what we'll cover in this lesson.

With Aurora Serverless, you don't need to provision resources in the same way as you did with Aurora provisioned. You still create a cluster, but Aurora Serverless uses the concept of ACUs or Aurora Capacity Units. Capacity units represent a certain amount of compute and a corresponding amount of memory. For a cluster, you can set minimum and maximum values, and Aurora Serverless will scale between those values, adding or removing capacity based on the load placed on the cluster. It can even go down to zero and be paused, meaning that you're only billed for the storage that the cluster consumes.

Now billing is based on the resources that you use on a per-second basis, and Aurora Serverless provides the same levels of resilience as you're used to with Aurora provisioned. So, you get cluster storage that's replicated across six storage nodes across multiple availability zones. Now, some of the high-level benefits of Aurora Serverless: it's much simpler, it removes much of the complexity of managing database instances and capacity, it's easier to scale, it seamlessly scales the compute and memory capacity in the form of ACUs as needed with no disruption to client connections, and you'll see how that works architecturally on the next screen. It's also cost-effective. When you use Aurora Serverless, you only pay for the database resources that you consume on a per-second basis, unlike with Aurora provisioned, where you have to provision database instances in advance, and you charge for the resources that they consume, whether you're utilizing them or not.

The architecture of Aurora Serverless has many similarities with Aurora provisioned, but it also has crucial differences, so let's review both of those, the similarities and the differences. The Aurora cluster architecture still exists, but it's in the form of an Aurora Serverless cluster. Now, this has the same cluster volume architecture which Aurora provisioned uses. In an Aurora Serverless cluster, though, instead of using provisioned servers, we have ACUs, which are Aurora Capacity Units. These capacity units are actually allocated from a warm pool of Aurora capacity units which are managed by AWS. The ACUs are stateless, they're shared across many AWS customers, and they have no local storage, so they can be allocated to your Aurora Serverless cluster rapidly when required. Now, once these ACUs are allocated to an Aurora Serverless cluster, they have access to the cluster storage in the same way that a provisioned Aurora instance would have access to the storage in a provisioned Aurora cluster. It's the same thing; it's just that these ACUs are allocated from a shared pool managed by AWS.

Now, if the load on an Aurora Serverless cluster increases beyond the capacity units which are being used, and assuming the maximum capacity setting of the cluster allows it, then more ACUs will be allocated to the cluster. And once the compute resource, which represents this new, potentially bigger ACU, is active, then any old compute resources representing unused capacity can be deallocated from your Aurora Serverless cluster. Now, because of the ACU architecture, because the number of ACUs are dynamically increased and decreased based on load, the way that connections are managed within an Aurora Serverless cluster has to be slightly more complex versus a provisioned cluster. In an Aurora Serverless cluster, we have a shared proxy fleet which is managed by AWS. Now, this happens transparently to you as a user of an Aurora Serverless cluster, but if a user interacts with the cluster via an application, it actually goes via this proxy fleet. Any of the proxy fleet instances can be used, and they will broker a connection between the application and the Aurora Capacity Units.

Now, this means that because the client application is never directly connecting to the compute resource that provides an ACU, it means that the scaling can be fluid, and it can scale in or out without causing any disruptions to applications while it's occurring because you're not directly connecting with an ACU. You're connecting via an instance in this proxy fleet. So, the proxy fleet is managed by AWS on your behalf. The only thing you need to worry about for an Aurora Serverless cluster is picking the minimum and maximum values for the ACU, and you only have a bill for the amount of ACU that you're using at a particular point in time as well as the cluster storage. So that makes Aurora Serverless really flexible for certain types of use cases.

Now, a couple of examples of types of applications which really do suit Aurora Serverless. The first is infrequently used applications, maybe a low-volume blog site such as "The Best Cats," where connections are only attempted for a few minutes several times per day, or maybe on really popular days of the week. With Aurora Serverless, if you were using the product to run the "Best Cat Pics" blog, which you'll experience in the demo lesson, then you'd only pay for resources for the Aurora Serverless cluster as you consume them on a per-second basis. Another really good use case is new applications. If you're deploying an application where you're unsure about the levels of load that will be placed on the application, so you're going to be unsure about the size of the database instance that you'll need. With Aurora provisioned, you would still need to provision that in advance and potentially change it, which could cause disruption. If you use Aurora Serverless, you can create the Aurora Serverless cluster and have the database autoscale based on the incoming load.

It's also really good for variable workloads. If you're running a normally lightly used application which has peaks, maybe 30 minutes out of an hour or on certain days of the week during sale periods, then you can use Aurora Serverless and have it scale in and out based on that demand. You don't need to provision static capacity based on the peak or average as you would do with Aurora provisioned. It's also really good for applications with unpredictable workloads, so if you're really not sure about the level of workload at a given time of day, you can't predict it, you don't have enough data, then you can provision an Aurora Serverless cluster and initially set a fairly large range of ACUs so the minimum is fairly low and the maximum is fairly high, and then over the initial period of using the application, you can monitor the workload. If it really does stay unpredictable, then potentially Aurora Serverless is the perfect database product to use because if you're using anything else, say an Aurora provisioned cluster, then you always have to have a certain amount of capacity statically provisioned. With Aurora Serverless, you can, in theory, leave an unpredictable application inside Aurora Serverless constantly and just allow the database to scale in and out based on that unpredictable workload.

It's also great for development and test databases because Aurora Serverless can be configured to pause itself during periods of no load, and during the database pause, you only build for the storage. So, if you do have systems which are only used as part of your development and test processes, then they can scale back to zero and only incur storage charges during periods when it's not in use, and that's really cost-effective for this type of workload. It's also great for multi-tenant applications. If you've got an application where you're billing a user a set dollar amount per month per license to the application, if your incoming load is directly aligned to your incoming revenue, then it makes perfect sense to use Aurora Serverless. You don't mind if a database supporting your product scales up and costs you more if you also get more customer revenue, so it makes perfect sense to use Aurora Serverless for multi-tenant applications where the scaling is fairly aligned between infrastructure size and incoming revenue.

So, these are some classic examples of when Aurora Serverless makes perfect sense. Now, this is a product I don't yet expect to feature extensively on the exam. It will feature more and more as time goes on, and so by learning the architecture at this point, you get a head start and you can answer any questions which might feature on the exam about Aurora Serverless and comparing it to the other RDS products, which is often just as important. But at this point, that's all of the theory that I wanted to cover, all of the architecture. So go ahead, finish up this video, and when you're ready, I look forward to joining you in the next lesson.

Welcome back, and in this lesson, I'm going to be covering the architecture of the Amazon Aurora managed database product from AWS. I mentioned earlier that Aurora is officially part of RDS, but from my perspective, I've always viewed it as its own distinct product. The features that it provides and the architecture it uses to deliver those features are so radically different than normal RDS that it needs to be treated as its own product. So, we've got a lot to cover, so let's jump in and get started.

As I just mentioned, the Aurora architecture is very different from normal RDS. At its very foundation, it uses the base entity of a cluster, which is something that other engines within RDS don’t have. A cluster is made up of a number of important things. Firstly, from a compute perspective, it's made up of a single primary instance and then zero or more replicas. Now, this might seem similar to how RDS works with the primary and the standby replica, but it’s actually very different. The replicas within Aurora can be used for reads during normal operations, so it’s not like the standby replica inside RDS. The replicas inside Aurora can actually provide the benefits of both RDS multi-AZ and RDS read replicas. So, they can be inside a cluster and can be used to improve availability, but they can also be used for read operations during the normal operation of a cluster.

Now, that alone would be worth the move to Aurora since you don’t have to choose between read scaling and availability. Replicas inside Aurora can provide both of those benefits. Now, the second major difference in the Aurora architecture is its storage. Aurora doesn’t use local storage for the compute instances. Instead, an Aurora cluster has a shared cluster volume. This is storage that is shared and available to all compute instances within a cluster. This provides a few benefits, such as faster provisioning, improved availability, and better performance.

A typical Aurora cluster looks something like this. It functions across a number of availability zones—in this example, A, B, and C. Inside the cluster is a primary instance and optionally a number of replicas. Again, these function as failover options if the primary instance fails, but they can also be used during the normal functioning of the cluster for read operations from applications. Now, the cluster has shared storage, which is SSD-based, and it has a maximum size of 128TIB. It also has six replicas across multiple availability zones. When data is written to the primary DB instance, Aurora synchronously replicates that data across all of these six storage nodes spread across the availability zones, which are associated with your cluster. All instances inside your cluster, so the primary and all of the replicas, have access to all of these storage nodes.

The important thing to understand, though, from a storage perspective, is that this replication happens at the storage level. So, no extra resources are consumed on the instances or the replicas during this replication process. By default, the primary instance is the only instance able to write to the storage, and the replicas and the primary can perform read operations. Because Aurora maintains multiple copies of your data in three availability zones, the chances of losing data as a result of any disk-related failure are greatly minimized. Aurora automatically detects failures in the disk volumes that make up the cluster shared storage. When a segment or a part of a disk volume fails, Aurora immediately repairs that area of the disk. When Aurora repairs that area of disk, it uses the data inside the other storage nodes that make up the cluster volume and it automatically recreates that data. It ensures that the data is brought back into an operational state with no corruption. As a result, Aurora avoids data loss and reduces any need to perform point-in-time restores or snapshot restores to recover from disk failures.

So, the storage subsystem inside Aurora is much more resilient than that which is used by the normal RDS database engines. Another powerful difference between Aurora and the normal RDS database engines is that with Aurora, you can have up to 15 replicas, and any of them can be the failover target for a failover operation. So, rather than just having the one primary instance and the one standby replica of the non-Aurora engines, with Aurora, you’ve got 15 different replicas that you can choose to fail over to. And that failover operation will be much quicker because it doesn’t have to make any storage modifications.

Now, as well as the resiliency that the cluster volume provides, there are a few other key elements that you should be aware of. The cluster shared volume is based on SSD storage by default, so it provides high IOPS and low latency. It's high-performance storage by default. You don't get the option of using magnetic storage. Now, the billing for that storage is very different than with the normal RDS engines. With Aurora, you don't have to allocate the storage that the cluster uses. When you create an Aurora cluster, you don't specify the amount of storage that's needed. Storage is simply based on what you consume. As you store data up to the 128 TIB limit, you'll bill on consumption.

Now, the way that this consumption works is that it's based on a high watermark. So, if you consume 50 GIB of storage, you'll bill for 50 GIB of storage. If you free up 10 GIB of data (so move down to 40 GIB of consumed data), you'll still bill for that high watermark of 50 GIB, but you can reuse any storage that you free up. What you'll bill for is a high watermark—the maximum storage that you've consumed in a cluster. And if you go through a process of significantly reducing storage and you need to reduce storage costs, then you need to create a brand new cluster and migrate data from the old cluster to the new cluster.

Now, it is worth mentioning that this high watermark architecture is being changed by AWS, and this no longer is applicable for the more recent versions of Aurora. I’m going to update this lesson once this feature becomes more widespread, but for now, you do still need to assume that this high watermark architecture is being used. Now, because the storage is for the cluster and not for the instances, it means replicas can be added and removed without requiring storage provisioning or removal, which massively improves the speed and efficiency of any replica changes within the cluster. Having this cluster architecture also changes the access method versus RDS.

Aurora clusters, like RDS clusters, use endpoints. These are DNS addresses that are used to connect to the cluster. Unlike RDS, Aurora clusters have multiple endpoints that are available for an application. As a minimum, you have the cluster endpoint and the reader endpoint. The cluster endpoint always points at the primary instance, and that's the endpoint that can be used for read and write operations. The reader endpoint will also point at the primary instance if that's all that there is, but if there are replicas, then the reader endpoint will load balance across all of the available replicas, and this can be used for read operations.

Now, this makes it much easier to manage read scaling using Aurora versus RDS because as you add additional replicas, which can be used for reads, this reader endpoint is automatically updated to load balance across these new replicas. You can also create custom endpoints, and in addition to that, each instance, so the primary and any of the replicas, has their own unique endpoint. So, Aurora allows for a much more custom and complex architecture versus RDS.

So, let’s move on and talk about costs. With Aurora, one of the biggest downsides is that there isn’t actually a free tier option. You can’t use Aurora within the free tier, and that’s because Aurora doesn’t support the micro instances that are available inside the free tier. But for any instances beyond an RDS single AZ micro-sized instance, Aurora offers much better value. For any compute that you use, there's an hourly charge, and you'll bill per second with a 10-minute minimum. For storage, you’ll bill based on a gigabyte month consumed metric, of course taking into account the high watermark. So, this is based on the maximum amount of storage that you've consumed during the lifetime of that cluster, and as well, there is an I/O cost per request made to the cluster shared storage.

Now, in terms of backups, you're given 100% of the storage consumption for the cluster in free backup allocation. So, if your database cluster is 100GIB, then you're given 100GIB of storage for backups as part of what you pay for that cluster. So, for most situations, for anything low usage or medium usage, unless you've got high turnover in data or unless you keep the data for long retention periods, in most cases, you'll find that the backup costs are often included in the charge that you pay for the database cluster itself.

Now, Aurora provides some other really exciting features. In general, though, backups in Aurora work in much the same way as they do in RDS. So, for normal backup features, for automatic backups, for manual snapshot backups, this all works in the same way as any other RDS engine, and restores will create a brand-new cluster. So, you've experienced this in the previous demo lesson where you created a brand-new RDS instance from a snapshot, and this architecture by default doesn't change when you use Aurora.

But you've also got some advanced features, which can change the way that you do things. One of those is backtrack, and this is something that needs to be enabled on a per-cluster basis. It will allow you to roll back your database to a previous point in time. So, consider the scenario where you've got major corruption inside an Aurora cluster, and you can identify the point at which that corruption occurred. Well, rather than having to do a restore to a brand-new database at a point in time before that corruption, if you enable backtrack, you can simply roll back in place your existing Aurora cluster to a point before that corruption occurred. And that means you don’t have to reconfigure your applications; you simply allow them to carry on using the same cluster—it's just the data is rolled back to a previous state before the corruption occurred.

You need to enable this on a per-cluster basis, and you can adjust the window that backtrack will work for, but this is a really powerful feature that's exclusive, at the time of creating this lesson, to Aurora. You also have the ability to create what's known as a fast clone, and a fast clone allows you to create a brand-new database from an existing database. But crucially, it doesn't make a one-for-one copy of the storage for that database. What it does is it references the original storage, and it only stores any differences between those two.

Now, differences can be either that you update the storage in your cloned database, or it can also be that data is updated in the original database, which means that your clone needs a copy of that data before it was changed on the source. So, essentially, your cloned database only uses a tiny amount of storage—it only stores data that's changed in the clone or changed in the original after you make the clone, and that means that you can create clones much faster than if you had to copy all of the data bit by bit. It also means that these clones don’t consume anywhere near the full amount of data—they only store the changes between the source data and the clone.

So, I know that’s a lot of architecture to remember. I’ve tried to quickly step through all of the differences between Aurora and the other RDS engines. You’ll have lessons upcoming later in this section, which deep dive into a little bit more depth of specific Aurora features that I think you will need for the exam, but in this lesson, I just wanted to provide a broad-level overview of the differences between Aurora and the other RDS engines.

So, in the next demo lesson, you're going to get the opportunity to migrate the data for our WordPress application stack from the RDS MariaDB engine into the Aurora engine. So, you'll get some experience of creating an Aurora cluster and interacting with it with some data that you've migrated, but at this point, that's all of the theory that 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 video I want to talk about a specific feature of RDS called RDS Custom. Now this is a really niche topic. I've yet to see it used in the real world and for the exams you really only need to have the most surface level understanding so I'm going to keep this really brief. So RDS Custom fills the gap between the main RDS product and then EC2 running a database engine. RDS is a fully managed database server as a service product. Essentially it gives you access to databases running on a database server which is fully managed by AWS and so any OS or engine access is limited using the main RDS product.

Now databases running on EC2 are self-managed but this has significant overhead because done in this way you're responsible for everything from the operating system upwards. So RDS Custom bridges this gap; it gives you the ability to occupy a middle ground where you can utilize RDS but still get access to some of the customizations that you have access to when running your own DB engine on EC2. Now currently RDS Custom works for MS SQL and Oracle and when you're using RDS Custom you can actually connect using SSH, RDP and session manager and actually get access to the operating system and database engine.

Now RDS Custom, unlike RDS, is actually running within your AWS account. If you're utilizing normal RDS then if you look in your account you won't see any EC2 instances or EBS volumes or any backups within S3. That's because they're all occurring within an AWS managed environment. With RDS, the networking works by injecting elastic network interfaces into your VPC. That's how you get access to the RDS instance from a networking perspective, but with RDS Custom everything is running within your AWS account so you will see an EC2 instance, you will see EBS volumes and you will see backups inside your AWS account.

Now if you do need to perform any type of customization of RDS Custom then you need to look at the database automation settings to ensure that you have no disruptions caused by the RDS automation while you're performing customizations. You need to pause database automation, perform your customizations and then resume the automation so re-enable full automation and this makes sure that the database is ready for production usage. Now again I'm skipping through a lot of these facts and talking only at a high level because realistically you're probably never going to encounter this in production and if you do have any exposure to it on the exam just knowing that it exists will be enough.

Now from a service model perspective, this is how using RDS Custom changes things. So on this screen anything that you see in blue is customer managed, anything that you see in orange is AWS managed and then anything that has a gradient is a shared responsibility. So if you're using a database engine running on-premises then you're responsible for everything as the customer. So application optimization, scaling, high availability, backups, any DB patches, operating system patches, operating system install and management of the hardware. End-to-end that's your responsibility.

Now if you migrate to using RDS, this is how it looks where AWS has responsibility for everything but application optimization. Now if for whatever reason you can't use RDS, then historically your only other option was to use a database engine running on EC2 and this was the model in that configuration. So AWS handled the hardware but from an operating system installation perspective, operating system patches, database patches, backups, HA, scaling and application optimization were still the responsibility of the customer. So you only gained a tiny amount of benefit versus using an on-premises system.

With RDS Custom we have this extra option where the hardware is AWS's responsibility, the application optimization is the customer responsibility but everything else is shared between the customer and AWS. So this gives you some of the benefits of both. It gives you the ability to use the RDS product and benefit from the automation while at the same time allowing you an increased level of customization and the ability to connect into the instance using SSH, session manager or RDP.

Now once again for the exam this is everything that you'll need to understand. It only currently works for Oracle and MS SQL and for the real world you probably won't encounter this outside of very niche scenarios. With that being said though that is everything I wanted to cover in this video, so go ahead and complete the video and when you're ready I'll look forward to you joining me in the next.

Welcome back and in this lesson I want to talk about data security within the RDS product. I want to focus on four different things: Authentication, so how users can log into RDS; Authorization, how access is controlled; Encryption in transit between clients and RDS; and then encryption at rest, so how data is protected when it's written to disk. Now we've got a lot to cover so let's jump in and get started.

With all of the different engines within RDS you can use encryption in transit, which means data between the client and the RDS instance is encrypted via SSL or TLS, and this can actually be set to mandatory on a per user basis. Encryption at rest is supported in a few different ways depending on the database engine. By default, it's supported using KMS and EBS encryption. So this is handled by the RDS host and the underlying EBS based storage. As far as the RDS database engine knows, it's just writing unencrypted data to storage. The data is encrypted by the host that the RDS instance is running on. KMS is used and so you select a customer master key or CMK to use. Either a customer managed CMK or an AWS managed CMK and then this CMK is used to generate data encryption keys or DECs, which are used for the actual encryption operations.

Now when using this type of encryption, the storage, the logs, the snapshots, and any replicas are all encrypted using the same customer master key and importantly encryption cannot be removed once it's added. Now these are features supported as standard with RDS. In addition to KMS EBS based encryption, Microsoft SQL and Oracle support TDE. Now TDE stands for transparent data encryption and this is encryption which is supported and handled within the database engine. So data is encrypted and decrypted within the database engine itself not by the host that the instance is running on, and this means that there's less trust. It means that you know data is secure from the moment it's written out to disk by the database engine.

In addition to this, RDS Oracle supports TDE using cloud HSM and with this architecture, the encryption process is even more secure with even stronger key controls because cloud HSM is managed by you with no key exposure to AWS. It means that you can implement encryption where there is no trust chain which involves AWS and for many demanding regulatory situations this is really valuable. Visually, this is how the encryption architecture looks. Architecturally, let's say that we have a VPC and inside this a few RDS instances running on a pair of underlying hosts and these instances use EBS for underlying storage. Now we'll start off with Oracle on the left, which uses TDE and so cloud HSM is used for key services because TDE is native and handled by the database engine. The data is encrypted from the engine all the way through to the storage with AWS having no exposure and outside of the RDS instance to the encryption keys which are used.

With KMS based encryption, KMS generates and allows usage of CMKs which themselves can be used to generate data encryption keys known as DECays. These data encryption keys are loaded onto the RDS hosts as needed and are used by the host to perform the encryption or decryption operations. This means the database engine doesn't need to natively support encryption or decryption; it has no encryption awareness. From its perspective, it's writing data as normal and it's encrypted by the host before sending it on to EBS in its final encrypted format. Data that's transferred between replicas, as with MySQL in this example, is also encrypted as are any snapshots of the RDS EBS volumes and these use the same encryption key. So that's at rest encryption and there's one more thing that I want to cover before we finish this lesson and that's IAM authentication for RDS.

Normally logins to RDS are controlled using local database users. These have their own usernames and passwords, they're not IAM users and are outside of the control of AWS. One gets created when you provision an RDS instance but that's it. Now you can configure RDS to allow IAM user authentication against a database and this is how. We start with an RDS instance on which we create a local database user account configured to allow authentication using an AWS authentication token. How this works is that we have IAM users and roles, in this case an instance role, and attached to those roles and users are policies. These policies contain a mapping between that IAM entity, so the user or role, and a local RDS database user. This allows those identities to run a generate DB auth token operation which works with RDS and IAM and based on the policies attached to the IAM identities, it generates a token with a 15-minute validity. This token can then be used to log in to the database user within RDS without requiring a password.

So this is really important to understand by associating a policy with an IAM user or an IAM role, it allows either of those two identities to generate an authentication token which can be used to log into RDS instead of a password. Now one really important thing to understand going into the exam is that this is only authentication. This is not authorization. The permissions over the RDS database inside the instance are still controlled by the permissions on the local database user. So authorization is still handled internally. This process is only for authentication which involves IAM and only if you specifically enable it on the RDS instance.

Now that's everything I wanted to cover about encryption in transit, encryption at rest as well as RDS IAM based authentication. 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.

Welcome back. In this video I want to talk about RDS read replicas. Now read replicas provide a few main benefits to us as solutions architects or operational engineers; they provide performance benefits for read operations, they help us create cross-region failover capability, and they provide a way for RDS to meet really low recovery time objectives, just as long as data corruption isn't involved in a disaster scenario. Now let's step through the key concepts and architectures because they're going to be useful for both the exam and the real world.

Read replicas, as the name suggests, are read-only replicas of an RDS instance. Unlike MultiAZ, where you can't by default use the standby replica for anything, you can use read replicas but only for read operations. Now MultiAZ running in cluster mode, which is the newer version of MultiAZ, is like a combination of the old MultiAZ instance mode together with read replicas. But, and this is really important, you have to think of read replicas as separate things; they aren't part of the main database instance in any way. They have their own database endpoint address and so applications need to be adjusted to use them. An application, say WordPress, using an RDS instance will have zero knowledge of any read replicas by default. Without application support, read replicas do nothing. They aren't functional from a usage perspective. There's no automatic failover, they just exist off to one side.

Now they're kept in sync using a synchronous replication. Remember MultiAZ uses synchronous replication and that means that when data is written to the primary instance, at the same time as storing that data on disk on the primary, it's replicated to the standby. And conceptually think of this as a single write operation, both on the primary and on the standby. With asynchronous, data is written to the primary first at which point it's viewed as committed. Then after that it's replicated to the read replicas and this means in theory there could be a small lag, maybe seconds, but it depends on network conditions and how many writes occur on the database. For the exam for any RDS questions and exclude Aurora for now, remember that synchronous means MultiAZ and asynchronous means read replicas.

Read replicas can be created in the same region as the primary database instance or they can be created in other AWS regions known as cross region read replicas. If you create a cross region read replica, then AWS handle all of the networking between regions and this occurs transparently to you and it's fully encrypted in transit.

Now why do read replicas matter? Well there are two main areas of importance that I want you to think about. First is read performance and read scaling for a database instance. So you can create five direct read replicas per database instance and each of these provides an additional instance of read performance. So this offers a simple way of scaling out your read performance on a database. Now read replicas themselves can also have their own read replicas but this means that lag starts to become a problem because asynchronous replication is used. There can be a lag between the main database instance and any read replicas and if you then create read replicas of read replicas then this lag becomes more of a problem. So while you can use multiple levels of read replicas to scale read performance even more lag does start to become even more of a problem. So you need to take that into consideration.

Additionally read replicas can help you with global performance improvements for read workloads. So if you have read workloads in other AWS regions then these workloads can directly connect to read replicas and not impact the performance at the primary instance in any way. In addition read replicas benefit us in terms of recovery point objectives and recovery time objectives. So snapshots and backups improve RPOs the more frequent snapshots occur and the better backups are this offers improved recovery point objectives because it limits the amount of data which can be lost but it doesn't really help us for recovery time objectives because restoring snapshots takes a long time especially for large databases.

Now read replicas offer a near zero RPO and that's because the data that's on the read replica is synced from the main database instance. So there's very little potential for data loss assuming we're not dealing with data corruption. Read replicas can be promoted quickly they offer a near zero RPO. So in a disaster scenario where you have a major problem with your RDS instance you can promote a read replica and this is a really quick process but and this is really important you should only look at using read replicas during disaster recovery scenarios when you're recovering from failure. If you're recovering from data corruption then logically the read replica will probably have a replica of that corrupted data. So read replicas are great for achieving low RTOs but only for failure and not for data corruption.

Now read replicas are read only until they're promoted and when they're promoted you're able to use them as a normal RDS instance. There's also a really simple way to achieve global availability improvements and global resilience because you can create a cross region read replica in another AWS region and use this as a failover region if AWS ever have a major regional issue.

Now at this point that's everything I wanted to cover about read replicas. If appropriate for the exam that you're studying I might have another lesson which goes into more technical depth or a demo lesson which allows you to experience this practically. If you don't see either of these then don't worry they're not required for the exam that you're studying. At this point though, that's everything I'm going to cover 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 how RDS can be backed up and restored, as well as covering the different methods of backup that we have available. Now we do have a lot to cover, so let's jump in and get started. Within RDS, there are two types of backup-like functionality: automated backups and snapshots. Both of these are stored in S3, but they use AWS-managed buckets, so they won't be visible to you within your AWS console. You can see backups in the RDS console, but you can't move to S3 and see any form of RDS bucket, which exists for backups. Keep this in mind because I've seen questions on it in the exam.

Now, the benefits of using S3 is that any data contained in backups is now regionally resilient, because it's stored in S3, which replicates data across multiple AWS availability zones within that region. RDS backups, when they do occur, are taken in most cases from the standby instance if you have multi-AZ enabled. So, while they do cause an I/O pause, this occurs from the standby instance, and so there won't be any application performance issues. If you don't use multi-AZ, for example, with test and development instances, then the backups are taken from the only available instance, so you may have pauses in performance.

Now, I want to step through how backups work in a little bit more detail, and I'm going to start with snapshots. Snapshots aren't automatic; they're things that you run explicitly or via a script or custom application. You have to run them against an RDS database instance. They're stored in S3, which is managed by AWS, and they function like the EBS snapshots that you've covered elsewhere in the course. Snapshots and automated backups are taken of the instance, which means all the databases within it, rather than just a single database. The first snapshot is a full copy of the data stored within the instance, and from then on, snapshots only store data which has changed since the last snapshot.

When any snapshot occurs, there is a brief interruption to the flow of data between the compute resource and the storage. If you're using single AZ, this can impact your application. If you're using multi-AZ, this occurs on the standby, and so won't have any noticeable effect. Time-wise, the initial snapshot might take a while; after all, it's a full copy of the data. From then on, snapshots will be much quicker because only changed data is being stored. Now, the exception to this are instances where there's a lot of data change. In this type of scenario, snapshots after the initial one can also take significant amounts of time. Snapshots don't expire; you have to clear them up yourself. It means that snapshots live on past when you delete the RDS instance. Again, they're only deleted when you delete them manually or via some external process. Remember that one because it matters for the exam.

Now you can run one snapshot per month, one per week, one per day, or one per hour. The choice is yours because they're manual. And one way that lower recovery point objectives can be met is by taking more frequent snapshots. The lower the time frame between snapshots, the lower the maximum data loss that can occur when you have a failure. Now, this is assuming we only have snapshots available, but there is another part to RDS backups, and that's automated backups. These occur once per day, but the architecture is the same. The first one is a full, and any ones which follow only store changed data. So far, you can think of them as though they're automated snapshots, because that's what they are. They occur during a backup window which is defined on the instance. You can allow AWS to pick one at random or use a window which fits your business. If you're using single AZ, you should make sure that this happens during periods of little to no use, as again there will be an I/O pause. If you're using multi-AZ, this isn't a concern, as the backup occurs from the standby.

In addition to this automated snapshot, every five minutes, database transaction logs are also written to S3. Transaction logs store the actual operations which change the data, so operations which are executed on the database. And together with the snapshots created from the automated backups, this means a database can be restored to a point in time with a five-minute granularity. In theory, this means a five-minute recovery point objective can be reached. Now automated backups aren't retained indefinitely; they're automatically cleared up by AWS, and for a given RDS instance, you can set a retention period from zero to 35 days. Zero means automated backups are disabled, and the maximum is 35 days. If you use a value of 35 days, it means that you can restore to any point in time over that 35-day period using the snapshots and transaction logs, but it means that any data older than 35 days is automatically removed.

When you delete the database, you can choose to retain any automated backups, but, and this is critical, they still expire based on the retention period. The way to maintain the contents of an RDS instance past this 35-day max retention period is that if you delete an RDS instance, you need to create a final snapshot, and this snapshot is fully under your control and has to be manually deleted as required. Now, RDS also allows you to replicate backups to another AWS region, and by backups, I mean both snapshots and transaction logs. Now, charges apply for both the cross-region data copy and any storage used in the destination region, and I want to stress this really strongly. This is not the default. This has to be configured within automated backups. You have to explicitly enable it.

Now let's talk a little bit about restores. The way RDS handles restores is really important, and it's not immediately intuitive. It creates a new RDS instance when you restore an automated backup or a manual snapshot. Why this matters is that you will need to update applications to use the new database endpoint address because it will be different than the existing one. When you restore a manual snapshot, you're restoring the database to a single point in time. It's fixed to the time that the snapshot was created, which means it influences the RPO. Unless you created a snapshot right before a failure, then chances are the RPO is going to be suboptimal. Automated backups are different. With these, you can choose a specific point to restore the database to, and this offers substantial improvements to RPO. You can choose to restore to a time which was minutes before a failure.

The way that it works is that backups are restored from the closest snapshot, and then transaction logs are replayed from that point onwards, all the way through to your chosen time. What's important to understand though is that restoring snapshots isn't a fast process. If appropriate for the exam that you're studying, I'm going to include a demo where you'll get the chance to experience this yourself practically. It can take a significant amount of time to restore a large database, so keep this in mind when you think about disaster recovery and business continuity. The RDS restore time has to be taken into consideration.

Now in another video elsewhere in this course, I'm going to be covering read replicas, and these offer a way to significantly improve RPO if you want to recover from failure. So, RDS automated backups are great as a recovery to failure, or as a restoration method for any data corruption, but they take time to perform a restore, so account for this within your RTO planning. Now once again, if appropriate for the exam that you're studying, you're going to get the chance to experience a restore in a demo lesson elsewhere in the course, which should reinforce the knowledge that you've gained within this theory video. If you don't see this then don't worry, it's not required for the exam that you're studying.

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

Welcome back, and in this video, I want to talk through the ways in which RDS offers high availability. Historically, there was one way: multi-AZ. Over time, RDS has been improved, and now there are multi-AZ instance deployments and multi-AZ cluster deployments, each offering different benefits and trade-offs. In this video, I want to step through the architecture and functionality of both. Now, we do have a lot to cover, so let's jump in and get started straight away.

Historically, the only method of providing high availability that RDS had was multi-AZ, which is now called multi-AZ instance deployment. With this architecture, RDS has a primary database instance containing any databases that you create. When you enable multi-AZ mode, this primary instance is configured to replicate its data synchronously to a standby replica running in another availability zone, meaning the standby also has a copy of your databases.

In multi-AZ instance mode, this replication occurs at the storage level, which is less efficient than the cluster multi-AZ architecture, but more on this later in the video. The exact method that RDS uses for this replication depends on the database engine you pick. MariaDB, MySQL, Oracle, and PostgreSQL use Amazon failover technology, whereas Microsoft's SQL instances use SQL server database mirroring or always-on availability groups. In any case, this is abstracted away, and all you need to understand is that it's a synchronous replica.

Architecturally, all accesses to the databases are via the database CNAME, which is a DNS name that by default points at the primary database instance. With multi-AZ instance architecture, you always access the primary database instance, with no access to the standby, even for reads. Its job is to simply sit there until a failure scenario occurs with the primary instance. Other things, such as backups, can occur from the standby, so data is moved into S3 and then replicated across multiple availability zones in that region, placing no extra load on the primary because it's occurring from the standby.

Remember, all accesses, both reads and writes, from this multi-AZ architecture occur to and from the primary instance. If anything happens to the primary instance, RDS detects it, and a failover occurs. This can be done manually if you're testing or need to perform maintenance, but generally, this is an automatic process. What happens in this scenario is that the database CNAME changes from pointing at the primary to pointing at the standby, which becomes the new primary. Since this is a DNS change, it generally takes between 60 to 120 seconds for this to occur, meaning there can be brief outages.

This can be reduced by removing any DNS caching in your application for this specific DNS name. If you do remove this caching, it means the second RDS has finished the failover, and the DNS name has been updated. Your application will use this name, which now points at the new primary instance. So, this is the architecture when you're using the older multi-AZ instance architecture.

I want to cover a few key points of this architecture before we look at how multi-AZ cluster architecture works. So, just to summarize, replication between primary and standby is synchronous, meaning that data is written to the primary and then immediately replicated to the standby before being viewed as committed. Now, multi-AZ does not come within the free tier because of the extra cost for the standby replica that's required. And multi-AZ with the instance architecture means that you only have one standby replica, and that's important. It's only one standby replica, and this standby replica cannot be used for reads or writes. Its job is to simply sit there and wait for failover events.

A failover event can take anywhere from 60 to 120 seconds to occur, and multi-AZ mode can only be within the same region, meaning different availability zones within the same AWS region. Backups can be taken from the standby replica to improve performance, and failovers will occur for various reasons such as availability zone outage, the failure of the primary instance, manual failover, instance type change (when you change the type of the RDS instance), and even when you're patching software. So, you can use failover to move any consumers of your database onto a different instance, patch the instance with no consumers, and then flip it back. So, it does offer some great features that can help you maintain application availability.

Now, next, I want to talk about multi-AZ using a cluster architecture. When you watch the Aurora video, you might be confused between this architecture and Amazon Aurora. So, I'm going to stress the differences between multi-AZ cluster for RDS and Aurora in this video, and this is to prepare you for when you watch the Aurora video. It's really critical for you to understand the differences between multi-AZ cluster mode for RDS and Amazon Aurora.

We start with a similar VPC architecture, but now in addition to the single client device on the left, I'm adding two more. In this mode, RDS is capable of having one writer replicate to two reader instances, which is a key difference between this and Aurora. With this mode of RDS multi-AZ, you can have two readers only. These are in different availability zones than the writer instance, but there will only be two, whereas with Aurora, you can have more. The difference between this mode of multi-AZ and the instance mode is that these readers are usable. You can think of the writer like the primary instance within multi-AZ instance mode in that it can be used for both writes and read operations.

The reader instances, unlike multi-AZ instance mode, can be utilized while they're in this state. They can be used only for read operations, which will need application support since your application needs to understand that it can't use the same instance for reads and writes. But it means you can use this multi-AZ mode to scale your read workloads, unlike multi-AZ instance mode.

In terms of replications between the writer and the readers, while data is sent to the writer and it's viewed as being committed when at least one of the readers confirms that it's been written, it's resilient at that point across multiple availability zones within that region. The cluster that RDS creates to support this architecture is different in some ways and similar in others compared to Aurora. In RDS multi-AZ mode, each instance still has its own local storage, which, as you'll see elsewhere in this course, is different than Aurora. Like Aurora, though, you access the cluster using a few endpoint types.

The first is the cluster endpoint, which you can think of like the database CNAME in the previous multi-AZ architecture. It points at the writer and can be used for both reads and writes against the database or administration functions. Then, there's a reader endpoint, which points at any available reader within the cluster, and in some cases, this includes the writer instance. Remember, the writer can also be used for reads. In general operation, though, this reader endpoint will be pointing at the dedicated reader instances, and this is how reads within the cluster scale.

So, applications can use the reader endpoint to balance their read operations across readers within the cluster. Finally, there are instance endpoints, and each instance in the cluster gets one of these. Generally, it's not recommended to use them directly, as it means any operations won't be able to tolerate the failure of an instance because they don't switch over to anything if there's an instance failure. So, you generally only use these for testing and fault finding. This is the multi-AZ cluster architecture.

Before I finish up with this video, I just want to cover a few key points about this specific type of multi-AZ implementation. And don't worry, you're going to get the chance to experience RDS practically in other videos in this part of the course. First, RDS using multi-AZ in cluster mode means one writer and two reader DB instances in different availability zones. This gives you a higher level of availability versus instance mode because you have this additional reader instance versus the single standby instance in multi-AZ instance mode.

In addition, multi-AZ cluster mode runs on much faster hardware, using Graviton architecture and local NVMe SSD storage. So, any writes are written first to local superfast storage and then flushed through to EBS. This gives you the benefit of local superfast storage, in addition to the availability and resilience benefits of EBS. Furthermore, when multi-AZ uses cluster mode, readers can be used to scale read operations against the database. So, if your application supports it, you can set read operations to use the reader endpoint, which frees up capacity on the writer instance and allows your RDS implementation to scale to high levels of performance versus any other mode of RDS.

And again, you'll see when you're watching the Aurora video, Aurora as a database platform can scale even more. I'll detail exactly how in that separate video. When using multi-AZ in cluster mode, replication is done using transaction logs, which is much more efficient. This also allows for faster failover. In this mode, failover can occur in as little as 35 seconds, plus any time required to apply the transaction logs to the reader instances. But in any case, this will occur much faster than the 60 to 120 seconds needed when using multi-AZ instance mode.

And just to confirm, when running in this mode, writes are viewed as committed when they've been sent to the writer instance and stored, then replicated to at least one reader, which has confirmed that it's written that data. So, as you can see, these are completely different architectures, and in my opinion, multi-AZ in cluster mode adds significant benefits over instance mode. You'll see how this functionality is extended again when I talk about Amazon Aurora, but for now, that's everything I wanted to cover in this video. Thanks for watching, and when you're ready, I'll look forward to you joining me in the next.

Welcome back, and in this video, which is the first of this series, I'm going to step through the architecture of the relational database service known as RDS. Now, this video will focus on the architecture of the product, with upcoming videos going into specific features in more depth. Now, we do have a lot to cover, so let's jump in and get started.

Now, I've heard many people refer to RDS as a database as a service or DB AAS product. Now, details are important, and you need to understand why this is not the case. A database as a service product is where you pay money, and in return, you get a database; this isn't what RDS does. With RDS, you pay for and receive a database server, so it would be more accurate to call it a database server as a service product. Now, this matters because it means that on this database server or instance, which RDS provides, you can have multiple databases.

RDS provides a managed version of a database server that you might have on-premises, only with RDS, you don't have to manage the hardware, the operating system, or the installation, as well as much of the maintenance of the DB engine, and RDS, of course, runs within AWS.

Now, with RDS, you have a range of database engines to use, including MySQL, Maria DB, PostgreSQL, and then commercial databases such as Oracle and Microsoft SQL. Some of these are open source, and some are commercial, and so there will be licensing implications; and if appropriate for the exam that you're working towards, there will be a separate video on this topic.

Now, there's one specific term that I want you to disassociate from RDS, and that's Amazon Aurora. You might see Amazon Aurora discussed commonly along with RDS, but this is actually a different product. Amazon Aurora is a custom database engine and product created by AWS, which has compatibility with some of the above engines, but it was designed entirely by AWS. Many of the features I'll step through while talking about RDS are different for Aurora, and most of these are improvements, so in your mind, separate Aurora from RDS.

So, in summary, RDS is a managed database server as a service product. It provides you with a database instance—so a database server—which is largely managed by AWS. Now, you don't have access to the operating system or SSH access. Now, I have a little asterisk here because there is a variant of RDS called RDS Custom where you do have some more low-level access, but I'll be covering that in a different video if required. In general, when you think about RDS, think no SSH access and no operating system access.

Now, what I think might help you at this point is to look at a typical RDS architecture visually, and then over the remaining videos in this series, I'll go into more depth on certain elements of the product.

So, RDS is a service which runs within a VPC, so it's not a public service like S3 or DynamoDB; it needs to operate in subnets within a VPC in a specific AWS region, and for this example, let's use US East 1, and to illustrate some cross-region bits of this architecture, our second region will be AP Southeast 2. And then we're going to have within US East 1 a VPC, and let's use three availability zones here: A, B, and C.

Now, the first component of RDS which I want to introduce is an RDS subnet group. This is something that you create, and you can think of this as a list of subnets which RDS can use for a given database instance or instances. So, in this case, let's say that we create one which uses all three of the availability zones; in reality, this means adding any subnets in those three availability zones which you want RDS to use, and in this example, I'm going to actually create another one. We're going to have two database subnet groups, and you'll see why in a second.

In the top database subnet group, let's say I add two public subnets, and in the bottom database subnet group, let's say three private subnets. So, when launching an RDS instance, whether you pick to have it highly available or not—and I'll talk about how this works in an upcoming video—you need to pick a DB subnet group to use.

So, let's say that I picked the bottom database subnet group and launched an RDS instance, and I chose to pick one with high availability. So, it would pick one subnet for the primary instance and another for the standby. It picks at random unless you indicate a specific preference, but it will put the primary and standby within different availability zones. Now, because these database instances are within private subnets, it means that they would be accessible from inside the VPC or from any connected networks such as on-premises networks connected using VPNs or Direct Connect, or any other VPCs which are peered with this one, and I'll cover all of those topics elsewhere in the course if I haven't already done so.

Now, I could also launch another set of RDS instances using the top database subnet group, and the same process would be followed; assuming that I picked to use multi-AZ, RDS would pick two different subnets in two different availability zones to use.

Now, because these are public subnets, we could also, if we really wanted to, elect to make these instances accessible from the public internet by giving them public addressing, and this is something which is really frowned upon from a security perspective, but it's something that you need to know is an option when deploying RDS instances into public subnets.

Now, you can use a single DB subnet group for multiple instances, but then you're limited to using the same defined subnets. If you want to split databases between different sets of subnets, as with this example, then you need multiple DB subnet groups, and generally, as a best practice, I like to have one DB subnet group for one RDS deployment—I find it gives me the best overall flexibility.

Okay, so another few important aspects of RDS which I want to cover: first, RDS instances can have multiple databases on them; second, every RDS instance has its own dedicated storage provided by EBS, so if you have a multi-AZ pair—primary and standby—each has their own dedicated storage. Now, this is different than how Amazon Aurora handles storage, so try to remember this architecture for RDS—each instance has its own dedicated EBS-provided storage.

Now, if you choose to use multi-AZ, as in this architecture, then the primary instances replicate to the standby using synchronous replication. Now, this means that the data is replicated to the standby as soon as it's received by the primary; it means the standby will have the same set of data as the primary—so the same databases and the same data within those databases.

Now, you can also decide to have read replicas; I'll be covering what these are and how they work in another dedicated video, but in summary, read replicas use asynchronous replication, and they can be in the same region but also other AWS regions. These can be used to scale read load or to add layers of resilience if you ever need to recover in a different AWS region.

Now, lastly, we also have backups of RDS. There is a dedicated video covering backups later on in this section of the course, but just know that backups occur to S3—it’s to an AWS-managed S3 bucket, so you don't see the bucket within your account, but it does mean that data is replicated across multiple availability zones in that region. So, if you have an AZ failure, backups will ensure that your data is safe. If you use multi-AZ mode, then backups occur from the standby instance, which means no negative performance impact.

Now, this is the basic product architecture; I'll be expanding on all of these key areas in dedicated videos, as well as giving you the chance to get practical experience via some demos and mini-projects if appropriate.

For now, let's cover one final thing before we finish this video, and that's the cost architecture of RDS. So, before I finish the video, I want to talk about RDS costs because it's a database server as a service product—you're not really billed based on your usage. Instead, like EC2, which RDS is loosely based on, you're billed for resource allocation, and there are a few different components to RDS's cost architecture.

First, you've got the instance size and type—logically, the bigger and more feature-rich the instance, the greater the cost, and this follows a similar model to how EC2 is billed; the fee that you see is an hourly rate, but it's billed per second.

Next, we have the choice of whether multi-AZ is used or not—because multi-AZ means more than one instance, there's going to be additional cost. Now, how much more cost depends on the multi-AZ architecture, which I'll be covering in detail in another video.

Next is a per-gig monthly fee for storage, which means the more storage you use, the higher the cost, and certain types of storage such as provisioned IOPS cost more; and again, this is aligned to how EBS works because the storage is based on EBS.

Next is the data transfer costs, and this is a cost per gig of data transfer in and out of your DB instance from or to the internet and other AWS regions.

Next, we have backups and snapshots—so you get the amount of storage that you pay for for the database instance in snapshot storage for free. So, if you have 2 TB of storage, then that means 2 TB of snapshots for free. Beyond that, there is a cost, and this cost is gig per month of storage, so the more data is stored, the more it costs; the longer it's stored, the more it costs—one TB for one month is the same cost as 500 GB for two months, so it's a per-GB-month cost.

And then finally, we have any extra costs based on using commercial DB engine types, and again, I'll be covering this if appropriate in a dedicated video elsewhere in the course.

Okay, so at this point, that is everything I wanted to cover in this video. As I mentioned at the start, this is just an introduction to RDS architecture; we're going to be going into more detail on specific key points in upcoming videos, but for now, that's everything I wanted to cover. 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 something which can be argued is bad practice to do inside AWS and that's running databases directly on EC2, as you'll find out in this section of the course there are lots of AWS products which provide database services so running any database on EC2 at best requires some justification.

In this lesson I want to step through why you might want to directly run databases on EC2 and why it's also a bad idea; it's actually always a bad idea to run databases on EC2, and the argument really is whether the benefits to you or your business outweigh the fact that it is a bad idea.

So let's jump in and take a look at some of the reasons why you should and shouldn't run databases on EC2.

Generally when people think about running databases on EC2 they picture one of two things: first, a single instance and on this instance you're going to be running a database platform, an application of some kind and perhaps a web server such as Apache, or you might picture a simple split architecture where the database is separated from the web server and application, so you'll have two instances, probably smaller instances than the single large one.

And architecturally I hope this makes sense so far, since so far in the course with the Animals for Life WordPress application stack example we've used the architecture on the left—a single EC2 instance with all of the application tiers or components on one single instance, crucially one single instance running within a single availability zone.

Now if you have a split architecture like on the right you can either have both EC2 instances inside the same availability zone or you could split the instances across two—so AZA and AZB.

Now when you change the architecture in this way, when you split up the components into separate instances, whether you decide to put those both in the same availability zone or split them, you need to understand that you've introduced a dependency into the architecture—the dependency that you've introduced is that there needs to be reliable communication between the instance running the application and the database instance, if not the application won't work.

And if you do decide to split these instances across multiple availability zones then you should also be aware that there is a cost for data when it's transiting between different availability zones in the same region—it's small but it does exist.

Now that's in contrast to where communications between instances using private IPs in the same availability zone is free, so that's a lot to think about from an architectural perspective, but that's what we mean when we talk about running databases on EC2—this is the architecture, generally one or more EC2 instances with at least one of them running the database platform.

Now there are some reasons why you might want to run databases on EC2 in your own environment—you might need access to the operating system of the database and the only way that you can have this level of access is to run on EC2 because other adbs products don't give you OS level access.

This is one of those things though that you should really question if a client requests it because there aren't many situations where OS level access is really a requirement—do they need it, do they want it, or do they only think that they want it?

So if you have a client or if your business states that they do need OS level access the first thing that you should do is question that statement.

Now there are some database tuning things which can only be done with root level access and because you don't have this level of access with managed database products then these values or these configuration options won't be tuneable.

But in many cases and you'll see this later on in this section AWS does allow you to control a lot of these parameters that historically you would need root access for without having root access.

So again this is one of those situations where you need to question any situation where it's presented to you that you need database root access—it's worth noting often that it's an application vendor demanding this level of access not the business themselves, but again it's often the case that you need to delve into the justifications.

This level of access is often not required and a lot of software vendors now explicitly support AWS's managed database products, so again verify any suggestion of this level of access.

Now something that is often justified is that you might need to run a database or a database version which AWS don't provide—this is certainly possible and more so with emerging types of databases or databases with really niche use cases.

You might actually need to implement an application with a particular database that is not supported by AWS and any of its managed database products, and in that case the only way of servicing that demand is to install that database on EC2.

So that's one often justified reason for running databases on EC2, or it might be that a particular project that you're working on has really, really detailed and specific requirements and you need a very specific version of an OS and a very specific version of a DB in combination which AWS don't provide.

Or you might need or want to implement an architecture which AWS also don't provide—certain types of replication done in certain ways or at certain times.

Or it could be something as simple as the decision makers in your organization just want a database running on EC2—you could argue that they're being unreasonable to just demand a database running on EC2 but in many cases you might not have a choice.

So it can always be done—you can run databases on EC2 as long as you're willing to accept the negatives, so these are all valid, some of them I would question or fight or ask for justification but situations certainly do exist which require you to use databases on EC2.

And I'm stressing these because I've seen tricky exam questions where the right answer is to use a database on EC2, so I want to make sure that you've got fresh in your mind some of the styles of situations where you might actually want to run a database on EC2.

But now let's talk about why you really shouldn't put a database product on EC2—even with the previous screen in mind, even with all of those justifications, you need to be aware of the negatives.

And the first one is the admin overhead—the admin overhead of managing the EC2 instance as well as the database host, the database server, both of these require significant management effort.

Don't underestimate the effort required to keep an EC2 instance patched or keep a database host running at a certain compatible level with your application—you might not be able to upgrade or you might have to upgrade and keep the database version running in a very narrow range in order to be compatible with the application.

And whenever you perform upgrades or whenever you're fault finding, you need to do it out of core usage hours, which could mean additional time, stress and cost for staff to maintain both of these components.

Also don't forget about backups and disaster recovery management—so if your business has any disaster recovery planning, running databases on EC2 adds a lot of additional complexity.

And in this area, when you're thinking about backups and DR, many of AWS's managed database products we'll talk about throughout this section include a lot of automation to remove a lot of this admin overhead.

Perhaps one of the most serious limitations though is that you have to keep in mind that EC2 is running in a single availability zone—so if you're running on an EC2 instance, keep in mind you're running on an EBS volume in an EC2 instance, both of those are within a single availability zone.

If that zone fails, access to the database could fail and you need to worry about taking EBS snapshots or taking backups of the database inside the database server and putting those on storage somewhere, maybe S3—again, it's all admin overhead and risk that your business needs to be aware of.

Another issue is features—some of AWS's database products genuinely are amazing, a lot of time and effort and money have been put in on your behalf by AWS to make these products actually better than what you can achieve by installing database software on EC2.

So by limiting yourself to running databases on EC2, you're actually missing out on some of the advanced features and we'll be talking about all of those throughout this section of the course.

Another aspect is that EC2 is on or off—EC2 does not have any concept of serverless because explicitly it is a server, you're not going to be able to scale down easily or keep up with bursty style demand.

There are some AWS managed database products we'll talk about in this section which can scale up or down rapidly based on load, and by running a database product on EC2, you do limit your ability to scale and you do set a base minimum cost of whatever the hourly rate is for that particular size of EC2 instance—so keep that in mind.

So again, if you're being asked to implement this by your business, you should definitely fight this fight and get the business to justify why they want the database product on EC2 because they're missing out on some features and they're committing themselves to costs that they might not need to.

There's also replication—so if you've got an application that does need replication, there are the skills to set this up, the setup time, the monitoring and checking for its effectiveness and all of this tends to be handled by a lot of AWS's managed database products, so again, there's a lot of additional admin overhead that you need to keep in mind.

And lastly, we've got performance—this relates in some way to when I talked about features moments ago.

AWS do invest a considerable amount of time into optimization of their database products and implementing performance based features, and if you simply take an off the shelf database product and implement it on EC2, you're not going to be able to take advantage of these advanced performance features, so keep that in mind.

If you do run database software directly on EC2, you're limiting the performance that you can achieve.

But with that out of the way, that's all of the theory and logic that I wanted to cover in this lesson, so now you have an idea about why you should and why you shouldn't run your own database on an EC2 instance.

In the next lesson, which is a demo, we're going to take the single instance WordPress deployment that we've been using so far in the course, and we're going to evolve it into two separate EC2 instances—one of these is going to be running Apache and WordPress, so it's going to be the application server, and the other is going to be running a database server MariaDB.

Now this kind of evolution is best practice, at least as much as it can ever be best practice to run a self-managed database platform.

Now the reason we're doing this is we want to split up our single monolithic application stack—we want to get it to the point so the database is not running on the same instance as the application itself, because once we've done that, we can move that database into one of AWS's managed database products later in this section.

And that will allow us to take advantage of these features and performance that these products deliver.

It's never a good idea to have a single monolithic application stack when you can avoid it, so the way that we're running WordPress at the moment is not best practice for an enterprise application.

So by splitting up the application from the database, as we go through the course, it will allow us to scale each of these independently and take advantage independently of different AWS products and services, which can help us improve each component of our application.

So with that being said, go ahead and finish up this video, and then when you're ready, you can join me in the next lesson, which is going to be a demo where we're going to split up this monolithic WordPress architecture into two separate compute instances.

Welcome to this lesson where I want to provide a really quick theoretical introduction to Acid and Base, which are two database transaction models that you might encounter in the exam and in the real world. Now this might seem a little abstract, but it does feature on the exam, and I promise in real world usage knowing this is a database superpower. So let's jump in and get started.

Acid and Base are both acronyms and I'll explain what they stand for in a moment, but they are both database transaction models. They define a few things about transactions to and from a database, and this governs how the database system itself is architected. At a real foundational level, there's a computer science theorem called the CAP theorem, and it stands for consistency, availability, and partition tolerance.

Now let's explore each of these quickly because they really matter. Consistency means that every read to a database will receive the most recent write or it will get an error. On the other hand, availability means that every request will receive a non-error response, but without the guarantee that it contains the most recent write, and that's important. Partition tolerance means that the system can be made of multiple network partitions, and the system continues to operate even if there are a number of dropped messages or errors between these network nodes.

Now the CAP theorem states that any database product is only capable of delivering a maximum of two of these different factors. One reason for this is that if you imagine that you have a database with many different nodes, all of these are on a network, imagine if communication fails between some of the nodes or if any of the nodes fail. Well you have two choices if somebody reads from that database: you can cancel the operation and thus decrease the availability but ensure the consistency, or you can proceed with the operation and improve the availability but risk the consistency. So as I just mentioned, it's widely regarded as impossible to deliver a database platform which provides more than two of these three different elements.

So if you have a database system which has multiple nodes and if a network is involved, then you generally have a choice to provide either consistency or availability, and the transaction models of ACID and BASE choose different trade-offs. ACID focuses on consistency and BASE focuses on availability. Now there is some nuance here and some additional detail but this is a high-level introduction. I'm only covering what's essential to know for the exam.

So let's quickly step through the trade-offs which each of these makes and we're going to start off with ACID. ACID means that transactions are atomic, transactions are also consistent, transactions are also isolated, and then finally, transactions are durable. And let's get the exam power-up out of the way: generally if you see ACID mentioned, then it's probably referring to any of the RDS databases. These are generally ACID-based and ACID limits the ability of a database to scale and I want to step through some of the reasons why.

Now I'm going to keep this high-level but I've included some links attached to this lesson if you want to read about this in additional detail. In this lesson though I'm going to keep it to what is absolutely critical for the exam. So let's step through each of these individually.

Atomic means that for a transaction either all parts of a transaction are successful or none of the parts of a transaction are successful. Consider if you run a bank and you want to transfer $10 from account A to account B; that transaction will have two parts: part one will remove $10 from account A and part two will add $10 to account B. Now you don't want a situation where the first part or the second part of that transaction can succeed on its own and the other part can fail — either both parts of a transaction should be successful or no parts of the transaction should be applied and that's what atomic means.

Now consistent means that transactions applied to the database move the database from one valid state to another — nothing in between is allowed. In databases such as relational databases there may well be links between tables where an item in one table must have a corresponding item in another where values might need to be in certain ranges, and this element just means that all transactions need to move the database from one valid state to another as per the rules of that database.

Isolated means that because transactions to a database are often executed in parallel they need not to interfere with each other; isolation ensures that concurrent executions of transactions leave the database in the same state that would have been obtained if transactions were executed sequentially. So this is essential for a database to be able to run lots of different transactions at the same time maybe from different applications or different users — each of them need to execute in full as they would do if they were the only transaction running on that database, they need not to interfere with each other.

And then finally we have durable which means that once a transaction has been committed it will remain committed even in the case of a system failure — once the database tells the application that the transaction is complete and committed once it's succeeded that data is stored somewhere that system failure or power failure or the restart of a database server or node won't impact the data.

Now most relational database platforms use acid-based transactions — it's why financial institutions generally use them because it implements a very rigid form of managing data and transactions on that data, but because of these rigid rules it does limit scalability.

Now next we have BASE, and BASE stands for basically available, it also stands for soft state, and then lastly it stands for eventually consistent — and again this is super high level and I've included some links attached to this lesson with more information.

Now it's also going to sound like I'm making fun of this transaction model because some of these things seem fairly odd, but just stick with me and I'll explain all of the different components. Basically available means that read and write operations are available as much as possible but without any consistency guarantees — so reads and writes are kinder or maybe. Essentially rather than enforcing immediate consistency, BASE-modeled NoSQL databases will ensure availability of data by spreading and replicating that data across all of the different nodes of that database. There isn't really an aim within the database to guarantee anything to do with consistency — it does its best to be consistent but there's no guarantee.

Now soft state is another one which is a tiny bit laughable in a way — it means that BASE breaks off with the concept of a database which enforces its own consistency; instead it delegates that responsibility to developers. Your application needs to be aware of consistency and state and work around the database if you need immediate consistency — so if you need a read operation to always have access to all of the writes which occurred before it immediately, and if the database optionally allows it, then your application needs to specifically ask for it. Otherwise, your application has to tolerate the fact that what it reads might not be what another instance of that application has previously written — so with soft state databases your application needs to deal with the possibility that the data that you're reading isn't the same data that was written moments ago.

Now all of these are fairly fuzzy and do overlap but lastly we have the fact that BASE does not enforce immediate consistency — it means that it might happen eventually, if we wait long enough then what we read will match what has been previously written eventually.

Now this is important to understand because generally by default a BASE transaction model means that any reads to a database are eventually consistent — so applications do need to tolerate the fact that reads might not always have the data for previous writes. Many databases are capable of providing both eventually consistent and immediately consistent reads, but again the application has to have an awareness of this and explicitly ask the database for consistent reads.

Now it sounds like BASE transactions are pretty bad right? Well not really — databases which use BASE are actually highly scalable and can deliver really high performance because they don't have to worry about all the pesky annoying things like consistency within the database — they offload that to the applications.

Now DynamoDB within AWS is an example of a database which normally works in a BASE-like way — it offers both eventually and immediately consistent reads but your application has to be aware of that. Now DynamoDB also offers some additional features which offer ACID functionality such as DynamoDB transactions, so that's something else to keep in mind.

Now for the exam specifically I have a number of useful defaults: if you see the term BASE mentioned then you can safely assume that it means a NoSQL style database; if you see the term ACID mentioned then you can safely assume as a default that it means an RDS database — but if you see NoSQL or DynamoDB mentioned together with ACID then it might be referring to DynamoDB transactions and that's something to keep in mind.

Now that's everything I wanted to cover in this high-level lesson about the different transaction models. This topic is relatively theoretical and pretty deep and there's a lot of extra reading, but I just wanted to cover the essentials of what you need for the exam, so I've covered all of those facts in this lesson and at this point it is the end of the lesson — so thanks for watching, go ahead and complete the video, and then when you're ready I 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, there are other types of database platforms—NoSQL platforms—and this doesn't represent one single way of doing things, so I want to quickly step through some of the common examples of NoSQL databases or non-relational databases.

The first type of database in the NoSQL category that I want to introduce is key-value databases, and the title gives away the structure: key-value databases consist of sets of keys and values. There's generally no concept of structure; it's just a list of keys and value pairs. In this case, it's a key-value database for one of the animals for life rescue centers, and it stores the date and time and a sensor reading from a feeding sensor, recording the number of cookies removed from the feeder during the previous 60 minutes. So essentially, the key on the left stores the date and time, and on the right is the number of cookies eaten as detected by the sensor during the previous 60 minutes.

So that's it for this type of database—it's nothing more complex than that—it's just a list of key-value pairs. As long as every single key is unique, then the value doesn't matter. It has no real schema, nor does it have any real structure, because there are no tables or table relationships. Some key-value databases allow you to create separate lists of keys and values and present them as tables, but they're only really used to divide data—there are no links between them.

This makes key-value databases really scalable because sections of this data could be split onto different servers. In general, key-value databases are just really fast; it's simple data with no structure, and there isn't much that gets in the way between giving the data to the database and it being written to disk. For key-value databases, only the key matters—you write a value to a key and you read a value from a key.

The value is opaque to the database; it could be text, it could be JSON, it could be a cat picture—it doesn't matter. In the exam, look out for any question scenarios which present simple requirements or mention data which is just names and values or pairs or keys and values—look out for questions which suggest no structure. If you see any of these types of scenarios, then key-value stores are generally really appropriate.

Key-value stores are also used for in-memory caching, so if you see any questions in the exam that talk about in-memory caching, then key-value stores are often the right way to go, and I'll be introducing some products later in the course which do provide in-memory key-value storage.

Okay, so let's move on, and the next type of database that I want to talk about is actually a variation of the previous model—a variation on key-value—and it's called a wide column store.

Now, this might look familiar to start with. Each row or item has one or more keys; generally, one of them is called the partition key, and then optionally, you can have additional keys as well as the partition key. Now, DynamoDB, which is an AWS example of this type of database—this secondary key is called the sort or the range key. It differs depending on the database, but most examples of wide column stores generally have one key as a minimum, which is the partition key, and then optionally, every single row or item in that database can have additional keys.

Now that's really the only rigid part of a wide column store—every item in a table has to have the same key layout, so that's one key or more keys, and they just need to be unique to that table. Wide column stores offer groupings of items called tables, but they're still not the same type of tables as in relational database products—they're just groupings of data.

Every item in a table can also have attributes, but—and this is really important—they don't have to be the same between items. Remember how in relational database management systems, every table had attributes, and then every row in that table had to have a value for every one of those attributes? That is not the case for most NoSQL databases and specifically wide column stores—because that's what we're talking about now.

In fact, every item can have any attribute—it could have all of the attributes, so all of the same attributes between all of the items, it could have a mixture, so mix and matching attributes on different items, or an item could even have no attributes. There is no schema, no fixed structure on the attribute side—it’s normally partially opaque for most database operations.

The only thing that matters in a wide column store is that every item inside a table has to use the same key structure, and it has to have a unique key—so whether that's a single partition key or whether it's a composite key (a partition key and something else). If it's a single key, it has to be unique; if it's a composite key, the combination of both of those values has to be unique. That's the only rule for placing data into a table using wide column stores.

Now DynamoDB inside AWS is an example of this type of database, so DynamoDB is a wide column store. Now this type of database has many uses—it’s very fast, it’s super scalable, and as long as you don’t need to run relational operations such as SQL commands on the database, it often makes the perfect database product to take advantage of, which is one of the reasons why DynamoDB features so heavily amongst many web-scale or large-scale projects.

Okay, so let's move on. And next I want to talk about a document database, and this is a type of NoSQL database that's designed to store and query data as documents. Documents are generally formatted using a structure such as JSON or XML, but often the structure can be different between documents in the same database.

You can think of a document database almost like an extension of a key-value store, where each document is interacted with via an ID that’s unique to that document, but the value—the document contents—are exposed to the database, allowing you to interact with it. Document databases work best for scenarios like order databases or collections or contact-style databases—situations where you generally interact with the data as a document.

Document databases are also great when you need to interact with deep attributes—so nested data items within a document structure. The document model works well with use cases such as catalogs, user profiles, and lots of different content management systems where each document is unique, but it changes over time, so it might have different versions; documents might be linked together in hierarchical structures or when you're linking different pieces of content in a content management system.

For any use cases like this, document-style databases are perfect. Each document has a unique ID, and the database has access to the structure inside the document. Document databases provide flexible indexing, so you can run really powerful queries against the data that could be nested deep inside a document.

Now let’s move on. Column databases are the next type of database type that I want to discuss, and understanding the power of these databases requires knowing the limitations of their counterpart—row-based databases—which is what most SQL-based databases use. Row-based databases are where you interact with data based on rows.

So in this example, we have an orders table; it has order ID, the product ordered, color, size, and price. For every order, we have a row, and those rows are stored on disk together. If you needed to read the price of one order from the database, you read the whole row from disk. If you don’t have indexes or shortcuts, you’ll have to find that row first, and that could mean scanning through rows and rows of data before you reach the one that you want to query.

Now if you want to do a query which operates over lots of rows—for example, you wanted to query all the sizes of every order—then you need to go through all of the rows, finding the size of each. Row-based databases are ideal when you operate on rows—creating a row, updating a row, or deleting rows. Row-based databases are often called OLTP or Online Transaction Processing Databases, and they are ideal, as the name suggests, for systems which are performing transactions—so order databases, contact databases, stock databases, things which deal in rows and items where these rows and items are constantly accessed, modified, and removed.

Now column-based databases handle things very differently. Instead of storing data in rows on disk, they store it based on columns. The data is the same, but it’s grouped together on disk based on column—so every order value is stored together, every product item, every color, size, and price, all grouped by the column that the data is in.

Now this means two things. First, it makes it very, very inefficient for transaction-style processing, which is generally operating on whole rows at a time. But this very same aspect makes column databases really good for reporting, so if your queries relate to just one particular column, because that whole column is stored on disk grouped together, then that’s really efficient.

You could perform a query to retrieve all products sold during a period, or perform a query which looks for all sizes sold in total ever and looks to build up some intelligence around which are sold most and which are sold least. With column store databases, it’s really efficient to do this style of querying—reporting style querying.

An example of a column-based database in AWS is Redshift, which is a data warehousing product, and that name gives it away. Generally what you’ll do is take the data from an OLTP database—a row-based database—and you’ll shift that into a column-based database when you’re wanting to perform reporting or analytics. So generally, column store databases are really well suited to reporting and analytics.

Now lastly I want to talk about graph-style databases. Earlier in the lesson I talked about tables and keys and how relational database systems handle the relationships by linking the keys of different tables. Well with graph databases, relationships between things are formally defined and stored in the database itself along with the data—they’re not calculated each and every time you run a query—and this makes them great for relationship-driven data, for example social media or HR systems.

Consider this data: three people, two companies, and a city—these are known as nodes inside a graph database. Nodes and nouns—so objects. Nodes can have properties which are simple key-value pairs of data, and these are attached to the nodes.

So far, this looks very much like a normal database—nothing is new so far. But with graph databases, there are also relationships between the nodes, which are known as edges. Now these edges have a name and a direction—so Natalie works for XYZ Corp, and Greg works for both XYZ Corp and Acme Widgets. Relationships themselves can also have attached data—so name-value pairs. In this particular example, we might want to store the start date of any employment relationship.

A graph database can store a massive amount of complex relationships between data or between nodes inside a database—and that’s what’s key. These relationships are actually stored inside the database as well as the data. A query to pull up details on all employees of XYZ Corp would run much quicker than on a standard SQL database because that data of those relationships is just being pulled out of the database just like the actual data.

With a relational-style database, you’d have to retrieve the data, and the relationships between the tables is computed when you execute the query—so it’s a really inefficient process with relational database systems. These relationships are fixed and computed each and every time a query is run.

With a graph-based database, those relationships are fluid, dynamic—they’re stored in the database along with the data—and it means when you’re interacting with data and looking to take advantage of these fluid relationships, it’s much more efficient to use a graph-style database.

Now using graph databases is very much beyond the scope of this course, but I want you to be aware of it because you might see questions in the exam which mention the technology, and you need to be able to identify or eliminate answers based on the scenario—based on the type of database that the question is looking to implement.

So if you see mention of social media in an exam or systems with complex relationships, then you should think about graph databases first.

Now that's all I wanted to cover in this lesson. I know it's been abstract and high level—I wanted to try and make it as brief as possible. I know I didn’t really succeed because we had a lot to cover, but I want this to be a foundational set of theory that you can use throughout the databases section, and it will help you in the exam.

For now though, that's everything I wanted to cover in this lesson, so go ahead complete the video and when you're ready you can join me in the next.

Welcome back and in this first technical lesson of this section of the course, I wanted to provide a quick fundamentals lesson on databases; if you already have database experience then you can play me on super fast speed and think of this lesson as a good confirmation of the skills that you already have, but if you don't have database experience though, that's okay, as this lesson will introduce just enough knowledge to get you through the course and I'll include additional reading material to get you up to speed with databases in general.

Now we do have a fair amount to get through so let's jump in and get started: databases are systems which store and manage data, but there are a number of different types of database systems and crucial differences between how data is physically stored on disk and how it's managed on disk and in memory, as well as how the systems retrieve data and present it to the user.

Database systems are very broadly split into relational and non-relational; relational systems are often referred to as SQL or SQL, though this is actually wrong because SQL is a language which is used to store, update and retrieve data, and it's known as the structured query language and it's a feature of most relational database platforms.

Strictly speaking, it's different than the term relational database management system, but most people use the two interchangeably, so if you see or hear the term SQL or RDBMS which is relational database management system, they're all referring to relational database platforms and most people use them interchangeably.

Now one of the key identifiable characteristics of relational database systems is that they have a structure to their data, so that's inside and between database tables and I'll cover that in a moment: the structure of a database table is known as a schema and with relational database systems it's fixed or rigid, meaning it's defined in advance before you put any data into the system.

A schema defines the names of things, valid values of things and the types of data which are stored and where; more importantly, with relational database systems there's also a fixed relationship between tables, so that's fixed and also defined in advance before any data is entered into the system.

Now no SQL on the other hand—well let's start by making something clear: no SQL isn't one single thing, as no SQL as the name suggests is everything which doesn't fit into the SQL mold, everything which isn't relational, but that represents a large set of alternative database models which I'll cover in this lesson.

One common major difference which applies to most no SQL database models is that generally there is a much more relaxed concept of a schema, so generally they all have weak schemers or no schemers and relationships between tables are also handled very differently.

Both of these impact the situations that a particular model is right for and that's something that you need to understand at a high level for the exam and also when you're picking a database model for use in the real world.

Before I talk about the different database models I wanted to visually give you an idea of how relational database management systems known as RDBMSs or SQL systems conceptualize the data that you store within them: consider an example of a simple PET database where you have three humans and for those three humans you want to record the PETs that those humans are owned by.

The key component of any SQL based database system is a table, and every table has columns and these are known as attributes; the column has a name—its attribute name—and then within each row of that table each column has to have a value, and this is known as the attribute value.

So in this table for example the columns are f name, first name, l name, last name and age, and then for each of the rows 1, 2 and 3 the row has an attribute value for each of the columns, so each of the attributes which are the columns have an attribute value in each row.

Now generally the way that data is modeled in a relational database management system or a SQL database system is that data which relates together is stored within a table, so in this case all of the data on the humans is stored within one table.

Every row in the table has to be uniquely identifiable and so we define something that's known as a primary key, which is unique in the table and every row of that table has to have a unique value for this attribute.

So note in this table how every row has a unique value 1, 2 and 3 for this primary key; now with this database model we've also got a similar table for the animals—so we've got whiskers and woofy—and they also have a primary key that's been defined which is the animal or AID.

And this primary key on this table also has to have a unique value in every row on the table, so in this case whiskers is animal ID 1 and woofy is animal ID 2.

Each table in a relational database management system can have different attributes, but for a particular table every row in that table needs to have a value stored for every attribute in that table, so see how the animals table has name and types whereas the human table has first name, last name and age.

But note how in both tables for every row every attribute has to have a value, and because SQL systems are relational we generally define relationships between the tables.

Now this is a join table and it makes it easy to have many to many relationships, so a human could have many animals and each animal can have many human minions.

A join table has what's known as a composite key which is a key formed of two parts, and for composite keys together they have to be unique, so notice how the second and third rows have the same animal ID—that's fine because the human ID is different—and as long as the composite key in its entirety is unique that's also fine.

Now the keys in different tables are how the relationships between the tables are defined, so in this example the human table has a relationship with the join table, and it allows each human to have multiple animals and each animal to have multiple humans.

In this example the animal ID of two which is woofy is linked to human ID two and three which is Julie and James; they're both woofies minions because that doggo needs double the amount of tasty treats.

Now all these keys and the relationships are defined in advance and this is done using the schema—it's fixed and it's very difficult to change after the first piece of data goes in.

The fact that this schema is so fixed and has to be declared in advance makes it difficult for a sequel or a relational system to store any data which has rapidly changing relationships, and a good example of this is a social network such as Facebook where relationships change all the time.

So this is a simple example of a relational database system—it generally has multiple tables, a table stores data which is related, so humans and animals, tables have fixed schemas, they have attributes, they have rows, each row has a unique primary key value and has to contain some value for all of the attributes in the table, and in those tables they have relationships between each other which are also fixed and defined in advance.

So this is sequel, this is relational database modelling.

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, and part two will be continuing immediately from the end of part one, so go ahead complete the video and when you're ready join me in part two.

Welcome back and in this lesson I want to talk through how we implement DNSSEC using Route 53. Now if you haven't already watched my DNS and DNSSEC fundamentals video series you should pause this video and watch those before continuing. Assuming that you have let's jump in and get started.

Now you should be familiar with this architecture—this is how Route 53 works normally. In this example I'm using the animalsforlive.org domain, so a query against this would start with our laptop, go to a DNS resolver, then to the root servers looking for details of the .org top-level domain, and then it would go to the .org top-level domain name servers looking for animalsforlive.org, and then it would proceed to the four name servers which are hosting the animalsforlive.org zone using Route 53.

On the right-hand side here we have an AWS VPC using the plus two address, which is the Route 53 resolver, and those instances can query the animalsforlive.org domain from inside the VPC.

Now enabling DNSSEC on a Route 53 hosted zone is done from either the Route 53 console UI or the CLI, and once initiated the process starts with KMS. This part can either be done separately or as part of enabling DNSSEC signing for the hosted zone, but in either case, an asymmetric key pair is created within KMS, meaning a public part and a private part. Now you can think of these conceptually as the key signing keys or KSKs, but in actual fact, the KSK is created from these keys; these aren't the actual keys, but this is a nuance which isn't required at this level.

So these keys are used to create the public and private key signing keys which Route 53 uses, and these keys need to be in the US East 1 region—that's really important, so keep that in mind. Next, Route 53 creates the zone signing keys internally; this is really important to understand—both the creation and the management of the zone signing keys is handled internally within Route 53, and KMS isn't involved.

Next, Route 53 adds the key signing key and the zone signing key public parts into a DNS key record within the hosted zone, and this tells any DNSSEC resolvers which public keys to use to verify the signatures on any other records in this zone. Next, the private key signing key is used to sign those DNS key records and create the RRSIG DNS key record, and these signatures mean that any DNSSEC resolver can verify that the DNS key records are valid and unchanged.

Now at this point that's signing within the zone configured, which is step one. Next, Route 53 has to establish the chain of trust with the parent zone—the parent zone needs to add a DS record or delegated signer record, which is a hash of the public part of the key signing key for this zone, and so we need to make this happen.

Now how we do this depends on if the domain is registered via Route 53; if so, the registered domains area of the Route 53 console or the equivalent CLI command can be used to make this change, and Route 53 will liaise with the appropriate top-level domain and add the delegated signer record.

Now if we didn't register the domain using Route 53 and are instead just using it to host the zone, then we're going to need to perform this step manually. Once done, the top-level domain—in this case .org—will trust this domain via the delegated signer record, which, as I mentioned, is a hash of the domain's public key signing key, and the domain zone will sign all records within it either using the key signing or zone signing keys.

As part of enabling this, you should also make sure to configure CloudWatch alarms—specifically, create alarms for DNSSEC internal failure and DNSSEC key signing keys needing action, as both of these indicate a DNSSEC issue with the zone which needs to be resolved urgently, either an issue with the key signing key itself or a problem interacting with KMS.

Lastly, you might want to consider enabling DNSSEC validation for VPCs; this means for any DNSSEC enabled zones, if any records fail validation due to a mismatch signature or otherwise not being trusted, they won't be returned—this doesn't impact non-DNSSEC enabled zones, which will always return results, and this is how to work with the Route 53 implementation of DNSSEC.

What I wanted to do now is step you through an actual implementation of DNSSEC for a hosted zone within Route 53, and to do that we're going to need to move across to my AWS console. Okay, so now we're at the AWS console, and I'm going to step you through an example of enabling DNSSEC on a Route 53 domain, and to get started I'm going to make sure I'm in an AWS account where I have admin permissions.

In this case, I'm logged in as the IAM admin user, which is an IAM identity with admin permissions. As always, I'm going to make sure that I have the Northern Virginia region selected, and once I've done that, I'm going to go ahead and open Route 53 in a new tab.

In my case, it's already inside recently visited services; if it's not, you can just search for it in the search box at the top, but I'm going to go ahead and open Route 53. So I'm going to go to the Route 53 console and click on hosted zones, and in my case, I've got two hosted zones—animalsforlife.org and animalsforlife1337.org—and I'm going to go ahead and DNSSEC enable animalsforlife.org, so I'm going to go ahead and go inside this hosted zone.

Now if I just go ahead and move across to my command prompt and if I run this command—so dig animalsforlife.org DNSKEY +dnssec—this will query this domain attempting to look for any DNSKEY records using DNSSEC, and as you can see, there are no DNSSEC results returned, which is logical because this domain is not enabled for DNSSEC.

So moving back to this console, I'm going to click on DNSSEC signing under the domain and then click on enable DNSSEC signing. Now if this were a production domain, the order of these steps really matters, and you need to make sure that you wait for certain time periods before conducting each of these steps—specifically, you need to make sure that you're making changes taking into consideration the TTL values within your domain.

I'll include a link attached to this video which details all of these time-critical prerequisites that you need to make sure you consider before enabling DNS signing. In my case, I don't need to worry about that because this is a fresh, empty domain.

The first thing we're going to do is create a key signing key, and as I mentioned earlier in this video, this is done using a KMS key. So the first thing I'm going to do is to specify a KSK name—a key signing key name—and I'm going to call it A4L-KSK for Animals for Life key signing key.

Next you'll need to decide on which key to use within KMS to create this key signing key. Now unfortunately the user interface is a little bit inconsistent—AWS have decided to rename CMKs to KMS keys—so you might see the interface looking slightly different when you're doing this video.

Regardless, you need to create a KMS key, so check the box saying create customer managed CMK or create KMS key depending on what state the user interface is in, and you'll need to give a name to this key—again, this is creating an asymmetric KMS key—so I'm going to call it A4L-KSK-KMS-Key, and once I've done that, I can go ahead and click on create KSK and enable signing.

Now behind the scenes this is creating an asymmetric KMS key and using this to create the key signing key pair that this hosted zone is going to use. Now this part of the process can take a few minutes, and so I'm going to skip ahead until this part has completed.

Okay so that's completed, and that means that we now have an active key signing key within this hosted zone, and that means it's also created a zone signing key within this hosted zone.

If I go back to my terminal and I rerun this same command and press enter, you'll see that we still get the same empty results, and this can be because of caching—so I need to wait a few minutes before this will update. If I run it again now, we can see for the same query it now returns DNSKEY records—so one for 256 which represents the zone signing key (the public part of that key pair), and one for 257 which represents the key signing key (again the public part of that key pair), and then we have the corresponding RRSIG DNSKEY record which is a signature of these using the private key signing key.

So now internally we've got DNSSEC signing enabled for this hosted zone, and what we need to do now is create the chain of trust with the parent zone—in this case the .org top-level domain.

Now to do that, because I've also registered this domain using Route 53, I can do that from the registered domains area of the console, so I'll open that in a brand new tab. I'm going to go there, and then I'm going to go to the animalsforlife.org registered domain, and this is the area of the console where I can make changes, and Route 53 will liaise with the .org top-level domain and enter those changes into the .org zone.

Now the area that I'm specifically interested in is the DNSSEC status—currently this is set to disabled. What I'm going to do is to click on manage keys, and it's here where I can enter the public key—specifically, it's going to be the public key signing key of the animalsforlife.org zone—and I'm going to enter it so that it creates the delegated signer record in the .org domain which establishes this chain of trust.

So first I'm going to change the key type to KSK, then I'm going to go back to our hosted zone and I'm going to click on view information to create DS record, then I'm going to expand establish a chain of trust, and depending on what type of registrar you used you either need to follow the bottom instructions or these if you used Route 53—and I did, so I can go ahead and use the Route 53 registrar details.

Now the first thing you need to do is to make sure that you're using the correct signing algorithm—so it's ECDSAP256SHA256—so I'm going to go ahead and move back to the registered domains console, click on the algorithm drop-down, and select the matching signing algorithm: ECDSAP256SHA256.

Next I'll go back and I'll need to copy the public key into my clipboard—so remember a delegated signer record is just a hash of the public part of the key signing key—so this is what I'm copying into my clipboard, this is the public key of this key signing key.

So I'm going to go back and paste this in and then click on add. Now this is going to initiate a process where Route 53 are going to make the changes to the animalsforlife.org part of the .org top-level domain zone.

So specifically, in the .org top-level domain zone, there's going to be an entry for animalsforlife.org—by default, for normal DNS, this is going to contain name server records which delegate through to Route 53—what this process is going to do is also add a DS record which is a delegated signer record and it is going to contain a hash of this public key.

So now we have an end-to-end chain of trust from the DNS root all the way through to this resource record. This means any DNSSEC-enabled resolver can verify not just the domain-level DNSKEY and RRSIG records, but also any signed individual records like the A record we just created, ensuring integrity and authenticity from top to bottom.

That’s everything I wanted to cover in this video. I just wanted to give you a comprehensive overview of how to implement DNSSEC within Route 53—covering both the theoretical background and practical implementation steps to get it up and running. At this point, that’s the end of the video, so go ahead and complete the video, and when you’re ready, I’ll look forward to you joining me in the next one.

Welcome back and in this video I want to cover Route 53 interoperability, and what I mean by that is using Route 53 to register domains or to host zone files when the other part of that is not with Route 53. Generally both of these things are performed together by Route 53 but it's possible for Route 53 just to do one or the other, so let's start by stepping through exactly what I mean.

When you register a domain using Route 53 it actually does two jobs at the same time, and while these two jobs are done together, conceptually they're two different things. Route 53 acts as a domain registrar and it provides domain hosting, so it can do both which is what happens initially when you register a domain, or it can be a domain registrar alone or it can host domains alone. It might only do one of them if, for example, you register a domain elsewhere and you want to use it with Route 53, and I want to take the time in this video to explain those edge case scenarios.

So let's quickly step through what happens when you register a domain using Route 53: first it accepts your money, the domain registration fee, which is a one-off fee or more specifically a once-a-year or once-every-three-year fee for actually registering the domain. Next it allocates for Route 53 DNS servers called name servers, then it creates a zone file which it hosts on the four name servers that I've just talked about, so that's the domain hosting part—allocating those servers and creating and hosting the zone file. If you hear me mention domain hosting, that's what it means.

Then once the domain hosting is sorted, Route 53 communicates with the registry for the specific top level domain that you're registering your domain within, so they have a relationship with the registry. So Route 53 is acting as the domain registrar, the company registering the domain on your behalf with the domain registry, and the domain registry is the company or entity responsible for the specific top level domain. So Route 53 gets the registry to add an entry for the domain, say for example animalsforlife.org, and inside this entry it adds four name server records and it points these records at the four name servers that I've just been talking about—this is the domain registrar part.

So the registrar registers the domain on your behalf, that's one duty, and then another entity provides DNS or domain hosting, and that's another duty. Often these are both provided by Route 53 but they don't have to be, so fix in your mind these two different parts: the registrar, which is the company who registers the domain on your behalf, and the domain hosting, which is how you add and manage records within hosted zones.

So let's step through this visually, looking at a few different options. First we have a traditional architecture where you register and host a domain using Route 53, so on the left conceptually we have the registrar role and this is within the registered domains area of the Route 53 console, and on the right we have the DNS hosting role and this is managed in the public hosted zone part of the Route 53 console.

So step one is to register a domain within Route 53—let's assume that it's the animalsforlife.org domain—so you liaise with Route 53 and you pay the fee required to register a domain, which is a per year or per three year fee. Now assuming nobody else has registered the domain before, the process continues: first the Route 53 registrar liaisers with the Route 53 DNS hosting entity and it creates a public hosted zone which allocates for Route 53 name servers to host that zone, which are then returned to the registrar.

I want to keep driving home that conceptually the registrar and the hosting are separate functions of Route 53 because it makes everything easier to understand. Once the registrar has these four name servers, it passes all of this along through to the .org top level domain registry, and the registry is the manager of the .org top level domain zone file, and it's via this entity that records are created in the top level domain zone for the animalsforlife.org domain. So entries are added for our domain which point at the four name servers which are created and managed by Route 53, and that's how the domain becomes active on the public DNS system.

At this point we've paid once for the domain registration to the registrar, which is Route 53, and we also have to pay a monthly fee to host the domain, so the hosted zone, and with this architecture this is also paid to Route 53. So this is a traditional architecture and this is what you get if you register and host a domain using Route 53, and this is a default configuration. So when you register a domain, while you might see it as one step, it's actually two different steps done by two different conceptual entities: the registrar and the domain hoster, and it's important to distinguish between these two whenever you think about DNS.

But now let's have a look at two different configurations where we're not using Route 53 for both of these different components. This time Route 53 is acting as a registrar only, so we still pay Route 53 for the domain, they still liaise on our behalf with the registry for the top level domain, but this time a different entity is hosting the domain, so the zone file and the name servers, and let's assume for this example it's a company called Hover.

This architecture involves more manual steps because the registrar and the DNS hosting entity are separate, so as the DNS admin you would need to create a hosted zone. The third party provider would generally charge a monthly fee to host that zone on name servers that they manage, and you would need to get the details of those servers once it's been created and pass those details on to Route 53, and Route 53 would then liaise with the .org top level domain registry and set those name server records within the domain to point at the name servers managed in this case by Hover.

With this configuration, which I'll admit I don't see all that often in the wild, the domain is managed by Route 53 but the zone file and any records within it are managed by the third party domain hosting provider, in this case Hover. Now the reason why I don't think we see this all that often in the wild is the domain registrar functionality that Route 53 provides—it's nothing special. With this architecture you're not actually using Route 53 for domain hosting, and domain hosting is the part of Route 53 which adds most of the value. If anything, this is the worst way to manage domains.

Let's look at another more popular architecture which I see fairly often in the wild, and that's using Route 53 for domain hosting only. Now you might see this either when a business needs to register domains via a third party provider—maybe they have an existing business deal or business discount—or you might have domains which have already been historically registered with another provider and where you want to get the benefit that Route 53 DNS hosting provides.

With this architecture the domain is registered via a third party domain registrar, in this case Hover, so it's the registrar in this example who liais with the top level domain registry, but we use Route 53 to host the domain. So at some point, either when the domain is being created or afterwards, we have to create a public hosted zone within Route 53—this creates the zone and the name servers to host the zone, obviously for a monthly fee.

So once this has been created we pass those details through to the registrar, who liais with the registry for the top level domain, and then those name server records are added to the top level domain meaning the hosted zone is now active on the public internet. Now it's possible to do this when registering the domain, so you could register the domain with Hover and immediately provide Route 53 name servers, or you might have a domain that's been registered years ago and you now want to use Route 53 for hosting and record management.

So you can use this architecture either while registering a domain or after the fact by creating the public hosted zone and then updating the name server records in the domain via the third party registrar and then the dot org registry. Now I know that this might seem complex, but if you just keep going back to basics and thinking about Route 53 as two things, then it's much easier.

Route 53 offers a component which registers the domain—so this is the registrar—and it also offers a component which hosts the zone files and provides managed DNS name servers. If you understand that both of those are different things, and when you normally register a domain using Route 53 both of them are being used, a hosted zone is created for you and then via the registrar part it's added to the domain record by the top level domain registry. If you understand that—so see these as two completely different components—then it's easy to understand how you can use Route 53 for only one of them and a separate third-party company for the other.

Now generally I think Route 53 is one of the better DNS providers on the market, and so generally for my own domains I will use Route 53 for both the registrar and the domain hosting components, but depending on your architecture, depending on any legacy configuration, you might have a requirement to use different entities for these different parts, and that's especially important if you're a developer looking at writing applications that take advantage of DNS, or if you're an engineer looking to implement or fault find these type of architectures.

Now with that being said, that's everything I wanted to cover in this theory video—I just wanted to give you a brief overview of some of the different types of scenarios that you might find in more complex Route 53 situations. At this point, go ahead and complete this video, and when you're ready, I'll look forward to you joining me in the next.

Welcome back and in this video I want to talk about Geoproximity routing which is another routing policy available within Route 53. So let's just jump in and get started.

Geoproximity aims to provide records which are as close to your customers as possible. If you recall, latency based routing provides the record which has the lowest estimated latency between your customer and the region that the record is in. Geoproximity aims to calculate the distance between a customer and a record and answer with the lowest distance. Now it might seem similar to latency, but this routing policy works on distance and also provides a few key benefits which I'll talk about in this video.

When using Geoproximity, you define rules—so you define the region that a resource is created in if it's an AWS resource, or provide the latitude and longitude coordinates if it's an external resource. You also define a bias, but more on that in a second.

Let's say that you have three resources: one in America, one in the UK, and one in Australia. Well, we can define rules which mean that requests are routed to those resources. If these were resources in AWS, we could define the region that the resources were located in—so maybe US East 1 or AP South East 2. If the resources were external, so non-AWS resources, we could define their location based on coordinates, but in either case Route 53 knows the location of these resources. It also knows the location of the customers making the requests, and so it will direct those requests at the closest resource.

Now we're always going to have some situations where customers in countries without any resources are using our systems—in this case Saudi Arabia, which is over 10,000 kilometers away from Australia and about 6,700 kilometers away from the UK. Under normal circumstances, this would mean that the UK resource would be returned for any users in Saudi Arabia. What geo proximity allows us to do though is to define a bias, so rather than just using the actual physical distance, we can adjust how Route 53 handles the calculation.

We can define a plus or minus bias. So for example, with the UK we might define a plus bias, meaning the effective area of service for the UK resource is increased larger than it otherwise would be. And we could do the same for the Australian resource but maybe providing a much larger plus bias. Now routing is distance based but it includes this bias, so in this case we can influence Route 53 so that customers from Saudi Arabia are routed to the Australian resource rather than the UK one.

Geo proximity routing lets Route 53 route traffic to your resources based on the geographic location of your users and your resources, but you can optionally choose to route more traffic or less traffic to a given resource by specifying a value. The value is called a bias. A bias expands or shrinks the size of a geographic region that is used for traffic to be routed to, so even in the example of the UK where it's just a single relatively small country, by adding a plus bias we can effectively make the size larger so that more surrounding countries route towards that resource.

In the case of Australia, by adding an even larger bias, we can make it so that countries even in the Middle East route towards Australia rather than the closer resource in the UK. So geo proximity routing is a really flexible routing type that not only allows you to control routing decisions based on the locations of your users and resources, it also allows you to place a bias on these rules to influence those routing decisions.

So this is a really important one to understand and it will come in really handy for a certain set of use cases. Now thanks for watching. That's everything that I wanted to cover in this video. 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 geolocation routing which is another routing policy available within Route 53. Now this is going to be a pretty brief video so let's jump in and get started.

In many ways geolocation routing is similar to latency, only instead of latency, the location of customers and the location of resources are used to influence resolution decisions. With geolocation routing, when you create records you tag the records with the location. Now this location is generally a country, so using ISO standard country codes, it can be continents—again using ISO continent codes such as SA for South America in this case—or records can be tagged with default. Now there's a fourth type which is known as a subdivision; in America you can tag records with the state that the record belongs to.

Now when a user is making a resolution request, an IP check verifies the location of the user. Depending on the DNS system, this can be the user directly or the resolver server, but in most cases these are one and the same in terms of the user's location. So we have the location of the user and we have the location of the records. What happens next is important because geolocation doesn't return the closest record, it only returns relevant records.

When a resolution request happens, Route 53 takes the location of the user and it starts checking for any matching records. First, if the user doing the resolution request is based in the US, then it checks the state of the user and it tries to match any records which have a state allocated to them. If any records match, they're returned and the process stops. If no state records match, then it checks the country of the user. If any records are tagged with that country, then they're returned and the process stops. Then it checks the continent; if any records match the continent that the user is based in, then they're returned and the process stops.

Now you can also define a default record which is returned if no record is relevant for that user. If nothing matches though—so there are no records that match the user's location and there's no default record—then a no answer is returned. So to stress again, this type of routing policy does not return the closest record, it only returns any which are applicable or the default, or it returns no answer.

So geolocation is ideal if you want to restrict content—for example, providing content for the US market only. If you want to do that, then you can create a US record and only people located in the US will receive that record as a response for any queries. You can also use this policy type to provide language specific content or to load balance across regional endpoints based on customer location.

Now one last time, because this is really important for the exam and for real world usage: this routing policy type is not about the closest record—geolocation returns relevant locations only. You will not get a Canadian record returned if you're based in the UK and no closer records exist. The smallest type of record is a subdivision which is a US state, then you have country, then you have continent, and finally optionally a default record. Use the geolocation routing policy if you want to route traffic based on the location of your customers.

Now it's important that you understand—which is why I've stressed this so much—that geolocation isn't about proximity, it's about location. You only have records returned if the location is relevant. So if you're based in the US but are based in a different state than a record, you won't get that record. If you're based in the US and there is a record which is tagged as the US as a country, then you will get that record returned. If there isn't a country specific record but there is one for the continent that you're in, you'll get that record returned, and then the default is a catchall. It's optional; if you choose to add it, then it's returned if your user is in a location where you don't have a specific record tagged to that location.

Now that's everything that 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 and in this video I want to talk about latency based routing which is yet another routing policy available within Route 53. So let's jump in and get started.

Latency based routing should be used when you're trying to optimize for performance and user experience, when you want Route 53 to return records which can provide better performance. So how does it work? Well it starts with a hosted zone within Route 53 and some records with the same name. So in this case www, three of those records, they're A records and so they point at IP addresses. In addition, for each of the records you can specify a record region—so US East 1, US West 1, and AP Southeast 2 in this example. Latency based routing supports one record with the same name for each AWS region. The idea is that you're specifying the region where the infrastructure for that record is located.

Now in the background AWS maintains a database of latencies between different regions of the world. So when a user makes a resolution request it will know that that user is in Australia in this example. It does this by using an IP lookup service, and because it has a database of latencies, it will know that a user in Australia will have a certain latency to US East 1, a certain latency to US West 1, and hopefully the lowest latency to a record which is tagged to be in the Asia Pacific region—so AP Southeast 2. So that record is selected and it's returned to the user and used to connect to resources.

Latency based routing can also be combined with health checks. If a record is unhealthy, then the next lowest latency is returned to the client making the resolution request. This type of routing policy is designed to improve performance for global applications by directing traffic towards infrastructure with the best, so lowest latency, for users accessing that application.

It's worth noting though that the database which AWS maintain isn't real time. It's updated in the background and doesn't really account for any local networking issues, but it's better than nothing and can significantly help with performance of your applications.

Now that's all of the theory that I wanted to cover about latency based routing, so go ahead and complete the video, and when you're ready I look forward to you joining me in the next.

Welcome back. In this video I want to talk about weighted routing, which is another routing policy available within Route 53. So let's jump in and get started straight away.

Weighted routing can be used when you're looking for a simple form of load balancing or when you want to test new versions of software. Like all other types of routing policy, it starts with a hosted zone and in this hosted zone— you guessed it—records. In this case, three www records. Now these are all A records and so they point at IP addresses, and let's assume that these are three EC2 instances.

With weighted routing, you're able to specify a weight for each record and this is called the record weight. Let's assume 40 for the top record, 40 for the middle, and 20 for the record at the bottom. Now how this record weight works is that for a given name—www in this case—the total weight is calculated. So 40 plus 40 plus 20 for a total of 100. Each record then gets returned based on its weighting versus the total weight. So in this example, it means that the top record is returned 40% of the time, the middle also 40% of the time, and the bottom record gets returned 20% of the time.

Setting a record weight to zero means that it's never returned, so you can do this if temporarily you don't want a particular record to be returned—unless all of the records are set to zero, in which case they're all returned. So any of the records with the same name are returned based on its weight versus the total weight. Now I've kept this example simple by using record weights that total 100 so it makes it easy to view them as percentages, but the same formula is used regardless. An individual record is returned based on its weight versus the total weight.

Now you can combine weighted routing with health checks, and if you do so, when a record is selected based on the above weight calculation, if that record is unhealthy then the process repeats. It's skipped over until a healthy record is selected and then that one's returned. Health checks don't remove records from the calculation and so don't adjust the total weight. The process is followed normally, but if an unhealthy record is selected to be returned, it's just skipped over and the process repeats until a healthy record is selected.

Now weighted routing, as I mentioned at the start, is great for very simple load balancing or when you want to test new software versions. If you want to have 5% of resolution requests go to a particular server which is running a new version of Catergram, then you have that option. So weighted routing is really useful when you have a group of records with the same name and want to control the distribution—so the amount of time that each of them is returned in response to queries.

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

Welcome back. In this video, I want to talk about multivalue routing, which is another routing policy available within Route 53. So let's jump in and get started.

Multivalue routing, in many ways, is like a mixture between simple and failover, taking the benefits of each and merging them into one routing policy. With multivalue routing, we start with a hosted zone, and you can actually create many records all with the same name. In this case, we have three www records, and each of those records in this example is an A record, which maps onto an IP address.

Each of the records, when using this routing type, can have an associated health check. When queried, up to eight healthy records are returned to the client. If you have more than eight records, then eight are selected at random. At that point, the client picks one of those values and uses it to connect to the resource.

Because each of the records is health checked, any of the records which fail the check—such as the bottom record in this example—won’t be returned to the client and won’t be selected when connecting to resources. This helps improve reliability and ensures that only healthy endpoints are used.

Multivalue routing aims to improve availability by allowing a more active-active approach to DNS. You can use it if you have multiple resources which can all service requests and you want to select one at random. It’s not a substitute for a load balancer, which handles the actual connection process from a network perspective, but the ability to return multiple health-checkable IP addresses is a way to use DNS to improve the availability of an application.

To summarize: simple routing has no health checks and is generally used for a single resource such as a web server. Failover is used for active-backup architectures, commonly with an S3 bucket as a backup. Multivalue is used when you have many resources that can all handle requests and you want them all health checked and returned at random. Any healthy records will be returned to the client, and if you have more than eight, they’ll be returned randomly.

OK, so that’s everything for this type of routing policy. Go ahead and complete the video when you’re ready, and I’ll look forward to you joining me in the next video.

Welcome back and in this video I want to talk about the second Route 53 routing policy that I'm going to be covering in this series of videos and that's fail over routing. Now let's just jump in and get started straight away.

With fail over routing we start with a hosted zone and inside this hosted zone a www.record. However with fail over routing we can add multiple records of the same name, a primary and a secondary.

Each of these records points at a resource and a common example is an out of band failure architecture where you have a primary application endpoint such as an EC2 instance and a backup or fail over resource using a different service such as an S3 bucket.

The key element to fail over routing is the inclusion of a health check. The health check generally occurs on the primary record. If the primary record is healthy then any queries to www in this case resolve to the value of the primary record which is the EC2 instance running category in this example. If the primary record fails its health check then the secondary value of the same name is returned in this case the S3 bucket.

The use case for fail over routing is simple. Use it when you need to configure active passive fail over where you want to route traffic to a resource when that resource is healthy or to a different resource when the original resource is failing its health check.

Now this is a fairly simple concept that you'll be experiencing yourself in a demo video which is coming up very soon but at this point that's everything that 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. In this video, I want to cover the Health Check feature within Route 53. Health checks support many of the advanced architectures of Route 53, and so it's essential that you understand how they work as an architect, developer, or engineer. So let's jump in and get started.

First, let's quickly step through some high-level concepts of Health checks. Health checks are separate from but are used by records inside Route 53. You don't create the checks within records. Health checks exist separately. You configure them separately. They evaluate something's health, and they can be used by records within Route 53.

Health checks are performed by a fleet of health checkers, which are distributed globally. This means that if you're checking the health of systems which are hosted on the public internet, then you need to allow these checks to occur from the health checkers. If you think they're bots or exploit attempts and block them, then it will cause false alarms. Health checks, as I just indicated, are not just limited to AWS targets. You can check anything which is accessible over the public internet. It just needs an IP address.

The checks occur every 30 seconds by default, or this can be increased to every 10 seconds at an additional cost. The checks can be TCP checks, where Route 53 tries to establish a TCP connection with the endpoint, and this needs to be successful within 10 seconds. You can have HTTP checks, where Route 53 must be able to establish a TCP connection with the endpoint within 4 seconds, and in addition, the endpoint must respond with an HTTP status code in the 200 range or 300 range within 2 seconds after connecting. And this is more accurate for web applications than a simple TCP check.

And finally, with HTTP and HTTPS checks, you can also perform string matching. Route 53 must be able to establish a TCP connection with the endpoint within 4 seconds, and the endpoint must respond with an HTTP status code in the 200 or 300 range within 2 seconds, and Route 53 health checker, when it receives the status code, it must also receive the response body from the endpoint within the next 2 seconds. Route 53 searches the response body for the string that you specify. The string must appear entirely in the first 5,120 bytes of the response body, or the endpoint fails the health check. This is the most accurate because not only do you check that the application is responding using HTTP or HTTPS, but you can also check the content of that response versus what the application should do in normal circumstances.

Based on these health checks, an endpoint is either healthy or unhealthy. It moves between those states based on its health, based on the checks conducted. Now lastly, the checks themselves can be one of 3 types. You can have endpoint checks, and these are checks which assess the health of an actual endpoint that you specify. You can use CloudWatch alarm checks, which react to CloudWatch alarms that can be configured separately and can involve some detailed in OS or in-app tests if you use the CloudWatch agent, which we cover elsewhere in the course. Finally, checks can be what's known as calculated checks, so checks of other checks. So you can create health checks which check application-wide health with lots of individual components.

Now, you're going to get the opportunity to actually implement a health check in a demo lesson, which is coming up very shortly in this section of the course. But what I want to do before that is to just give you an overview of exactly how the console looks when you're creating a health check. So let's move across to the console.

Okay, so we're at the AWS console, logged in to the general account in the Northern Virginia region. So to create a health check, we need to move to the Route 53 console, so I'm going to go ahead and do that. Remember how earlier in the theory component of this lesson, I mentioned how health checks are created externally from records? So rather than going into a hosted zone, selecting a record, and configuring a health check there, to create a health check, we go to the menu on the left and click on health checks. Then we'll click on create health check, and this is where we enter the information required to create the health check.

First, we need to give it a name, so let's just say that we use the example of test health check. I mentioned that there are three different types of health checks. We've got an endpoint health check, and this checks the health of the particular endpoint. We can use the status of other health checks, so this is a calculated health check, and as I mentioned, this allows you to create a health check which monitors the application as a whole and involves the health status of individual application components, and then finally we can use the status of a CloudWatch alarm to form the basis of this health check.

If we select endpoint for now, then you're able to pick either IP address or domain name. So you can specify the domain name of an application endpoint or you can use an IP address. If you pick domain name, then what this configures is that all of the Route 53 health checkers will resolve this domain name first and then perform a health check on the resulting IP address.

Now, in either case, you've got the option of either picking TCP, which does a simple TCP check, in which case you need to specify either the IPv4 or IPv6 address together with a port number. If you choose to use the more extensive HTTP or HTTPS health check, then you're asked to specify the same IP address and port number, so that will be used to establish the TCP connection. You can also specify the host name, and if you specify that, it will pass this value to the endpoint as a host header. So if you've got lots of different virtual hosts configured, then this is how you can specify a particular host that the website should deliver.

You're also able, because this is HTTP, you can specify a path to use for this health check. You can either specify the route path or you can specify a particular path to check. If you change this to HTTPS, then all of this information is the same, only this time it will use secure HTTP rather than normal HTTP.

Now, if we scroll down and expand advanced configuration, it's here where you can select the request interval, so the default is every 30 seconds, or you can specify fast and have the checks occur every 10 seconds. Now, this is a check every 10 seconds from every health checker involved within this health check, so the actual frequency of the health checks occurring on the endpoint will be much more frequent. This is one check every 10 seconds from every health checker.

You can specify the failure threshold, so this is the number of consecutive health checks that an endpoint must pass or fail for Route 53 to change the current status. So if you want to allocate a buffer and allow for the opportunity of the odd fail check not to influence the health state, then you can specify a suitable value in this box. It's here where you can specify a simple check, so HTTP or HTTPS, or you can elect to use string matching to do more rich checks of application health. So if you know that your application should deliver a certain string in the request body, then you can specify that here.

Now, you can also configure a number of advanced options. One of them is the latency graph, so you can show the latency of the checks against this endpoint. You can invert the health check status, so if the health check of an application is unhealthy, you can invert it to healthy and vice versa. So this is a fairly situational option that I haven't found much use for.

You also have the option of disabling the health check. This might be useful if you're performing temporary maintenance on an application, and if you check this box, then even if the application endpoint reports as unhealthy, it's considered healthy. You also get the option of specifying the health checker regions. You can use the recommended suggestion, and the health checkers will come from these locations, or you can select customize and pick the particular regions that you want to use. In most cases, you would use the recommended options.

Now, if we just go ahead and enter some sample values here, so I'm going to use 1.1.1.1. I'm going to leave the host name blank, I'm going to set the port number to 80, and then I'll scroll down and just enter a search string. Again, we're not going to create this or just enter a placeholder, click on next, and it's here where you can configure what happens when the health check fails.

Now, this is completely optional. We can use health checks within resource records only; we don't have to configure any notification, but if we do want to configure a notification, then we can create an alarm, and we can send this to either an existing or new SNS topic, and this is a method of how we can integrate this with other systems so we can have other AWS services configured to respond to notifications on this topic or we could integrate external systems so that when a health check fails, external action is taken. But this is what I wanted to show you. I just wanted to give you an overview of how it looks creating a health check within the console UI.

Now, don't worry, you're actually going to be doing this in a demo lesson, which is coming up elsewhere in this section, but I wanted to give you that initial exposure to how the console looks when creating a health check. At this point, let's go ahead and finish up the theory component of this lesson by returning to the architecture. Now you've seen how a health check is created architecturally, health checks look something like this: let's assume that somewhere near the UK we have an application Catergram, and we point a Route 53 record at this application, so let's assume that this is Catergram.io. What we can do is to associate a health check with this resource record, and doing so means that our application will be health checked by a globally distributed set of health checkers. So each of these health checkers performs a periodic check of our application, and based on this check, they report the resource as healthy or unhealthy.

If more than 18 percent of the health checkers report as healthy, then the health check overall is healthy, otherwise it's reported as unhealthy, and in most cases, records which are unhealthy are not returned in response to queries. Now, you're going to see throughout this section of the course and the wider course itself how health checks can be used to influence how DNS responds to queries and how applications can react to component failure. So Route 53 is an essential design and operational tool that you can use to influence how resolution requests occur and how they're routed through to your various different application components, and so understanding health checks is essential to be able to design Route 53 infrastructure, integrate this with your applications, and then manage it day to day as an operational engineer. So it's really important that you understand this topic end to end, no matter which stream of the AWS certifications that you're currently studying for.

Now, that's everything that 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 want to cover the first of a range of routing policies available within Route 53. We're going to start with the default, and as the name suggests, it's the simplest. This video is going to be pretty quick, so let's jump in and get started straight away.

Simple routing starts with a hosted zone. Let's assume it's a public hosted zone called animalsforlife.org. With simple routing, you can create one record per name. In this example, WWW, which is an A record type. Each record using simple routing can have multiple values, which are part of that same record.

When a client makes a request to resolve WWW and simple routing is used, all of the values are returned in the same query in a random order. The client chooses one of the values and then connects to that server based on the value, in this case, 1.2.3.4. Simple routing is simple, and you should use it when you want to route requests towards one single service, in this example, a web server.

The limitation of simple routing is that it doesn't support health checks, and I'll be covering what health checks are in the next video. But just remember, with simple routing, there are no checks that the resource being pointed at by the record is actually operational, and that's important to understand because all of the other routing types within Route 53 offer some form of health checking and routing intelligence based on those health checks.

Simple routing is the one type of routing policy which doesn't support health checks, and so it is fairly limited, but it is simple to implement and manage. So that's simple routing; again, as the name suggests, it's simple, it's not all that flexible, and it doesn't really offer any exciting features, but don't worry, I'll be covering some advanced routing types over the coming videos.

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

Welcome back. In this video I want to quickly step through a topic which confuses people who are new to DNS and Route 53, and that's the difference between C names and alias records. Now I've seen exam questions which test your understanding of when to use one versus the other, so let's quickly go through the key things which you need to know.

Now let's start by describing the problem that we have if we only use C names. So in DNS, an A record maps a name to an IP address — for example, the name Categor.io to the IP address 1.3.3.7 — by now that should make sense. A C name on the other hand maps a name to another name, so if you had the above A record for Categor.io then you could create a C name record for Categor.io, pointing at Categor.io — it's a way to create another alternative name for something within DNS.

The problem is that you can't use a C name for the apex of a domain, also known as the naked domain, so you couldn't have a C name record for Categor.io pointing at something else — it just isn't supported within the DNS standard. Now this is a problem because many AWS services such as Elastic Load Balancers don't give you an IP address to use, they give you a DNS name, and this means that if you only use C names, pointing the naked Categor.io at an Elastic Load Balancer wouldn't be supported.

You could point www.categor.io at an Elastic Load Balancer because using a C name for a normal DNS record is fine, but you can't use a C name for the domain Apex, also known as the naked domain — now this is a problem which alias records fix. So for anything that's not the naked domain where you want to point a name at another name, C name records are fine — they might not be optimal as I'll talk about in a second, but they will work. For the naked domain known as the Apex of a domain, if you need to point at another name such as Elastic Load Balancers, you can't use C names.

But let's go through the solution — alias records. An alias record generally maps a name onto an AWS resource — now it has other functions, but at this level let's focus on the AWS resource part. Alias records can be used for both the naked domain known as the domain Apex or for normal records. For normal records such as www.categor.io, you could use C names or alias records in most cases, but for naked domains known as the domain Apex, you have to use alias records if you want to point at AWS resources.

For AWS resources, AWS try to encourage you to use alias records and they do this by making it free for requests made where an alias record points at an AWS resource, so generally in most production situations and for the exam, default to picking alias records for anything in a domain where you're pointing at AWS resources.

Now an alias is actually a subtype — you can have an A record alias and a C name record alias and this is confusing at first, but the way I think about this is both of them are alias records, but you need to match the record type with the type of the record you're pointing at. So take the example of an elastic load balancer — with an ELB, you're given an A record for the elastic load balancer, it's a name which points at an IP address, so you have to create an A record alias if you want to point at the DNS name provided by the elastic load balancer.

If the record that the resource provides is an A record, then you need to use an A record alias. So you're going to use alias records when you're pointing at AWS services such as the API gateway, CloudFront, Elastic Beanstalk, Elastic Load Balancers, Global Accelerator, and even S3 buckets — and you're going to experience this last one in a demo lesson which is coming up very soon.

Now it's going to make a lot more sense when you see it in action elsewhere in the course. For now, I just want to make sure that you understand the theory of both the limitations of C name records and the benefits that alias records provide. Now the alias is a type of record that's been implemented by AWS and it's outside of the usual DNS standard, so it's something that in this form you can only use if Route 53 is hosting your domains.

Keep that in mind as I talk about more of the features of Route 53 as we move through this section of the course. But at this point, that's everything that 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 video I want to talk about the other type of hosted zone available within Route 53 and that's private hosted zone, so let's jump in and get started straight away.

A private hosted zone is just like a public hosted zone in terms of how it operates, only it's not public — instead of being public it's associated with VPCs within AWS and it's only accessible within VPCs that it's associated with. You can associate a private hosted zone with VPCs in your account using the console UI, CLI and API, and even in different accounts if you use the CLI and API only. Everything else is the same — you can use them to create resource records and these are resolvable within VPCs.

It's even possible to use a technique called split view or split horizon DNS, which is where you have public and private hosted zones of the same name, meaning that you can have a different variant of a zone for private users versus public. You might do this if you want your company intranet to run on the same address as your website and have your users be presented with your intranet when internal, but the public website when anyone accesses from outside of your corporate network, or if you wanted certain systems to be accessible via your business's DNS but only within your environment.

Now let's quickly step through how private hosted zones work visually so that you have more of an idea of the end-to-end architecture. So we start with a private hosted zone and as with public zones we can create records within this zone. Now from the public internet our users can do normal DNS queries, so for things like Netflix.com and Categor.io, but the private hosted zone is inaccessible from the public internet — it can be made accessible though from VPCs.

Let's assume all three of these VPCs have services inside them and use the Route 53 resolver, so the VPC +2 address — well, any VPCs which we associate with the private hosted zone will be able to access that zone via the resolver, and any VPCs which aren't associated will face the same problem as the user on the public internet on the left — access isn't available, so private hosted zones are great when you need to provide records using DNS but maybe they're sensitive and need to be accessible only from internal VPCs. Just remember, to be able to access a private hosted zone the service needs to be running inside a VPC and that VPC needs to be associated with the private hosted zone.

Now before I finish up this short lesson let's talk about split view or split horizon DNS. Consider this scenario: you have a VPC running an Amazon workspace and to support some business applications, a private hosted zone with some records inside it — the private hosted zone is associated with VPC 1 on the right, meaning the workspace could use the Route 53 resolver to access the private hosted zone, for example to access the accounting records stored within the private hosted zone.

Now the private hosted zone is not accessible from the public internet, but what split view allows us to do is to create a public hosted zone with the same name — this public hosted zone might only have a subset of records that the private hosted zone has, so from the public internet, access to the public hosted zone would work in the same way as you would expect: via the ISP resolver server, then through to the DNS root servers, from there to the .org TLD servers, and from there through to the animals for life name servers provided by Route 53.

Any records inside the public hosted zone would be accessible, but records in the private hosted zone which are not in the public hosted zone — so accounting in this example — would be inaccessible from the public internet, and this is a common architecture where you want to use the same domain name for public access and internal access, but with a different set of records available to each. It's something that you'll need to be comfortable with as an architect designing solutions, a developer integrating DNS into your applications, or an engineer implementing this within AWS.

Now that's everything I want to cover on the theory of private hosted zone, 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 talk about Route 53 public hosted zones. There are two types of DNS zones in Route 53, public and private.

To start with, let's cover off some general facts and then we can talk specifically about public hosted zones. A hosted zone is a DNS database for a given section of the global DNS database, specifically for a domain such as AnimalsForLife.org.

Route 53 is a globally resilient service; these name servers are distributed globally and have the same dataset, so whole regions can be affected by outages and Route 53 will still function. Hosted zones are created automatically when you register a domain using Route 53, and you saw that earlier in the course when I registered the AnimalsForLife.org domain, but they can also be created separately if you want to register a domain elsewhere and use Route 53 to host it.

There's a monthly fee to host each hosted zone and a fee for the queries made against that hosted zone. A zone is where the public or private hosts DNS records, examples of these being A records or the IP version 6 equivalent, MX records, NS records, and text records, and I've covered these at an introductory level earlier in the course.

In summary, hosted zones are databases which are referenced via delegation using name server records, and a hosted zone when referenced in this way is authoritative for a domain such as AnimalsForLife.org. When you register a domain, name server records for that domain are entered into the top level domain zone; these point at your name servers, and then your name servers and the zone that they host become authoritative for that domain.

A public hosted zone is a DNS database — a zone file — which is hosted by Route 53 on public name servers, and this means it's accessible from the public internet and within VPCs using the Route 53 resolver. Architecturally, when you create a public hosted zone, Route 53 allocates four public name servers, and it's on those name servers that the zone file is hosted.

To integrate it with the public DNS system, you change the name server records for that domain to point at those four Route 53 name servers. Inside a public hosted zone, you create resource records which are the actual items of data which DNS uses.

You can — and I'll cover this in an upcoming video — use Route 53 to host zone files for externally registered domains. So for example, you can use hover or goad adi to register a domain, then create the public hosted zone in Route 53, get the four name servers which are allocated to that hosted zone, and then via the hover or goad adi interface, you can add those name servers into the DNS system for your domain.

I'll cover how this works in detail in a future video. Visually, this is how a public hosted zone looks and functions.

We start by creating a public hosted zone, and for this example, it's animalsforlife.org — creating this allocates four Route 53 name servers for this zone, and those name servers are all accessible from the public internet. They're also accessible from AWS VPCs using the Route 53 resolver, which, assuming DNS is enabled for the VPC, is directly accessible from an internal IP address of that VPC.

Inside this hosted zone, we can create some resource records — in this case, a www A record, two MX records for email, and a text record. Within the VPC, the access method is direct — the VPC resolver using the VPC plus two address — and this is accessible from any instances inside the VPC which use this as their DNS resolver, so they can query the hosted zone as they can any public DNS zone using the Route 53 resolver.

From a public DNS perspective, the architecture is the same in that the same zone file is used, but the mechanics are slightly different. DNS starts with the DNS root servers, and these are the first servers queried by our user's resolver server — so Bob is using a laptop talking to his ISP DNS resolver server, which queries the root servers.

The root servers have information on the .org top level domain, and so the ISP resolver server can then query the .org servers. These servers host the .org zone file, and this zone file has an entry for AnimalsForLife.org, which has four name servers, and these all point at the Route 53 public name servers for the public hosted zone for Animals For Life.

This process is called "walking the tree," and this is how any public internet host can access the records inside a public hosted zone using DNS. And that's how public hosted zones work — they're just a zone file which is hosted on four name servers provided by Route 53.

This public hosted zone can be accessed from the public internet or any VPCs which are configured to allow DNS resolution. There's a monthly cost for hosting this public hosted zone and a tiny charge for any queries made against it — almost nothing in the grand scheme of things, but for larger volume sites, it's something to keep in mind.

So that's public hosted zones — that's everything I wanted to cover in this video on the theory side of things. So 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 and in this video, I want to talk at a very basic level about the Elastic Kubernetes Service known as EKS. Now this is AWS's implementation of Kubernetes as a service. If you haven't already done so, please make sure that you've watched my Kubernetes 101 video because I'll be assuming that level of knowledge so I can focus more in this video about the EKS specific implementation. Now this video is going to stay at a very high level and if required for the topic that you're studying, there are going to be additional deep dive videos and/or demos on any of the relevant subject areas. Now let's just jump in and get started straight away.

So EKS is an AWS managed implementation of Kubernetes. That's to say, AWS have taken the Kubernetes system and added it as a service within AWS. It's the same Kubernetes that you'll see anywhere else just extended to work really well within AWS. And that's the key point here. Kubernetes is cloud agnostic. So if you need containers, but don't want to be locked into a specific vendor, or if you already have containers implemented, maybe using Kubernetes, then that's a reason to choose EKS.

Now EKS can be run in different ways. It can run on AWS itself. It can run on AWS Outposts, which conceptually is like running a tiny version of AWS on-premises. It can run using EKS anywhere, which basically allows you to create EKS clusters on-premises or anywhere else. And AWS even release the EKS product as open source via the EKS distro. Generally though, and certainly for this video, you can assume that I mean the normal AWS deployment mode of EKS, so running EKS within AWS as a product.

So the Kubernetes control plane is managed by AWS and scales based on load and also runs across multiple availability zones, and the product integrates with other AWS services in the way that you would expect an AWS product to do so. So it can use the Elastic Container Registry or ECR, it uses Elastic Load Balancers anywhere where Kubernetes needs load balancer functionality, IAM is integrated for security, and it also uses VPCs for networking.

EKS clusters mean the EKS control plane, so that's the bit that's managed by AWS as well as the EKS nodes, and I'll talk more about those in a second. ETCD, remember, this is the key value store which Kubernetes uses; this is also managed by AWS and distributed across multiple availability zones.

Now in terms of nodes, you have a few different ways that these can be handled. You can do self-managed nodes running in a group, so these are EC2 instances which you manage and you're billed for based on normal EC2 pricing. Then we have managed node groups which are still EC2, but this is where the product handles the provisioning and lifecycle management. Finally, you can run pods on Fargate.

With Fargate, you don't have to worry about provisioning, configuring, or scaling groups of instances, and you also don't need to choose the instance type or decide when to scale or optimize cluster packing. Instead, you define Fargate profiles which mean that pods can start on Fargate, and in general, this is similar to ECS Fargate which I've already covered elsewhere.

Now one super important thing to keep in mind, deciding between self-managed, managed node groups or Fargate is based on your requirements. So if you need Windows pods, GPU capability, Inferentia, Bottle Rocket, Outposts, or Local Zones, then you need to check the node type that you're going to use and make sure it's capable of each of these features. I've included a link attached to this lesson with an up-to-date list of capabilities, but please be really careful on this one because I've seen it negatively impact projects.

Now lastly, remember from the Kubernetes 101 video where I mentioned storage by default is ephemeral. Well, for persistent storage, EKS can use EBS, EFS, and FSX as storage providers, and these can be used to provide persistent storage when required for the product.

Now that's everything about the key elements of the EKS product. Let's quickly take a look visually at how a simple EKS architecture might look. Conceptually, when you think of an EKS deployment, you're going to have two VPCs. The first is an AWS managed VPC, and it's here where the EKS control plane will run from across multiple availability zones. The second VPC is a custom managed VPC, in this case, the Animals for Life VPC.

Now, if you're going to be using EC2 worker nodes, then these will be deployed into the customer VPC. Now, normally the control plane will communicate with these worker nodes via elastic network interfaces which are injected into the customer VPC. So the Kubelet service running on the worker nodes connects to the control plane, either using these ENIs which are injected into the VPC, but it can also use a public control plane endpoint. Any administration via the control plane can also be done using this public endpoint, and any consumption of the EKS services is via ingress configurations which start from the customer VPC.

Now, at a high level, that's everything that I wanted to cover about the EKS product. Once again, if you're studying a course which needs any further detail, there will be additional theory and demo lessons. But at this point, that's everything I want you to do 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 fundamentals video I want to briefly talk about Kubernetes which is an open source container orchestration system, and you use it to automate the deployment, scaling and management of containerized applications. At a super high level, Kubernetes lets you run containers in a reliable and scalable way, making efficient use of resources and lets you expose your containerized applications to the outside world or your business. It's like Docker, only with robots to automate it and super intelligence for all of the thinking. Now Kubernetes is a cloud agnostic product so you can use it on-premises and within many public cloud platforms. Now I want to keep this video to a super high level architectural overview but that's still a lot to cover, so let's jump in and get started.

Let's quickly step through the architecture of a Kubernetes cluster. A cluster in Kubernetes is a highly available cluster of compute resources and these are organized to work as one unit. The cluster starts with the cluster control plane which is the part which manages the cluster; it performs scheduling, application management, scaling and deployment and much more. Compute within a Kubernetes cluster is provided via nodes and these are virtual or physical servers which function as a worker within the cluster; these are the things which actually run your containerized applications. Running on each of the nodes is software and at minimum this is container D or another container runtime which is the software used to handle your container operations, and next we have KubeLit which is an agent to interact with the cluster control plane. KubeLit running on each of the nodes communicates with the cluster control plane using the Kubernetes API. Now this is the top level functionality of a Kubernetes cluster — the control plane orchestrates containerized applications which run on nodes.

But now let's explore the architecture of control planes and nodes in a little bit more detail. On this diagram I've zoomed in a little — we have the control plane at the top and a single cluster node at the bottom, complete with the minimum Docker and KubeLit software running for control plane communications. Now I want to step through the main components which might run within the control plane and on the cluster nodes — keep in mind this is a fundamental level video, it's not meant to be exhaustive, Kubernetes is a complex topic so I'm just covering the parts that you need to understand to get started. The cluster will also likely have many more nodes — it's rare that you only have one node unless this is a testing environment.

First I want to talk about pods and pods are the smallest unit of computing within Kubernetes; you can have pods which have multiple containers and provide shared storage and networking for those pods, but it's very common to see a one container one pod architecture which as the name suggests means each pod contains only one container. Now when you think about Kubernetes don't think about containers — think about pods — you're going to be working with pods and you're going to be managing pods, the pods handle the containers within them. Architecturally you would generally only run multiple containers in a pod when those containers are tightly coupled and require close proximity and rely on each other in a very tightly coupled way. Additionally although you'll be exposed to pods you'll rarely manage them directly — pods are non-permanent things; in order to get the maximum value from Kubernetes you need to view pods as temporary things which are created, do a job and are then disposed of. Pods can be deleted when finished, evicted for lack of resources or if the node itself fails — they aren't permanent and aren't designed to be viewed as highly available entities. There are other things linked to pods which provide more permanence but more on that elsewhere.

So now let's talk about what runs on the control plane. Firstly I've already mentioned this one — the API known formally as kube-api server — this is the front end for the control plane, it's what everything generally interacts with to communicate with the control plane and it can be scaled horizontally for performance and to ensure high availability. Next we have ETCD and this provides a highly available key value store — so a simple database running within the cluster which acts as the main backing store for data for the cluster. Another important control plane component is kube-scheduler and this is responsible for constantly checking for any pods within the cluster which don't have a node assigned, and then it assigns a node to that pod based on resource requirements, deadlines, affinity or anti affinity, data locality needs and any other constraints — remember nodes are the things which provide the raw compute and other resources to the cluster and it's this component which makes sure the nodes get utilized effectively.

Next we have an optional component — the cloud controller manager — and this is what allows kubernetes to integrate with any cloud providers. It's common that kubernetes runs on top of other cloud platforms such as AWS, Azure or GCP and it's this component which allows the control plane to closely interact with those platforms. Now it is entirely optional and if you run a small kubernetes deployment at home you probably won't be using this component.

Now lastly in the control plane is the kube controller manager and this is actually a collection of processes — we've got the node controller which is responsible for monitoring and responding to any node outages, the job controller which is responsible for running pods in order to execute jobs, the end point controller which populates end points in the cluster (more on this in a second but this is something that links services to pods — again I'll be covering this very shortly), and then the service account and token controller which is responsible for account and API token creation. Now again I haven't spoken about services or end points yet — just stick with me, I will in a second.

Now lastly on every node is something called kproxy known as kube proxy and this runs on every node and coordinates networking with the cluster control plane — it helps implement services and configures rules allowing communications with pods from inside or outside of the cluster. You might have a kubernetes cluster but you're going to want some level of communication with the outside world and that's what kube proxy provides.

Now that's the architecture of the cluster and nodes in a little bit more detail but I want to finish this introduction video with a few summary points of the terms that you're going to come across. So let's talk about the key components — so we start with the cluster and conceptually this is a deployment of kubernetes, it provides management, orchestration, healing and service access. Within a cluster we've got the nodes which provide the actual compute resources and pods run on these nodes — a pod is one or more containers and is the smallest admin unit within kubernetes and often as I mentioned previously you're going to see the one container one pod architecture — simply put it's cleaner. Now a pod is not a permanent thing, it's not long lived — the cluster can and does replace them as required.

Services provide an abstraction from pods so the service is typically what you will understand as an application — an application can be containerized across many pods but the service is the consistent thing, the abstraction — service is what you interact with if you access a containerized application. Now we've also got a job and a job is an ad hoc thing inside the cluster — think of it as the name suggests as a job — a job creates one or more pods, runs until it completes, retries if required and then finishes — now jobs might be used as back end isolated pieces of work within a cluster.

Now something new that I haven't covered yet and that's ingress — ingress is how something external to the cluster can access a service — so you have external users, they come into an ingress, that's routed through the cluster to a service, the service points at one or more pods which provides the actual application. So an ingress is something that you will have exposure to when you start working with Kubernetes. And next is an ingress controller and that's a piece of software which actually arranges for the underlying hardware to allow ingress — for example there is an AWS load balancer ingress controller which uses application and network load balancers to allow the ingress, but there are also other controllers such as engine X and others for various cloud platforms.

Now finally and this one is really important — generally it's best to architect things within Kubernetes to be stateless from a pod perspective — remember pods are temporary — if your application has any form of long running state then you need a way to store that state somewhere. Now state can be session data but also data in the more traditional sense — any storage in Kubernetes by default is ephemeral provided locally by a node and thus if a pod moves between nodes then that storage is lost. Conceptually think of this like instance store volumes running on AWS EC2. Now you can configure persistent storage known as persistent volumes or PVs and these are volumes whose life cycle lives beyond any one single pod which is using them and this is how you would provision normal long running storage to your containerised applications — now the details of this are a little bit beyond this introduction level video but I wanted you to be aware of this functionality.

Ok so that's a high level introduction to Kubernetes — it's a pretty broad and complex product but it's super powerful when you know how to use it. This video only scratches the surface. If you're watching this as part of my AWS courses then I'm going to have follow up videos which step through how AWS implements Kubernetes with their EKS service. If you're taking any of the more technically deep AWS courses then maybe other deep dive videos into specific areas that you need to be aware of. So there may be additional videos covering individual topics at a much deeper level. If there are no additional videos then don't worry because that's everything that you need to be aware of. Thanks for watching this video, 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 quickly cover the theory of the Elastic Container Registry or ECR. Now I want to keep the theory part brief because you're going to get the chance to experience this in practice elsewhere in the course and this is one of those topics which is much easier to show you via a demo versus covering the theory. So I'm going to keep this as brief as possible so let's jump in and get started.

Well let's first look at what the Elastic Container Registry is. Well it's a managed container image registry service. It's like Docker Hub but for AWS so this is a service which AWS provide which hosts and manages container images and when I talk about container images I mean images which can be used within Docker or other container applications, so think things like ECS or EKS.

Now within the ECR product we have public and private registries and each AWS account is provided with one of each so this is the top level structure. Inside each registry you can have many repositories so you can think of these like repos within a source control system, so think of Git or GitHub—you can have many repositories. Now inside each repository you can have many container images and container images can have several tags and these tags need to be unique within your repository.

Now in terms of the security architecture the differences between public and private registries are pretty simple. First, a public registry means that anyone can have read-only access to anything within that registry but read-write requires permissions. The other side is that a private registry means that permissions are required for any read or any read-write operations, so this means with a public registry anyone can pull but to push you need permissions and for a private registry permissions are required for any operations.

So that's the high level architecture, let's move on and talk about some of the benefits of the elastic container registry. Well first and foremost it's integrated with IAM and this is logically for permissions, so this means that all permissions controlling access to anything within the product are controlled using IAM.

Now ECR offers security scanning on images and this comes in two different flavors: basic and enhanced, and enhanced is a relatively new type of scanning and this uses the inspector product. Now this can scan looking for issues with both the operating system and any software packages within your containers and this works on a layer by layer basis, so enhanced scanning is a really good piece of additional functionality that the product provides.

Now logically like many other AWS products, ECR offers near real-time metrics and these are delivered into CloudWatch. Now these metrics are for things like authentication or push or pull operations against any of the container images. ECR also logs all API actions into CloudTrail and then also it generates events which are delivered into EventBridge and this can form part of an event-driven workflow which involves container images.

Now lastly ECR offers replication of container images and this is both cross region and cross account, so these are all important features provided by ECR.

Now as I mentioned at the start of this lesson all I wanted to do is to cover the high-level theory of this product. It's far easier to gain an understanding of the product by actually using it. So elsewhere in the course you're going to get the chance to use ECR in some container-based workflows, so you'll get the chance to push some container images into the product and pull them when you're deploying your container-based applications.

Now 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 lesson I want to briefly discuss the two different cluster modes that you can use when running containers within ECS, so that's EC2 mode and Fargate mode. The cluster mode defines a number of things, but one of them is how much of the admin overheads surrounding running a set of container hosts that you manage versus how much AWS manage. So the technical underpinnings of both of these are important, but one of the main differentiating facts is what parts you're responsible for managing and what parts AWS manage. There are some cost differences we'll talk about and certain scenarios which favor EC2 mode and others which favor Fargate mode, and we'll talk about all of that inside this lesson.

At this level, it's enough to understand the basic architecture of both of these modes and the situations where you would pick one over the other. So we've got a lot to cover, so let's jump in and get started.

The first cluster mode available within ECS is EC2 mode, and using EC2 mode we start with the ECS management components, so these handle high level tasks like scheduling, orchestration, cluster management and the placement engine which handles where to run containers, so which container hosts. Now these high level components exist in both modes, so that's EC2 mode and Fargate mode, and with EC2 mode an ECS cluster is created within a VPC inside your AWS account.

Because an EC2 mode cluster runs within a VPC, it benefits from the multiple availability zones which are available within this VPC—for this example let's assume we have two, AZA and AZB. With EC2 mode, EC2 instances are used to run containers, and when you create the cluster you specify an initial size which controls the number of container instances, and this is handled by an auto scaling group. We haven't covered auto scaling groups yet in the course, but there are ways that you can control horizontal scaling for EC2 instances, so adding more instances when requirements dictate and removing them when they're not needed, but for this example let's say that we have four container instances.

Now these are just EC2 instances—you will see them in your account, you'll be billed for them, you can even connect to them, so it's important to understand that when these are provisioned you will be paying for them regardless of what containers you have running on them. So with EC2 cluster mode you are responsible for these EC2 instances that are acting as container hosts, and now ECS provisions these EC2 container hosts, but there is an expectation that you will manage them generally through the ECS tooling. So ECS using EC2 mode is not a serverless solution—you need to worry about capacity and availability for your cluster.

ECS uses container registries, and these are where your container images are stored. Remember in a previous lesson I showed you how to store the container of cats images on Docker Hub, and that's an example of a container registry. AWS of course have their own which is called ECR—I've previously mentioned that—and you can choose to use that or something public like Docker Hub.

Now in the previous lesson I spoke about tasks and services which are how you direct ECS to run your containers. Well, tasks and services use images on container registries, and via the task and service definitions inside ECS, container images are deployed onto container hosts in the form of containers.

Now in EC2 mode ECS will handle certain elements of this, so ECS will handle the number of tasks that are deployed if you utilize services and service definitions, but at a cluster level you need to be aware of and manage the capacity of the cluster because the container instances are not something that's delivered as a managed service—they are just EC2 instances.

So ECS using EC2 mode offers a great middle ground if you want to use containers in your infrastructure but you absolutely need to manage the container hosts’ capacity and availability. Then EC2 mode is for you, because EC2 mode uses EC2 instances. If your business has reserved instances then you can use those, you can use EC2 spot pricing, but you need to manage all of this yourself.

It's important to understand that with EC2 mode, even if you aren't running any tasks or any services on your EC2 container hosts, you are still paying for them while they're in a running state, so you're expected to manage the number of container hosts inside an EC2 based ECS cluster. So whilst ECS as a product takes away a lot of the management overhead of using containers, in EC2 cluster mode you keep some of that overhead and some flexibility, so it's a great middle ground.

Fargate mode for ECS removes even more of the management overhead of using containers within AWS. With Fargate mode you don't have to manage EC2 instances for use as container hosts. As much as I hate using the term serverless, Fargate is a cluster model which means you have no service to manage, and because of this you aren't paying for EC2 instances regardless of whether you're using them or not.

Fargate mode uses the same surrounding technologies, so you still have the Fargate service handling schedule and orchestration, cluster management and placement, and you still use registries for the container images as well as use task and service definitions to define tasks and services. What differs is how containers are actually hosted.

Core to the Fargate architecture is the fact that AWS maintain a shared Fargate infrastructure platform. This shared platform is offered to all users of Fargate, but much like how EC2 isolates customers from each other, so does Fargate. You gain access to resources from a shared pool, just like you can run EC2 instances on shared hardware, but you have no visibility of other customers.

With Fargate you use the same task and service definitions, and these define the image to use, the ports, and how much resources you need, but with Fargate these are then allocated to the shared Fargate platform. You still have your VPC—a Fargate deployment still uses a cluster and a cluster uses a VPC which operates in availability zones, in this example AZA and AZB.

Where it starts to differ though is for ECS tasks—which remember, they're now running on the shared infrastructure—but from a networking perspective they're injected into your VPC. Each of the tasks is injected into the VPC and it gets given an elastic network interface, which has an IP address within the VPC.

At that point they work just like any other VPC resource and they can be accessed from within that VPC and from the public internet if the VPC is configured that way. So this is really critical for you to be aware of—tasks and services are actually running from the shared infrastructure platform and then they're injected into your VPC, they're given network interfaces inside a VPC, and it's using these network interfaces in that VPC that you can access them.

So if the VPC is configured to use public subnets which automatically allocate an IPv4 address, then tasks and services can be given public IPv4 addressing. Fargate offers a lot of customizability—you can deploy exactly how you want into either a new VPC or a custom VPC that you have designed and implemented in AWS.

With Fargate mode, because tasks and services are running from the shared infrastructure platform, you only pay for the containers that you're using based on the resources that they consume. So you have no visibility of any host costs, you don't need to manage hosts, provision hosts or think about capacity and availability—that's all handled by Fargate, and you simply pay for the container resources that you consume.

Now one final thing before we move to a demo where we're going to implement a container inside a Fargate architecture. For the exam, and as a solutions architect in general, you should be able to advise when a business or a team should use ECS.

There are actually three main options: using EC2 natively for an application (so deploying an application as a virtual machine), using ECS in EC2 mode (so using a containerized application but running in ECS using an EC2 based cluster), or using a containerized application running in ECS but in Fargate mode. So there's a number of different options.

Picking between using EC2 and ECS should in theory be easy—if you use containers, then pick ECS. If you're a business which already uses containers for anything, then it makes sense to use ECS. In the demo that we did earlier in this section, we used an EC2 instance and Docker to create a Docker image—that's an edge case though.

If you're wanting to just quickly test containers, you can use EC2 as a Docker host, but for anything production usage, it's almost never a good idea to do that. The normal options are generally to run an application inside an operating system inside EC2 or to utilize ECS in one of these two different modes.

Containers in general make sense if you're just wanting to isolate your applications, applications which have low usage levels, applications which all use the same OS, or applications where you don't need the overhead of virtualization. You would generally pick EC2 mode when you have a large workload and your business is price conscious.

If you care about price more than effort, you'll want to look at using spot pricing or reserved pricing or make use of reservations that you already have. Running your own fleet of EC2-based ECS hosts will probably be cheaper—but only if you can minimize the admin overhead of managing them, so scaling, sizing, as well as correcting any faults.

So if you have a large consistent workload, if you're heavily using containers, but if you are a price-conscious organization, then potentially pick EC2 mode. If you're overhead-conscious, even with large workloads, then Fargate makes more sense. Using Fargate is much less management overhead versus EC2 mode because you don't have any exposure to container hosts or their management.

So even large workloads—if you care about minimizing management overhead—then use Fargate. For small or burst-style workloads, Fargate makes sense because with Fargate you only pay for the container capacity that you use. Having a fleet of EC2-based container hosts running constantly for non-consistent workloads just makes no sense—it's wasting the capacity.

The same logic is true for batch or periodic workloads. Fargate means that you pay for what you consume. EC2 mode would mean paying for the container instances even when you don't use them.

Okay, I hope this starts to make sense. I hope the theory that we've covered starts to give you an impression for when you would use ECS, and then when you do use the product, how to distinguish between scenarios which suit EC2 mode versus Fargate mode.

So next up we have a demo lesson, and I'm going to get you to take the container of cats Docker image that we created together earlier in this section and run it inside an ECS Fargate cluster. By configuring it practically, it's going to help a lot of the facts and architecture points that we've discussed through this section stick, and these facts sticking will be essential to being able to answer any container-based questions in the exam.

I know the container of cats is a simple example, but the steps that you'll be performing will work equally well in something that's a lot more complex. As we go through the course, we're going to be revisiting ECS—it will feature in some architectures for the Animals for Life business later in the course.

For now though, I want you to just be across the fundamentals—enough to get started with ECS and enough for the associate AWS exams. So go ahead, complete this lesson, and when you're ready you can join me in the next lesson which will be an ECS Fargate demo.

Welcome back and in this lesson I want to introduce the Elastic Container Service or ECS. In the previous lesson you created a Docker image and tested it by running up a container, all using the Docker container engine running on an EC2 instance, and this is always something that you can do with AWS. But ECS is a product which allows you to use containers running on infrastructure which AWS fully manage or partially manage, and it takes away much of the admin overhead of self managing your container hosts.

ECS is to containers what EC2 is to virtual machines, and ECS uses clusters which run in one of two modes: EC2 mode which uses EC2 instances as container hosts (and you can see these inside your account as just normal EC2 hosts running the ECS software), and Fargate mode which is a serverless way of running Docker containers where AWS manage the container host part and just leave you to define and architect your environment using containers.

Now in this lesson I'll be covering the high level concepts of the product which apply to both of those modes, and then in the following lesson I'll talk in a little bit more detail about EC2 mode and Fargate mode, so let's jump in and get started.

ECS is a service that accepts containers and some instructions that you provide and it orchestrates where and how to run those containers; it's a managed container based compute service. I mentioned this a second ago but it runs in two modes, EC2 and Fargate, which radically changes how it works under the surface, but for what I need to talk about in this lesson we can be a little abstract and say that ECS lets you create a cluster. I'll cover the different types of cluster architectures in the following lesson, but for now it's just a cluster; clusters are where your containers run from.

You provide ECS with a container image and it runs that in the form of a container in the cluster based on how you want it to run, but let's take this from the bottom up architecturally and just step through how things work. First you need a way of telling ECS about container images that you want to run and how you want them to be run; containers are all based on container images as we talked about earlier in this section, and these container images will be located on a container registry somewhere, and you've seen one example of that with the Docker Hub.

Now AWS also provide a registry, it's called the Elastic Container Registry or ECR, and you can use that if you want; ECR has a benefit of being integrated with AWS so all of the usual permissions and scalability benefits apply, but at its heart it is just a container registry—you can use it or use something else like Docker Hub.

To tell ECS about your container images you create what's known as a container definition; the container definition tells ECS where your container image is—logically it needs that—it tells ECS which port your container uses (remember in the demo we exposed port 80 which is HTTP), and so this is defined in the container definition as well.

The container definition provides just enough information about the single container that you want to define. Then we have task definitions and a task in ECS represents a self-contained application; a task could have one container defined inside it or many—a very simple application might use a single container just like the container of Katz application that we demoed in the previous lesson, or it could use multiple containers, maybe a web app container and a database container.

A task in ECS represents the application as a whole and so it stores whatever container definitions are used to make up that one single application; I remember the difference by thinking of the container definition as just a pointer to where the container is stored and what port is exposed, and the rest is defined in the task definition.

At the associate level this is easily enough detail but if you do want extra detail on what's stored in the container definition versus the task definition I've included some links attached to this lesson which give you an overview of both.

Task definitions store the resources used by the task—so CPU and memory—they store the networking mode that the task uses, they store the compatibility (so whether the task will work on EC2 mode or Fargate), and one of the really important things which the task definition stores is the task role.

A task role is an IAM role that a task can assume and when the task assumes that role it gains temporary credentials which can be used within the task to interact with AWS resources; task roles are the best practice way of giving containers within ECS permissions to access AWS products and services, and remember that one because it will come up in at least one exam question.

When you create a task definition within the ECS UI you actually create a container definition along with it, but from an architecture perspective I definitely wanted you to know that they're actually separate things.

This is further confused by the fact that a lot of tasks that you create inside ECS will only have one container definition and that's going to be the case with the container of Katz demo that we're going to be doing at the end of this section when we deploy our Docker container into ECS, but tasks and containers are separate things—a task can include one or more containers, and a lot of tasks do include one container which doesn't help with the confusion.

Now a task in ECS it doesn't scale on its own and it isn't by itself highly available, and that's where the last concept that I want to talk to you about in this lesson comes in handy and that's called an ECS service, and you configure that via a service definition.

A service definition defines a service, and a service is how for ECS we can define how we want a task to scale, how many copies we'd like to run—it can add capacity and it can add resilience because we can have multiple independent copies of our task running—and you can deploy a load balancer in front of a service so the incoming load is distributed across all of the tasks inside a service.

So for tasks that you're running inside ECS that are long running and business critical, you would generally use a service to provide that level of scalability and high availability; it's the service that lets you configure replacing failed tasks or scaling or how to distribute load across multiple copies of the same task.

Now we're not going to be using a service when we demo the container of cats demo at the end of this section because we'll only be wanting to run a single copy—you can run a single copy of a task on its own—but it's the service wrapper that you use if you want to configure scaling and high availability.

And it's tasks or services that you deploy into an ECS cluster and this applies equally to whether it's EC2 based or Fargate based; I'll be talking about the technical differences between those two in the next lesson, but for now the high level building blocks are the same—you create a cluster and then you deploy tasks or services into that cluster.

Now just to summarize a few of the really important points that I've talked about in this lesson: first is the container definition—this defines the image and the ports that will be used for a container—it basically points at a container image that's stored on a container registry and it defines which ports are exposed from that container.

It does other things as well and I've included a link attached to this lesson which gives you a full overview of what's defined in the container definition, but at the associate level all you need to remember is a container definition defines which image to use for a container and which ports are exposed.

A task definition applies to the application as a whole—it can be a single container (so a single container definition) or multiple containers and multiple container definitions—but it's also the task definition where you specify the task role, so the security that the containers within a task get: what can they access inside AWS?

It's an IAM role that's assumed and the temporary credentials that you get are what the containers inside the task can use to access AWS products and services.

So task definitions include this task role, the containers themselves, and you also specify at a task definition level the resources that your task is going to consume, and I'll be showing you that in the demo lesson at the end of this section.

The task role, obviously I've just talked about, is the IAM role that's assumed by anything that's inside the task—so the task role can be used by any of the containers running as part of a task—and that's the best practice way that individual containers can access AWS products and services.

And then finally we've got services and service definitions and this is how you can define how many copies of a task you want to run, and that's both for scaling and high availability.

So you can use a service and define that you want, say, five copies of a task running—you can put a load balancer in front of those five individual tasks and distribute incoming load across those—so it's used for scaling, it's used for high availability, and you can control other things inside a service such as restarts and the certain monitoring features that you've got access to in there.

And services are generally what you use if it's a business critical application or something in production that needs to cope with substantial incoming load.

In the demo that's at the end of this section, we won't be using a service—we'll be just deploying a task into our ECS cluster.

With that being said, though, that's all the high level ECS concepts that I wanted to talk about in this lesson; it's just enough to get you started so the next lesson makes sense, and then so when you do the demo and get some practical experience with ECS, everything will start to click.

At this point, though, go ahead, complete this video, and when you're ready, you can join me in the next lesson where I'll be talking about the different ECS cluster modes.

Welcome back. This section will be focusing on another type of compute, container computing. To understand the benefits of the AWS products and services which relate to containers, you'll need to understand what containers are and what benefits container computing provides. In this lesson, I aim to teach you just that. It's all theory in this lesson, but immediately following this is a demo lesson where you'll have the chance to make a container yourself. We've got a lot to get through though, so let's jump in and get started.

Before we start talking about containers, let's set the scene. What we refer to as virtualization should really be called operating system or OS virtualization. It's the process of running multiple operating systems on the same physical hardware. I've already covered the architecture earlier in the course, but as a refresher, we've got an AWS EC2 host running the Nitro hypervisor, and running on this hypervisor, we have a number of virtual machines.

Part of this lesson's objectives is to understand the difference between operating system virtualization and containers, and so the important thing to realize about these virtual machines is that each of them is an operating system with associated resources. What's often misunderstood is just how much of a virtual machine is taken up by the operating system alone. If you run a virtual machine with say 4GB of RAM and a 40GB disk, the operating system can easily consume 60 to 70% of the disk and much of the available memory, leaving relatively little for the applications which run in those virtual machines as well as the associated runtime environments.

So with the example on screen now, it's obvious that the guest operating system consumes a large percentage of the amount of resource allocated to each virtual machine. Now what's the likelihood with the example on screen that many of the operating systems are actually the same? Think about your own business servers, how many run Windows, how many run Linux, how many do you think share the same major operating system version. This is duplication. On this example, if all of these guest operating systems used the same or similar operating system, it's wasting resources, it's duplication.

And what's more, with these virtual machines, the operating system consumes a lot of system resources, so every operation that relates to these virtual machines, every restart, every stop, every start is having to manipulate the entire operating system. If you think about it, what we really want to do with this example is to run applications one through to six in separate isolated protected environments. To do this, do we really need six copies of the same operating system taking up disk space and host resources? Well, the answer is no, not when we use containers.

Containerization handles things much differently. We still have the host hardware, but instead of virtualization, we have an operating system running on this hardware. Running on top of this is a container engine, and you might have heard of a popular one of these called Docker. A container in some ways is similar to a virtual machine in that it provides an isolated environment which an application can run within, but where virtual machines run a whole isolated operating system on top of a hypervisor, a container runs as a process within the host operating system.

It's isolated from all of the other processors, but it can use the host operating system for a lot of things like networking and file I/O. For example, if the host operating system was Linux, it could run Docker as a container engine. Linux plus the Docker container engine can run a container. That container would run as a single process within that operating system, potentially one of many. But inside that process, it's like an isolated operating system. It has its own file systems isolated from everything else and it can run child processors inside it, which are also isolated from everything else.

So a container could run a web server or an application server and do so in a completely isolated way. What this means is that architecturally, a container would look something like this, something which runs on top of the base OS and container engine, but consumes very little memory. In fact, the only consumption of memory or disk is for the application and any runtime environment elements that it needs—so libraries and dependencies. The operating system could run lots of other containers as well, each running an individual application.

So using containers, we achieve this architecture, which looks very much like the architecture used on the previous example, which use virtualization. We're still running the same six applications, but the difference is that because we don't need to run a full operating system for each application, the containers are much lighter than the virtual machines. And this means that we can run many more containers on the same hardware versus using virtualization. This density, the ability to run more applications on a single piece of hardware is one of the many benefits of containers.

Let's move on and look at how containers are architected. I want you to start off by thinking about what an EC2 instance actually is, and what it is is a running copy of its EBS volumes, its virtual disks. An EC2 instance's boot volume is used, it's booted and using this, you end up with a running copy of an operating system running in a virtualized environment. A container is no different in this regard. A container is a running copy of what's known as a Docker image.

Docker images are really special, though. One of the reasons why they're really cool technology-wise is they're actually made up of multiple independent layers. So Docker images are stacks of these layers and not a single monolithic disk image, and you'll see why this matters very shortly. Docker images are created initially by using a Docker file, and this is an example of a simple Docker file which creates an image with a web server inside it ready to run.

So this Docker file creates this Docker image. Each line in a Docker file is processed one by one and each line creates a new file system layer inside the Docker image that it creates. Let's explore what this means and it might help to look at it visually. All Docker images start off being created either from scratch or they use a base image, and this is what this top line controls. In this case, the Docker image we're making uses CentOS 7 as its base image.

Now this base image is a minimal file system containing just enough to run an isolated copy of CentOS. All this is is a super thin image of a disk—it just has the basic minimal CentOS 7 base distribution. And so that's what the first line of the Docker file does—it instructs Docker to create our Docker image using as a basis this base image. So the first layer of our Docker image, the first file system layer is this basic CentOS 7 distribution.

The next line performs some software updates and it installs our web server, Apache in this case, and this adds another layer to the Docker image. So now our image is two layers—the base CentOS 7 image and a layer which just contains the software that we've just installed. This is critical in Docker—the file system layers that make up a Docker image are normally read only. So every change you make is layered on top as another layer, and each layer contains the differences made when creating that layer.

So then we move on in our Docker file and we have some slight adjustments made at the bottom. It's adding a script which creates another file system layer for a total of three. And this is how a Docker image is made—it starts off either from scratch or using a base layer and then each set of changes in the Docker file adds another layer with just those changes in, and the end result is a Docker image that we can use which consists of individual file system layers.

Now strictly speaking, the layers in this diagram are upside down—a Docker image consists of layers stacked on each other starting with the base layer. So the layer in red at the bottom and then the blue layer which includes the system updates and the web server should be in the middle and the final layer of customizations in green should be at the top. It was just easier to diagram it in this way but in actuality it should be reversed.

Now let's look at what images are actually used for—a Docker image is how we create a Docker container. In fact, a Docker container is just a running copy of a Docker image with one crucial difference—a Docker container has an additional read write file system layer. File system layers—so the layers that make up a Docker image by default, they're read only. They never change after they're created, and so this special read write layer is added which allows containers to run anything which happens in the container.

If log files are generated or if an application generates or reads data, that's all stored in the read write layer of the container. Each layer is differential and so it stores only the changes made against it versus the layers below. Together all stacked up they make what the container sees as a file system. But here is where containers become really cool—because we could use this image to create another container, container two.

This container is almost identical—it uses the same three base layers. So the CentOS 7 layer in red beginning AB, the web server and updates that are installed in the middle blue layer beginning 8-1 and the final customization layer in green beginning 5-7. They're both the same in both containers—the same layers are used so we don't have any duplication. They're read only layers anyway and so there's no potential for any overwrites.

The only difference is the read write layer which is different in both of these containers. That's what makes the container separate and keeps things isolated. Now in this particular case if we're running two containers using the same base image then the difference between these containers could be tiny. So rather than virtual machines which have separate disk images which could be tens or hundreds of gigs, containers might only differ by a few meg in each of their read write layers—the rest is reused between both of these containers.

Now this example has two containers but what if it had 200? The reuse architecture that's offered by the way that containers do their disk images scales really well. Disk usage when you have lots of containers is minimized because of this layered architecture, and the base layers, the operating systems, they're generally made available by the operating system vendors generally via something called a container registry and a popular one of these is known as Docker Hub.

The function of a container registry is almost revealed in the name—it's a registry or a hub of container images. As a developer or architect you make or use a Docker file to create a container image and then you upload that image to a private repository or a public one such as the Docker Hub, and for public hubs other people will likely do the same including vendors of the base operating system images such as the CentOS example I was just talking about.

From there these container images can be deployed to Docker hosts which are just servers running a container engine—in this case Docker. Docker hosts can run many containers based on one or more images and a single image can be used to generate containers on many different Docker hosts. Remember a container is a single thing—your eye could take a container image and both use that to generate a container, so that's one container image which can generate many containers, and each of these are completely unique because of this read write layer that a container gets the solo use of.

Now you can use the Docker Hub to download container images but also upload your own. Private registries can require authentication but public ones are generally open to the world. Now I have to admit I have a bad habit when it comes to containers—I'm usually all about precision in the words that I use but I've started to use Docker and containerization almost interchangeably. In theory, a Docker container is one type of container, a Docker host is one type of container host, and the Docker Hub is a type of container hub or a type of container registry operated by the company Docker.

Now even I start to use these terms interchangeably I'll try not to, but because of the popularity of Docker and Docker containers you will tend to find that people say Docker when they actually mean containers—so keep an eye out for that one. Now the last thing before we finish up and go to the demo I just want to cover some container key concepts just as a refresher.

You've learned that Docker files are used to build Docker images and Docker images are these multi-layer file system images which are used to run containers. Containers are a great tool for any solutions architect because they're portable and they always run as expected. If you're a developer and you have an application, if you put that application and all of its libraries into a container, you know that anywhere that there is a compatible container host that that application can run exactly as you intended with the same software versions.

Portability and consistency are two of the main benefits of using containerized computing. Containers and images are super lightweight—they use the host operating system for the heavy lifting but are otherwise isolated. Layers used within images can be shared and images can be based off other images. Layers are read only and so an image is basically a collection of layers grouped together which can be shared and reused.

If you have a large container environment, you could have hundreds or thousands of containers which are using a smaller set of container images, and each of those images could be sharing these base file system layers to really save on capacity—so if you've got larger environments, you could significantly save on capacity and resource usage by moving to containers.

Containers only run what's needed—so the application and whatever the application itself needs. Containers run as a process in the host operating system and so they don't need to be a full operating system. Containers use very little memory and as you will see, they're super fast to start and stop, and yet they provide much of the same level of isolation as virtual machines—so if you don't really need a full and isolated operating system, you should give serious thought to using containerization because it has a lot of benefits, not least is the density that you can achieve using containers.

Containers are isolated and so anything running in them needs to be exposed to the outside world—so containers can expose ports such as TCP port 80 which is used for HTTP, and so when you expose a container port, the services that that container provides can be accessed from the host and the outside world. It's important to understand that some more complex application stacks can consist of multiple containers—you can use multiple containers in a single architecture either to scale a specific part of the application or when you're using multiple tiers, so you might have a database container, you might have an application container, and these might work together to provide the functionality of the application.

Okay so that's been a lot of foundational theory and now it's time for a demo. In order to understand AWS's container compute services, you need to understand how containers work. This lesson has been the theory, and the following demo lesson is where you will get some hands-on time by creating your own container image and container. It's a fun way to give you some experience, so I can't wait to step you through it. At this point they'll go ahead and finish this video and when you're ready you can join me in the demo lesson.

Welcome back and in this lesson I want to cover two important EC2 optimisation topics, Enhanced Networking and EBS Optimised Instances; both of these are important on their own, both provide massive benefits to the way EC2 performs, and they support other performance features within EC2 such as placement groups. As a solutions architect understanding their architecture and benefits is essential, so let's get started.

Now let's start with Enhanced Networking, which is a feature designed to improve the overall performance of EC2 networking and is required for any high-end performance features such as cluster placement groups. Enhanced Networking uses a technique called SRIOV or Single Route IO Virtualisation, and I've mentioned this earlier in the course.

At a high level, it makes it so that a physical network interface inside an EC2 host is aware of virtualisation. Without Enhanced Networking this is how networking looks on an EC2 host architecturally: in this example we have two EC2 instances, each of them using one virtual network interface, and both of these virtual network interfaces talk back to the EC2 host and each of them use the host's single physical network interface.

The crucial thing to understand here is that the physical network interface card isn't aware of virtualisation, and so the host has to sit in the middle controlling which instance has access to the physical card at one time. It's a process taking place in software so it's slower and it consumes a lot of host CPU, and when the host is under heavy load—so CPU or IO—it can cause drops in performance, spikes in latency, and changes in bandwidth; it's not an efficient system.

Enhanced Networking or SRIOV changes things: using this model, the host has network interface cards which are aware of virtualisation, and instead of presenting themselves as single physical network interface cards which the host needs to manage, it offers what you can think of as logical cards—multiple logical cards per physical card.

Each instance is given exclusive access to one of these logical cards and it sends data to this the same as it would do if it did have its own dedicated physical card, and the physical network interface card handles this process end to end without consuming mass amounts of host CPU.

This means a few things which matter to us as solutions architects: first, in general it allows for higher IO across all instances on the host and lower host CPU as a result, because the host CPU doesn't have the same level of involvement as when no enhanced networking is used.

What this translates into directly is more bandwidth—it allows for much faster networking speeds because it can scale and it doesn't impact the host CPU. Also, because the process occurs directly between the virtual interface that the instance has and the logical interface that the physical card offers, you can achieve higher packets per second or PPS, and this is great for applications which rely on networking performance, specifically those which need to shift lots of small packets around the small isolated network.

And lastly, because the host CPU isn't really involved—because it's offloaded to the physical network interface card—you get low latency and perhaps more importantly consistent low latency.

Enhanced networking is a feature which is either enabled by default or available for no charge on most modern EC2 instance types; there's a lot of detail in making sure that you have it enabled, but for the solutions architect stream none of that is important. As always though, I'll include some links attached to the lesson if you do want to know how to implement it operationally.

Okay, so that's enhanced networking, now let's move on to EBS optimized instances. Whether an instance is EBS optimized or not depends on an option that's set on a per instance basis—it's either on or it's off.

To understand what it does, it's useful to appreciate the context: what we know already is that EBS is block storage for EC2, which is delivered over the network. Historically, networking on EC2 instances was actually shared, with the same network stack being used for both data networking and EBS storage networking, and this resulted in contention and limited performance for both types of networking.

Simply put, an instance being EBS optimized means that some stack optimizations have taken place and dedicated capacity has been provided for that instance for EBS usage; it means that faster speeds are possible with EBS and the storage side of things doesn't impact the data performance and vice versa.

Now, on most instances that you'll use at this point in time, it's supported and enabled by default at no extra charge, and disabling it has no effect because the hardware now comes with the capability built in. On some older instances, it's supported but enabling it costs extra.

EBS optimization is something that's required on instance types and sizes which offer higher levels of performance—so things which offer high levels of throughput and IOPS—especially when using the GP2 and IO1 volume types which promise low and consistent latency as well as high input output operations per second.

So that's EBS optimization; it's nothing complex—it essentially just means adding dedicated capacity for storage networking to an EC2 instance, and at this point in time it's generally enabled and comes with all modern types of instances, so it's something you don't have to worry about, but you do need to know that it exists.

Now, that's the theory that I wanted to cover—I wanted to keep it brief. There's a lot more involved in using both of these and understanding the effects that they can have, but this is an architecture lesson for this stream; you just need to know that both features exist and what they enable you to do—what features they provide at a high level.

So thanks for watching, go ahead, finish this video, and when you're ready you can join me in the next.

Welcome back. In this lesson I want to cover EC2 dedicated hosts, a feature of EC2 which allows you to gain access to hosts dedicated for your use, which you can then use to run EC2 instances. Now I want to keep it brief because for the exam you just need to know that the feature exists, and it tends to have a fairly narrow use case in the real world. So let's just cover the really high-level points and exactly how it works architecturally. So let's jump in and get started.

An EC2 dedicated host, as the name suggests, is an EC2 host which is allocated to you in its entirety, so allocated to your AWS account for you to use. You pay for the host itself, which is designed for a specific family of instances, for example A1, C5, M5 and so on. Because you're paying for the host, there are no charges for any instances which are running on the host; the host has a capacity, and you're paying for that capacity in its entirety, so you don't pay for instances running within that capacity.

Now you can pay for a host in a number of ways: either on demand, which is good for short-term or uncertain requirements, or once you understand long-term requirements and patterns of usage, you can purchase reservations with the same one or three-year terms as the instances themselves, and this uses the same payment method architecture—so all upfront, partial upfront or no upfront.

The host hardware itself comes with a certain number of physical sockets and cores, and this is important for two reasons: number one, it dictates how many instances can be run on that host, and number two, software which is licensed based on physical sockets or cores can utilize this visibility of the hardware. Some enterprise software is licensed based on the number of physical sockets or cores in the server; imagine if you're running some software on a small EC2 instance but you have to pay for the software licensing based on the total hardware in the host that that instance runs on, even though you can't use any of that extra hardware without paying for more instance fees.

With dedicated hosts, you pay for the entire host, so you can license based on that host which is available and dedicated to you, and then you can use instances on that host free of charge after you've paid the dedicated host fees. So the important thing to realize is you pay for the host; once you've paid for that host, you don't have any extra EC2 instance charges, you're covered for the consumption of the capacity on that host.

Now the default way that dedicated hosts work is that the hosts are designed for a specific family and size of instance, so for example an A1 dedicated host comes with one socket and 16 cores. All but a few types of dedicated hosts are designed to operate with one specific size at a time, so you can get an A1 host which can run 16 A1 medium instances, or 8 large, or 4 extra large, or 2 extra large, or 1 4 extra large; all of these options consume the 16 cores available, and all but a few types of dedicated hosts require you to set that in advance—so they require you to set that one particular host can only run 8 large instances, or 4 extra large, or 2 extra large, and you can't mix and match.

Newer types of dedicated hosts, so those running the Nitro virtualization platform, offer more flexibility; an example of this is an R5 dedicated host which offers 2 sockets and 48 cores. Because this is Nitro-based, you can use different sizes of instances at the same time up to your core limit of that dedicated host—so one host might be running 1 12 extra large, 1 4 extra large and 4 2 extra large, which consumes 48 cores of that dedicated host; another host might use a different configuration, maybe 4 4 extra large and 4 2 extra large, which also consumes 48 cores.

With Nitro-based dedicated hosts, there's a lot more flexibility allowing a business to maximize the value of that host, especially if they have varying requirements for different sizes of instances. Now this is a great link which I've included in the lesson text which details the different dedicated host options available—so you've got different dedicated hosts for different families of instance, for example the A1 instance family; this offers 1 physical socket and 16 physical cores and offers different configurations for different sizes of instances.

Now if you scroll all the way down, it also gives an overview of some of the Nitro-based dedicated hosts which support this mix-and-match capability—so we've got the R5 dedicated host that I just talked about on the previous screen; we've also got the C5 dedicated host and this gives 2 example scenarios. In scenario 1 you've got 1 instance of a C5 9 extra large, 2 instances of C5 4 extra large and 1 instance of C5 extra large, and that's a total cores consumed of 36; there's also another scenario though where you've got 4 times 4 extra large, 1 times extra large and 2 times large—same core consumption but a different configuration of instances. And again, I'll make sure this is included in the lesson description; it also gives the on-demand pricing for all of the different types of dedicated host.

Now there are some limitations that you do need to keep in mind for dedicated host; the first one is AMI limits—you can't use REL, Seuss Linux or Windows AMIs with dedicated host, they are simply not supported. You cannot use Amazon RDS instances—again, they're not supported. You can't utilize placement groups—they're not supported on dedicated hosts, and there's a lesson in this section which talks in depth about placement groups, but in this context, as it relates to dedicated hosts, you cannot use placement groups with dedicated hosts—it's not supported.

Now with dedicated hosts, they can be shared with other accounts inside your organization using the RAM product, which is the resource access manager—it's a way that you can share certain AWS products and services between accounts; we haven't covered it yet, but we will do later in the course. You're able to share a dedicated host with other accounts in your organization, and other AWS accounts in your organization can then create instances on that host.

Those other accounts which have a dedicated host shared into them can only see instances that they create on that dedicated host; they can't see any other instances, and you, as the person who owns the dedicated host, you can see all of the instances running on that host, but you can't control any of the instances running on your host created by any accounts you share that host with—so there is a separation: you can see all of the instances on your host, you can only control the ones that you create, and then other accounts who get that host shared with them—they can only see instances that they create, so there's a nice security and visibility separation.

Now that's all of the theory that I wanted to cover around the topic of dedicated hosts; you don't need to know anything else for the exam, and if you do utilize dedicated hosts for any production usage in the real world, it is generally going to be around software licensing. Generally using dedicated hosts, there are restrictions—obviously they are specific to a family of instance, so it gives you less customizability, it gives you less flexibility on sizing, and you generally do it if you've got licensing issues that you need solved by this product.

In most cases, in most situations, it's not the approach you would take if you just want to run EC2 instances. But with that being said, go ahead, 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 talk about an important feature of EC2 known as placement groups. Normally when you launch an EC2 instance its physical location is selected by AWS placing it on whatever EC2 host makes the most sense within the availability zone that it's launched in. Placement groups allow you to influence placement ensuring that instances are either physically close together or not. As a Solutions Architect understanding how placement groups work and why you would use them is essential so let's jump in and get started.

There are currently three types of placement groups for EC2. All of them influence how instances are arranged on physical hardware but each of them do it for different underlying reasons. At a high level we have cluster placement groups and these are designed to ensure that any instances in a single cluster placement group are physically close together. We've got spread placement groups which are the inverse ensuring that instances are all using different underlying hardware and then we've got partition placement groups and these are designed for distributed and replicated applications which have infrastructure awareness, so where you want groups of instances but where each group is on different hardware. So I'm going to cover each of them in detail in this lesson once we talk about each of them they'll all make sense.

Now cluster and spread tend to be pretty easy to understand. Partition is less obvious if you haven't used the type of application which they support but it will be clear once I've explained it and once you've finished with this lesson. Now let's start with cluster placement groups.

Cluster placement groups are used when you want to achieve the absolute highest level of performance possible within EC2. With cluster placement groups you create the group and best practice is that you launch all of the instances which will be in the group all at the same time. This ensures that AWS allocate capacity for everything that you require. So for example if you launch with nine instances imagine that AWS place you in a location with the capacity for 12. If you want to double the number of instances you might have issues. Best practice is to use the same type of instance as well as launching them all at the same time because then AWS will place all of them in a suitable location with capacity for everything that you need.

Now cluster placement groups because of their performance focus have to be launched into a single availability zone. Now how this works is that when you create the placement group you don't specify an availability zone. Instead when you launch the first instance or instances into that placement group it will lock that placement group to whichever availability zone that instance is also launched into. The idea with cluster placement groups is that all of the instances within the same cluster placement group generally use the same rack but often the same EC2 host. All of the instances within a placement group have fast direct bandwidth to all other instances inside the same placement group and when transferring data between instances within that cluster placement group they can achieve single stream transfer rates of 10 GB per second versus the usual 5 GB per second which is achievable normally.

Now this is single stream transfer rates while some instances do offer significantly faster networking you're always going to be limited to the speed that a single stream of data a single connection can achieve and inside a cluster placement group this is 10 GB per second versus 5 GB per second which is achievable normally. Now the connections between these instances because of the physical placement they're the lowest latency possible and the maximum packets per second possible within AWS. Now obviously to achieve these levels of performance you need to be using instances with high performance networking so IE more bandwidth than the 10 GB per second single stream and you should also use enhanced networking on all instances so definitely to achieve the low latency and max packets per second you do need also to use enhanced networking.

So cluster placement groups are used when you really need performance. They're needed to achieve the highest levels of throughput and the lowest consistent latencies within AWS but the trade-off is because of the physical location if the hardware that they're running on fails logically it could take down all of the instances within that cluster placement group. So cluster placement groups offer little to no resilience.

Now some key points which you need to be aware of for the exam you cannot span availability zones with cluster placement groups this is locked when launching the first instance. You can span VPC peers but this does significantly impact performance in a negative way. Cluster placement groups are not supported on every type of instance it requires a supported instance type and generally you should use the same type of instance to get the best results though this is not mandatory and you should also launch them at the same time. Also this is not mandatory but it is very recommended and ideally you should always launch all of the instances as the same type and at the same time when using cluster placement groups.

Now cluster placement groups offer 10 GB per second of single stream performance and the type of use cases where you would use them are any type of workloads which demand performance so fast speeds and low latency. So this might be things like high performance compute or other scientific analysis which demand fast node-to-node speed and low consistent latency.

Now the next type of placement group I want to talk about is spread placement groups and these are designed to ensure the maximum amount of availability and resilience for an application. So spread placement groups can span multiple availability zones in this case availability zone A and availability zone B. Instances which are placed into a spread placement group are located on separate isolated infrastructure racks within each availability zone so each instance has its own isolated networking and power supply separate from any of the other instances also within that same spread placement group. This means if a single rack fails either from a networking or power perspective the fault can be isolated to one of those racks.

Now with spread placement groups there is a limit to seven instances per availability zone because each instance is in a completely separate infrastructure rack and because there are limits on the number of these within each availability zone you do have that limit of seven instances per availability zone for spread placement groups. Now the more availability zones in a region logically the more instances can be a part of each spread placement group but remember the seven instances per availability zone in that region.

Now again just some points that you should know for the exam spread placement groups provides infrastructure isolation so you're guaranteed that every instance launched into a spread placement group will be entirely separated from every other instance that's also in that spread placement group. Each instance runs from a different rack each rack has its own network and power source and then just to stress again there is this hard limit of seven instances per availability zone. Now with spread placement groups you can't use dedicated instances or hosts they're not supported and in terms of use cases spread placement groups are used when you have a small number of critical instances that need to be kept separated from each other so maybe mirrors of a file server or maybe different domain controllers within an organization anywhere where you've got a specific application and you need to ensure as high availability for each member of that application as possible where you want to create separate blast radiuses for each of the servers within that particular application and ensure that if one fails there is a smaller chance as possible that any of the other instances will fail. You have to keep in mind these limits it's seven instances per availability zone but if you want to maximize the availability of your application this is the type of placement group to choose.

Now lastly we've got partition placement groups and these have a similar architecture to spread placement groups which is why they're often so difficult to understand fully and why it's often so difficult to pick between partition placement groups and spread placement groups. Partition placement groups are designed for when you have infrastructure where you have more than seven instances per availability zone but you still need the ability to separate those instances into separate fault domains.

Now a partition placement group can be created across multiple availability zones in a region in this example az a and az b and when you're creating the partition placement group you specify a number of partitions with a maximum of seven per availability zone in that region. Now each partition inside the placement group has its own racks with isolated power and networking and there is a guarantee of no sharing of infrastructure between those partitions.

Now so far this sounds like spread placement groups except with partition placement groups you can launch as many instances as you need into the group and you can either select the partition explicitly or have EC2 make that decision on your behalf. With spread placement groups remember you had a maximum of seven instances per availability zone and you knew 100% that each instance within that spread placement group was separated from every other instance in terms of hardware. With partition placement groups each partition is isolated but you get to control which partition to launch instances into. If you launch 10 instances into one partition and it fails you lose all 10 instances. If you launch seven instances and put one into each separate partition then it behaves very much like a spread placement group.

Now the key to understanding the difference is that partition placement groups are designed for huge scale parallel processing systems where you need to create groupings of instances and have them separated. You as the designer of a system can have control over which instances are in the same and different partitions so you can design your own resilient architecture. Partition placement groups offer visibility into the partitions. You can see which instances are in which partitions and you can share this information with topology aware applications such as HDFS, HBase and Cassandra. Now these applications use this information to make intelligent data replication decisions.

Imagine that you had an application which used 75 EC2 instances. Each of those instances had its own storage and that application replicated data three times across that 75 instances. So each piece of data was replicated on three instances and so essentially you had three replication groups each with 25 instances. If you didn't have the ability to use partition placement groups then in theory all of those 75 instances could be in the same hardware and so you wouldn't have that resiliency. With partition placement groups if the application is topology aware then it becomes possible to replicate data across different EC2 instances knowing that those instances are in separate partitions and so it allows more complex applications to achieve the same types of resilience as you get with spread placement groups only that it has an awareness of that topology and it can cope with more than seven instances.

So the difference between spread and partition placement is that with spread placement it's all handled for you but you have that seven instance per availability zone limit but with partition placement groups you can have more instances but you or your application which is topology aware needs to administer the partition placement. For larger scale applications that support this type of topology awareness this can significantly improve your resilience.

Now some key points for the exam around partition placement groups again seven partitions per availability zone instances can be placed into a specific partition or you can allow EC2 to automatically control that placement. Partition placement groups are great for topology aware applications such as HDFS, HBase and Cassandra and partition placement groups can help a topology aware application to contain the impact of a failure to a specific part of that application. So by the application and AWS working together using partition placement groups it becomes possible for large-scale systems to achieve significant levels of resilience and effective replication between different components of the application.

Now it's essential that you understand the difference between all three for the exam so make sure before moving on in the course you are entirely comfortable about the differences between spread placement groups and partition placement groups and then the different situations where you would choose to use cluster, spread and partition. With that being said though that's everything 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. So far in the course you've had a brief exposure to CloudWatch and CloudWatch logs, and you know that CloudWatch monitors certain performance and reliability aspects of EC2, but crucially only those metrics that are available on the external face of an EC2 instance.

There are situations when you need to enable monitoring inside an instance, so you have access to certain performance counters of the operating system itself, such as the ability to look at the processes running on an instance, the memory consumption of those processes, and generally access certain operating system level performance metrics that you cannot see outside the instance.

You also might want to allow access to system and application logging from within the EC2 instance, meaning both application logs and system logs from within the operating system of an EC2 instance.

So in this lesson I want to step through exactly how this works and what you need to use to achieve it, so let's get started.

Now, a quick summary of where we're at so far in the course relevant to this topic: I just mentioned you know now that CloudWatch is the product responsible for storing and managing metrics within AWS, and you also know that CloudWatch logs is a subset of that product aimed at storing, managing, and visualizing any logging data, but neither of those products can natively capture any data or logs happening inside of an EC2 instance.

The products aren't capable of getting visibility inside of an EC2 instance natively, and the inside of an instance is opaque to CloudWatch and CloudWatch logs by default.

To provide this visibility, the CloudWatch agent is required, and this is a piece of software which runs inside an EC2 instance, running on the operating system to capture OS-visible data and send it into CloudWatch or CloudWatch logs, so that you can then use it and visualize it within the console of both of those products.

Logically, for the CloudWatch agent to function, it needs to have the configuration and permissions to be able to send that data into both of those products, so in summary, in order for CloudWatch and CloudWatch logs to have access inside of an EC2 instance, there's some configuration and security work required in addition to having to install the CloudWatch agent, and that's what I want to cover over the remainder of this lesson and the upcoming demo lesson.

Architecturally, the CloudWatch agent is pretty simple to understand: we've got an EC2 instance on its own—for example, the animals for life WordPress instance from the previous demos—and it's incapable of injecting any logging into CloudWatch logs without the agent being installed.

To fix that, we need to install the CloudWatch agent within the EC2 instance, and the agent will need some configuration; it needs to know exactly what information to inject into CloudWatch and CloudWatch logs, so we need to configure the agent and supply the configuration information so that the agent knows what to do.

The agent also needs some way of interacting with AWS—some permissions—and we know now that it's bad practice to add long-term credentials to an instance, so we don't want to do that; but that aside, it's also difficult to manage that at scale.

So best practice for using this type of architecture is to create an IAM role with permissions to interact with CloudWatch logs, and then we can attach this IAM role to the EC2 instance, providing the instance—or more specifically, anything running on the instance—with access to the CloudWatch and CloudWatch logs service.

Now, the agent configuration also needs to be set up to configure the metrics and the logs that we want to capture, and these are all injected into CloudWatch using log groups; we'll configure one log group for every log file that we want to inject into the product, and then within each log group, there'll be a log stream for each instance performing this logging.

So that's the architecture: one log group for each individual log that we want to capture, and then one log stream inside that log group for every EC2 instance that's injecting that logging data.

To get this up and running for a single instance, you can do it manually—you can log into the instance, install the agent, configure it, attach a role, and start injecting the data—but at scale, you'll need to automate the process, and potentially you can use CloudFormation to include that agent configuration for every single instance that you provision.

Now, CloudWatch agent comes with a number of ways to obtain and store the configuration that it will use to send this data into CloudWatch logs, and one of those ways is to actually use the parameter store and store the agent configuration as a parameter.

Because we've just learned about parameter store, I thought it would be beneficial—along with demonstrating how to install and configure the CloudWatch agent—to also utilize the parameter store to store that configuration, and so that's what we're going to do together in the next demo lesson.

We're going to install and configure the CloudWatch agent and set it up to collect logging information for three different log files: we’re going to set it up to collect and inject logging for /var/log/secure, which shows any events relating to secure logins to the EC2 instance, and we’re also going to collect logging information for the access log and the error log, which are both log files generated by the Apache web server that's installed on the EC2 instance.

By using these three different log files, it should give you some great practical experience on how to configure the CloudWatch agent and how to use the parameter store to store configuration at scale.

So that's it for the theory for now; you can go ahead and finish off this video, and then when you're ready, you can join me in the next demo lesson where we'll be installing and configuring the CloudWatch agent.

Welcome back. In this lesson, I want to cover the Systems Manager parameter store, a service from AWS which makes it easy to store various bits of system configuration—so strings, documents, and secrets—and store those in a resilient, secure, and scalable way.

So let's step through the product’s architecture, including how to best make use of it. If you remember earlier in this section of the course, I mentioned that passing secrets into an EC2 instance using user data was bad practice because anyone with access to the instance could access all that data; well, parameter store is a way that this can be improved.

Parameter store lets you create parameters, and these have a parameter name and a parameter value, with the value being the part that stores the actual configuration. Many AWS services integrate with the parameter store natively—CloudFormation offers integrations that you've already used, which I'll explain in a second and in the upcoming demo lessons—and you can also use the CLI tooling on an EC2 instance to get access to the service.

So when I'm talking about configuration and secrets, parameter store offers the ability to store three different types of parameters: we've got strings, string lists, and secure strings. Using these three different types of parameters, you can store things inside the product such as license codes, database connection strings (so host names, ports), and you can even store full configs and passwords.

Now, parameter store also allows you to store parameters using a hierarchical structure and also stores different versions of parameters—so just like we've got object versioning in S3, inside parameter store we can also have different versions of parameters.

Parameter store can also store plain text parameters, which is suitable for things like DB connection strings or DB users, but we can also use cipher text, which integrates with KMS to allow you to encrypt parameters; this is useful if you're storing passwords or other sensitive information that you want to keep secret.

So when you encrypt using cipher text, you use KMS, and that means you need permissions on KMS as well, so there's that extra layer of security. The parameter store's also got the concept of public parameters—these are parameters publicly available and created by AWS.

You've used these earlier in the course—an example is when you've used CloudFormation to create EC2 instances, you haven't had to specify a particular AMI to use because you've consulted a public parameter made available by AWS, which is the latest AMI ID for a particular operating system in that particular region—and I'll be demonstrating exactly how that works now in the upcoming demo lessons.

Now, the architecture of the parameter store is simple enough to understand—it's a public service, so anything using it needs to either be an AWS service or have access to the AWS public space endpoints.

Different types of things can use the parameter store, so this might be things like applications, EC2 instances, all the things running on those instances, and even Lambda functions, and they can all request access to parameters inside the parameter store.

As parameter store is an AWS service, it's tightly integrated with IAM for permissions, so any accesses will need to be authenticated and authorized—and that might use long-term credentials like access keys or those credentials might be passed in via an IAM role.

And if parameters are encrypted, then KMS will be involved and the appropriate permissions to the CMK inside KMS will also be required.

Now, parameter store allows you to create simple or complex sets of parameters—for example, you might have something simple like myDB password, which stores your database password in an encrypted form, but you can also create hierarchical structures.

So something like /wordpress/ and inside there we might have something called dbUser, which could be accessed either by using its full name or requesting the WordPress part of the tree; we could also have dbPassword, which again, because it's under the WordPress branch of the tree, could be accessed along with the dbUser by pulling the whole WordPress tree or accessed individually by using its full name, so /wordpress/dbPassword.

Now, we might also have applications which have their own part of the tree, for example, my-cat-app, or you might have functional division in your organization, so giving your dev team a branch of the tree to store their passwords.

Permissions are flexible and they can be set either on individual parameters or whole trees. Everything supports versioning and any changes that occur to any parameters can also spawn events—and these events can start off processes in other AWS services, and I'll introduce this later.

I just want to mention it now so you understand that parameter store parameter changes can initiate events that occur in other AWS products.

Now, parameter store isn't a hugely complex product to understand, and so at this point, I've covered all of the theory that you'll need for the associate level exam.

What I want to do now is to finish off this theory lesson, and immediately following this is a demo where I want to show you how you can interact with the parameter store via the console UI and the AWS command line tools.

Now, it will be a relatively brief demo, and so you're welcome to just watch me perform the steps, or of course, as always, you can follow along with your own environment—and I'll be providing all the resources that you need to do that inside that demo lessons folder in the course GitHub repository.

So at this point, go ahead, finish this video, and when you're ready, you can join me in the next demo lesson.

Welcome back and in this lesson I'm going to be covering a topic which is probably slightly beyond what you need for the Solutions Architect Associate exam, but additional understanding of CloudFormation is never a bad thing and it will help you answer any automation style questions in the exam, and so I'm going to talk about it anyway. CloudFormation in it is a way that you can pass complex bootstrapping instructions into an EC2 instance, and it's much more complex than the simple user data example that you saw in the previous lesson.

Now we do have a lot to cover, so let's jump in and step through the theory before we move to another demo lesson. In the previous lesson I showed you how CloudFormation handled user data, and it works in a similar way to the console UI where you pass in base 64 encoded data into the instance operating system and it runs as a shell script. Now there's another way to configure EC2 instances, a way which is much more powerful.

It's called cfn-init, and it's officially referred to by AWS as a helper script which is installed on EC2 operating systems such as Amazon Linux 2. Now cfn-init is actually much more than a simple helper script — it's much more like a simple configuration management system. User data is what's known as procedural; it's a script, it's run by the operating system line by line. Now cfn-init can also be procedural — it can be used to run commands just like user data — but it can also be desired state, where you direct it how you want something to be.

What's the desired state of an EC2 instance, and it will perform whatever is required to move the instance into that desired state. So for example, you can tell cfn-init that you want a certain version of the Apache web server to be installed, and if that's already the case — if Apache is already installed and it's the same version — then nothing is done. However, if Apache is not installed then cfn-init will install it, or it will update any older versions to that version.

cfn-init can do lots of pretty powerful things — it can make sure packages are installed even with an awareness of versions, it can manipulate operating system groups and users, it can download sources and extract them onto the local instance even using authentication, it can create files with certain contents, permissions, and ownerships, it can run commands and test that certain conditions are true after the commands have run, and it can even control services on an instance — so in ensuring that a particular service is started or enabled to be started on the boot of the OS.

cfn-init is executed like any other command by being passed into the instance as part of the user data, and it retrieves its directives from the CloudFormation stack, and you define this data in a special part of each logical resource inside CloudFormation templates called aws double colon cloud formation double colon init — and don't worry, you'll get a chance to see this very soon in the demo.

So the instance runs cfn-init, it pulls this desired state data from the CloudFormation stack that you put in there via the CloudFormation template, and then it implements the desired state that's specified by you in that data. So let's quickly look at this architecture visually — the way that cfn-init works is probably going to be easier to understand if we do take a look at it visually, and once you see the individual components it's a lot simpler than I've made it sound on the previous screen.

It all starts off with a CloudFormation template, and this one creates an EC2 instance — and you'll see this in action yourself very soon. Now the template has a logical resource inside it called EC2 instance, which is to create an EC2 instance, and it has this new special component: metadata and aws double colon cloud formation double colon init — and this is where the cfn init configuration is stored. The cfn init command itself is executed from the user data that's passed into that instance.

So the CloudFormation template is used to create a stack which itself creates an EC2 instance, and the cfn-init line in the user data at the bottom here is executed by the instance. This should make sense now — anything in the user data 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 — specifically a stack ID and a region.

Remember, this instance is being created using CloudFormation, and so these variables are actually replaced for the actual values before this ends up inside the EC2 instance — so the region will be replaced with the actual region that the stack is created in, and the stack ID is the actual stack ID that's being created by this template, and these are all passed in to cfn-init. This allows cfn-init to communicate with the CloudFormation service and receive its configuration, and it can do that because of those variables passed into the user data by CloudFormation.

Once cfn-init has this configuration, then because it's a desired state system, it can implement the desired state that's specified inside the CloudFormation by you. And another amazing thing about this process, or about cfn-init and its associated tools, is that it can also work with stack updates.

Remember that the user data works once, while cfn-init can be configured to watch for updates to the metadata on an object in a template, and if that metadata changes, then cfn-init can be executed again and it will update the configuration of that instance to the desired state specified inside the template — it's really powerful. Now this is not something that user data can do — user data only works the once when you launch the instance.

Now in the demo lesson which immediately follows this one, you're going to experience just how cool this cfn-init process is. The WordPress CloudFormation template that you used in the previous demo — which included some user data — I've updated that and I've supplied a new version which uses this CloudFormation in its process or cfn-init, so you'll get to see how it's different and exactly how that looks when you apply it into your AWS account.

Now there's one more really important feature of CloudFormation which I want to cover — as you start performing more advanced bootstrapping, it will start to matter more and more. This feature is called CloudFormation creation policies and CloudFormation signals — so let's look at that next.

On the previous example there was another line passed into the user data — the bottom line: cfn-signal. Without this, the resource creation process inside CloudFormation is actually pretty dumb. You have a template which is used to create a stack which creates an EC2 instance — let's say you pass in some user data, this runs, and then the instance is marked as complete.

The problem though is we don't actually know if the resource actually completed successfully — CloudFormation has created the resource and passed in the user data, but I've already said that CloudFormation doesn't understand the user data, it just passes it in. So if the user data has a problem — if the instance bootstrapping process fails and from a customer perspective the instance doesn't really work — CloudFormation won't know. The instance is going to be marked as complete regardless of how the configuration is inside that instance.

Now this is fine when we're creating resources like a blank EC2 instance when there is no post-launch configuration — if EC2 reports to CloudFormation that it's successfully provisioned an instance then we can rely on that; if we're creating an S3 bucket and S3 reports to CloudFormation that it's worked okay then it's worked okay. But what if there's extra configuration happening inside the resource such as this bootstrapping process?

We need a better way — a way that the resource itself, the EC2 instance in this case, can inform CloudFormation if it's being configured correctly or not. This is how creation policies work, and this is a creation policy. A creation policy is something which is added to a logical resource inside a CloudFormation template — you create it and you supply a timeout value.

This one has 15 minutes, and this is used to create a stack which creates an instance. So far the process is the same — but at this point CloudFormation waits. It doesn't move the instance into a create complete status when EC2 signals that it's been created successfully — instead it waits for a signal, a signal from the resource itself.

So even though EC2 has launched the instance, even though its status checks pass and it's told CloudFormation that the instance is provisioned and ready to go — CloudFormation waits. It waits for a signal from the resource itself. The CFN signal command at the bottom is given the stack ID, the resource name, and the region — and these are passed in by the CloudFormation stack when the resource is created.

So the CFN signal command understands how to communicate with the specific CloudFormation stack that it's running inside. The -e $? part of that command represents the state of the previous command — so in this case the CFN init command is going to perform this desired state configuration, and if the output of that command is an OK state, then the OK is sent as a signal by CFN signal.

If CFN init reports an error code, then this is sent using CFN signal to the CloudFormation stack — so CFN signal is reporting to CloudFormation the success or not of the CFN init bootstrapping, and this is reported to the CloudFormation stack. If it's a success code — so if CFN init worked as intended — then the resource is moved into a create complete state; if CFN signal reports an error, the resource in CloudFormation shows an error.

If nothing happens for 15 minutes — the timeout value — then CloudFormation assumes it's erred and doesn't let the stack create successfully — the resource will generate an error. Now you'll see creation policies feature in more complex CloudFormation templates either within EC2 instance resources or within auto scaling groups that we'll be covering later in the course.

Now you won't need to know the technical implementation details of this for the Solutions Architect Associate exam, but I do expect the knowledge of this architecture will help you in any automation related questions. And now it's time for a quick demonstration — I just want you to have some experience in using a template which uses CFN init and also one which uses the creation policy, so I hope this theory has been useful to you and when you're ready for the demo, go ahead and complete this video and you can join me in the next.

Welcome back, and in the first real lesson of the advanced EC2 section of the course, I want to introduce EC2 Bootstrapping. Now, this is one of the most powerful features of EC2 available for us to use as solutions architects because it's what allows us to begin adding automation to the solutions that we design. Bootstrapping is a process where scripts or other bits of configuration can be run when an instance is first launched, meaning that an instance can be brought into service in a certain pre-configured state. So, unlike just launching an instance with an AMI and having it be in its default state, we can bootstrap in a certain set of configurations or software installs.

Now, let's look at how this works from a theory perspective, and then you'll get a chance to implement this yourself in the following demo lesson. Now, bootstrapping is a process which exists outside EC2 — it's a general term. In systems automation, bootstrapping is a process which allows a system to self-configure or perform some self-configuration steps. In EC2, it allows for build automation — some steps which can occur when you launch an instance to bring that instance into a configured state. Rather than relying on a default AMI or an AMI with a pre-baked configuration, it allows you to direct an EC2 instance to do something when launched, so perform some software installations and then some post-installation configuration.

With EC2, bootstrapping is enabled using EC2 user data, and this is injected into the instance in the same way that metadata is. In fact, it's accessed using the metadata IP address — so 169.254, 169.254, also known as 169.254 repeating — but instead of latest /meta-data, it's latest /user-data. The user data is a piece of data, a piece of information that you can pass into an EC2 instance, and anything that you pass in is executed by the instance's operating system. And here's the important thing to remember — it's executed only once at launch time. If you update the user data and restart an instance, it's not executed again, so it's only the once. User data applies only to the first initial launch of the instance — it's for launch time configuration only.

Now, another important aspect is that EC2 as a service doesn't validate this user data, it doesn't interpret it in any way. You can tell EC2 to pass in some random data and it will, you can tell EC2 to pass in commands which will delete all of the data on the boot volume and the instance will do so. EC2 doesn't interpret the data — it just passes the data into the instance via user data, and there's a process on the operating system which runs this as the root user. So, in summary, the instance needs to understand what you pass in because it's just going to run it.

Now, the bootstrapping architecture is pretty simple to understand — an AMI is used to launch an EC2 instance in the usual way and this creates an EBS volume which is attached to the EC2 instance, and that's of course based on the block device mapping inside the AMI. This part we understand already. Where it starts to differ is that now the EC2 service provides some user data through to the EC2 instance, and there's software within the operating system running on EC2 instances which is designed to look at the metadata IP for any user data, and if it sees any user data then it executes this on launch of that instance.

Now, this user data is treated just like any other script that the operating system runs — it needs to be valid, and at the end of running the script the EC2 instance will either be in a running state and ready for service, meaning that the instance has finished its startup process, the user data ran and it was successful, and the instance is in a functional and running state. Or, the worst case is that the user data errors in some way, so the instance would still be in a running state because the user data is separate from EC2 — EC2 just delivers it into the instance. The instance would still pass its status checks, and assuming you didn't run anything which deleted mass amounts of OS data, you could probably still connect to it, but the instance would likely not be configured as you want — it would be a bad configuration. So that's critical to understand — the user data is just passed in in an opaque way to the operating system, it's up to the operating system to execute it, and if executed correctly the instance will be ready for service. If there's a problem with the user data, you will have a bad config — this is one of the key elements of user data to understand. It's one of the powerful features but also one of the risky ones — you pass the instance user data as a block of data, it runs successfully or it doesn't, and from EC2's perspective it's simply opaque data, it doesn't know or care what happens to it.

Now, user data is also not secure — anyone who can access the instance operating system can access the user data, so don't use it for passing in any long-term credentials, at least not ideally. Now in the demo, we'll be doing just that — we'll be doing bad practice by passing into the instance using the user data some long-term credentials, but this is intentional — it's part of your learning process. As we move through the course, we'll evolve the design and implementations to use more AWS services, and some of these include better ways to handle secrets inside EC2, so I need to show you the bad practice before I can compare it to the good.

Now, user data is limited to 16 kilobytes in size — for anything more complex than that, you would need to pass in a script which would download that larger data. User data can be modified — if you shut down the instance, change the user data and start it up again, then new data is available inside the instance's user data, but the contents are only executed once when you initially launch that instance. So after the launch stage, user data is only really useful for passing data in, and there are better ways of doing that. So keep in mind for the exam — user data is generally used the once for the post-launch configuration of an instance — it's only executed the one initial time.

Now, one of the question types that you'll often face in the exam relates to how quickly you can bring an instance into service. There's actually a metric — boot time to service time — how quickly after you launch an instance is it ready for service, ready to accept connections from your customers, and this includes the time that AWS requires to provision the EC2 instance and the time taken for any software updates, installations or configurations to take place within the operating system. For an AWS-provided AMI, that time can be measured in minutes — from launch time to service time it's generally only minutes. But what if you need to do some extra configuration, maybe install an application?

Remember when you manually installed WordPress after launching an instance — this is known as post-launch time, the time required after launch for you to perform manual configuration or automatic configuration before the instance is ready for service. If you do it manually, this can be a few minutes or even as long as a few hours for things which are significantly more complex. Now, you can shorten this post-launch time in a few ways. The topic of this very lesson is bootstrapping, and bootstrapping as a process automates installations after the launch of an instance, and this reduces the amount of time taken to perform these steps, and you'll see that demoed in the next lesson.

Now, alternatively, you can also do the work in advance by AMI baking — with this method, you're front-loading the work, doing it in advance and creating an AMI with all of that work baked in. Now, this removes the post-launch time, but it means you can't be as flexible with the configuration because it has to be baked into the AMI. Now, the optimal way is to combine both of these processes — so AMI baking and bootstrapping — you'd use AMI baking for any part of the process which is time intensive. So, if you have an application installation process which is 90% installation and 10% configuration, you can AMI bake in the 90% part and then bootstrap the final configuration. That way, you reduce the post-launch time and thus the boot time to service time, but you also get to use bootstrapping which gives you much more configurability.

And I'll be demonstrating this architecture later in the course when I cover scaling and high availability, but I wanted to introduce these concepts now so you can keep mulling them over and understand them when I mention them. But now, it's time to finish up this lesson — and this has been the theory component of EC2 bootstrapping. In the next lesson, which is a demo, you're going to have the chance to use the EC2 user data feature.

Remember earlier in the course where we built an AMI together, we installed WordPress to the point when it was ready to install, and we massively improved the login banner of the EC2 instance to be something more animal related with Cowsay? In the next demo lesson, you're going to implement the same thing — but you're going to be using user data. You'll see how much quicker this process is to do, though, when you had to manually launch the instance and run each command one by one. It's going to be a good, valuable demo — I can't wait to get started, so go ahead, finish this video, and when you're ready, you can join me for some practical time.

Welcome back. In this lesson, I want to talk about a really important feature of EC2 called Instance Metadata. It's a very simple architecture, but it's one that's used in many of EC2's more powerful features, so it's essential that you understand its architecture fully. It features in nearly all of the AWS exams, and you will use it often if you design and implement AWS solutions in the real world, so let's jump in and get started.

The EC2 Instance Metadata is a service that EC2 provides to instances. It's data about the instance that can be used to configure or manage a running instance. It's a way the instance or anything running inside the instance can access information about the environment that it wouldn't be able to access otherwise, and it's accessible inside all instances using the same access method. The IP address to access the instance metadata is 169.254.169.254. Remember that IP, it comes up all the time in exams, so make sure it sticks. I'll repeat it as often as I can throughout the course, but it's unusual enough that it tends to stick pretty well.

Now, the way that I've remembered the IP address from when I started with AWS is just to keep repeating it. Repetition always helps, and I remember this one as a little bit of a rhyme: 169.254 repeated. And if you just keep repeating that over and over again, then the IP address will stick. So 169.254 repeated equals 169.254.169.254. And then for the next part of the URL, I always want the latest meta-data. If you remember 169.254 repeated and you always want the latest meta-data, it will tend to stick in your mind, at least it did for me.

Now, I've seen horrible exam questions which make you actually select the exact URL for this metadata, so this is one of those annoying facts that I just need you to memorize. I promise you it will help you with exam questions in the exam, so try to memorize the IP and latest meta-data. If you remember both of those, keep repeating them. Get annoying over and over again. Write them on flashcards. It will help you in the exam.

Now, the metadata allows anything running on the instance to query it for information about that instance, and that information is divided into categories. For example, host name, events, security groups and much more. All information about the environment that the instance is in. The most common things which can be queried though are information on the networking, and I'll show you this in the demo part of this lesson. While the operating system of an instance can't see any of its IP version for public addressing, the instance meta-data can be used by applications running on that instance to get access to that information, and I'll show you that soon.

You can also gain access to authentication information. We haven't covered EC2 instance roles yet, but instances can be themselves given permissions to access AWS resources, and the meta-data is how applications on the instance can gain access to temporary credentials generated by assuming the role. The meta-data service is also used by AWS to pass in temporary SSH keys. So when you connect to an instance using EC2 instance connect, it's actually passing in an SSH key behind the scenes that's used to connect. The meta-data service is also used to grant access to user data, and this is a way that you can make the instance run scripts to perform automatic configuration steps when you launch an instance.

Now one really important fact for the exam, and I've seen questions come up on this one time and time again, the meta-data service has no authentication, and it's not encrypted. Anyone who can connect to an instance and gain access to the Linux command line shell can by default access the meta-data. You can restrict it with local firewall rules, so blocking access to the 169.254 repeated IP address, but that's extra per instance admin overhead. In general, you should treat the meta-data as something that can and does get exposed.

Okay, well that's the architecture, it's nice and simple, but this is one of the things inside AWS which is much easier to show you than to tell you about. So it's time for a demo, and we're going to perform a demo together which uses the instance meta-data of an EC2 instance. So let's switch over to the console and get started.

Now, if you do want to follow along with this in your own environment, then you'll need to apply some infrastructure. Before you do that, just make sure that you're logged in to the general AWS account, so the management account of the organization, and make sure as always that you have the Northern Virginia region selected. Now this lesson has a one-click deployment link attached to it, so go ahead and click that link. This will take you to the quick create stack screen. You should see that the stack name is called meta-data, just scroll down to the bottom, check this box and click on create stack. Now, this will automatically create all of the infrastructure which we'll be using, so you'll need to wait for this stack to move into a create complete state.

We're also going to be using some commands within this demo lesson, and also attached to this lesson is a lesson commands document which includes all of the commands that you'll be using. So this will help you avoid errors. You can either type these out manually or copy and paste them as I do them in the demo. So at this point go ahead and open that link as well. It should look something like this. There's not that many commands that we'll be using, but they are relatively long, and so by using this document we can avoid any typos.

Now just refresh this stack. Again, it will need to be in a create complete state, so go ahead and pause this video, wait for the stack to move into create complete and then we good to continue. Okay, so now the stack's moved into a create complete state, and if you just go ahead and click on resources, you can see that it's created a selection of resources. Now the one that we're concerned with is public EC2 which is an EC2 instance running in a public subnet with public IP addressing. So we're going to go ahead and interact with this instance. So click on services and then go ahead and move to the EC2 console. You can either select it in all services, recently visited if you've used this service before or you can type EC2 into the search box and then open it in a new tab. Once you're at the EC2 console go ahead and click on instances running, and you should see this single EC2 instance. Go ahead and select it, and I just want to draw your attention to a number of key pieces of information which I want you to note down.

So first you'll be able to see that the instance has a private IP version 4 address. Yours may well be different if you're doing this within your own environment. You'll also see that the instance has a public IP version 4 address, and again if you're doing this in your environment, yours will be different. Now, if you click on networking, you'll be able to see additional networking information including the IP version 6 address that's allocated to this instance. Now the IP version 6 address is always public, and so there's no concept of public and private IP version 6 addresses, but you'll be able to see that address under the networking tab.

Now just to make this easier, just go ahead and note down the IP version 6 address as well as the public IP version 4 DNS which is listed as well as the public IP version 4 address which is listed at the top and then the private IP version 4 address. And once you've got all these noted down, we're going to go ahead and connect to this instance. So right click select connect, we're going to use EC2 instance connect, so make sure that the username is EC2 hyphen user and then connect to this instance. Now once we connected straight away, we'll be able to see how even the prompt of the instance makes visible the private IP version 4 address of this EC2 instance and if we run the Linux command of if config and press enter we'll get an output of the network interfaces within this EC2 instance.

Now we'll be able to see the private IP version 4 address listed within the configuration of this network interface inside the EC2 instance, and if you're performing this in your own environment, notice how it's exactly the same as the private IP version 4 address that you just noted down which was visible inside the console UI. So in my case you'll be able to see these two IP addresses match perfectly. So this IP address that's visible in the console UI is the same as this private IP address configured on the network interface inside the instance. The same is true of the IP version 6 IP address. This is also visible inside the operating system on the network configuration for this network interface and again that's the same IP version 6 address which is visible on the networking tab inside the console UI. So that's the same as this address. What isn't visible inside the instance operating system on the networking configuration is the public IP version 4 address.

It's critical to know that at no point ever during the life cycle of an EC2 instance is a public IP version 4 address configured within the operating system. The operating system has no exposure to the public IP version 4 address. That is performed by the internet gateway. The internet gateway translates the private address into a public address. So while IP version 6 is configured inside the operating system, IP version 4 public addresses are not. The only IP version 4 addresses that an instance has are the private IP addresses and that's critical to understand.

Now as I talked about in the theory component of this lesson, the EC2 metadata service is a service which runs behind all of the EC2 instances within your account and it's accessible using the metadata IP address. Now we can access this by using the curl utility. Now curl is installed on the EC2 instance that we're using for this demo. Now we're going to query the metadata service for one particular attribute and that attribute is the public IP version 4 address of this instance. So because the instance operating system has no knowledge of the public IP address, we can use the metadata service to provide any scripts or applications running on this instance with visibility of this public IP version 4 address, and we do that using this command.

So this uses curl to query the metadata service which is 169.254.169.254. I refer to this as 169.254 repeating. So it queries this IP address and then forward slash latest forward slash meta hyphen data and this is the metadata URL, this entire part, the IP address, then latest, then meta hyphen data and then at the end we specify the attribute which we want to retrieve which is public hyphen IPv4 and if we press enter then curl is going to contact the metadata service and retrieve the public IP version 4 address of this EC2 instance. So in my case this is the IP address and if I go back to the console this matches the address that's visible within the console UI.

So if I just clear the screen to make it easier to see, we can also use the same command structure again but this time query for the public host name of this EC2 instance. We use the same URL so IP address and path, but this time we query for public hyphen host name and this will give us the IPv4 public DNS of this EC2 instance. So again I'm going to clear the screen to make it easier to see.

Now we can make this process even easier. We can use the AWS instance metadata query tool and to download it we use this command so enter it and press enter. This is just downloaded the tool directly, so if we do a listing to list the current folder, we can see the EC2 hyphen metadata tool because this is Linux we need to make it so that this tool is executable. We do that with the chmod command so enter that and press enter and then we can run the EC2 hyphen metadata tool and we can use double hyphen help to display help for this product. So this shows all the different information that we can use this tool to query for and this just makes it easier to query the metadata service especially if the query is being performed by users running interactively on that EC2 instance.

So for example, we could run EC2 hyphen metadata space hyphen a to show the AMI ID that's used to launch this instance, and in this case it's the AMI for Amazon Linux 2 inside the US hyphen east hyphen one region at least at the time of creating this demo video. If we need to show the availability zone that this instance is in, we could use EC2 hyphen metadata space hyphen Z, in this case the instance is in US hyphen east hyphen one a and we can even use EC2 hyphen metadata space hyphen s to show any security groups which were launched with this instance. Now you can carry on exploring this tool if you want, there are plenty of other pieces of information which are accessible using the metadata tool. I just wanted to give you a brief introduction, show you how to download it, how to make it executable and how to run some of the basic options.

Now at this point that's everything I wanted to cover in this brief demo component of this lesson. I wanted to give you some exposure to how you can interact with the metadata service which I covered from a theory perspective earlier in this lesson. Now at this point we need to clear up all of the infrastructure that we've used for this demo component so close down this tab, go back to the AWS console, move to cloud formation, select the metadata stack, select delete and then confirm it and that will clear up all of the infrastructure that we've used and return the account into the same state as it was at the start of this demo component of this video.

Now at that point that's everything I wanted to cover. You've learned about the theory of the metadata service as well as experienced how to interact with it from a practical perspective. So go ahead and complete this video and when you're ready I'll look forward to you joining me.

Welcome back. In this lesson, I want to cover a little bit more theory, something which you'll need to understand from now on in the course because the topics that we'll discuss and the examples that we'll use to fully understand those topics will become ever more complex. Horizontal and vertical scaling are two different ways that a system can scale to handle increasing or, in some cases, decreasing load placed on that system, so let's quickly step through the difference and look at some of the pros, cons, and requirements of each. Scaling is what happens when systems need to grow or shrink in response to increases or decreases of load placed upon them by your customers. From a technical perspective, you're adding or removing resources to a system. A system can in some cases be a single compute device such as an EC2 instance, but in some cases could be hundreds, thousands, tens of thousands, or even hundreds of thousands, or more of individual devices.

Vertical scaling is one way of achieving this increase in capacity, so this increase of resource allocation. The way it works is simple. Let's say, for example, we have an application and it's running on an EC2 instance, and let's say that it's a T3.large, which provides two virtual CPUs and eight GiB of memory. The instance will service a certain level of incoming load from our customers, but at some point, assuming the load keeps increasing, the size of this instance will be unable to cope, and the experience for our customers will begin to decrease. Customers might experience delays, unreliability, or even outright system crashes. So the commonly understood solution is to use a bigger server. In the virtual world of EC2, this means resizing the EC2 instance. We have lots of sizes to choose from. We might pick a T3.extralarge, which doubles the virtual CPU and memory, or if the rate of increase is significant, we could go even further and pick another size up, a T3.2 XL, which doubles that again to eight virtual CPUs and 32 GiB of memory.

Let's talk about a few of the finer points though of vertical scaling. When you're actually performing vertical scaling with EC2, you're resizing an EC2 instance, and because of that, there's downtime, often a restart during the resize process, which can potentially cause customer disruption. But it goes beyond this because of this disruption, it means that you can only scale generally during pre-agreed times, so within outage windows. If incoming load on a system changes rapidly, then this restriction of only being able to scale during outage windows limits how quickly you can react, how quickly you can respond to these changes by scaling up or down. Now as load increases on a system, you can scale up, but larger instances often carry a price premium. So the increasing cost going larger and larger is often not linear towards the top end. And because you're scaling individual instances, there's always going to be an upper cap on performance. And this cap is the maximum instance size. While AWS are always improving EC2, there will always be a maximum possible instance size, and so with vertical scaling, this will always be the cap on the scaling of an individual compute resource.

Now there are benefits of vertical scaling. It's really simple and it doesn't need any application modification. If an application can run on an instance, then it can run on a bigger instance. Vertical scaling works for all applications, even monolithic ones, where the whole code base is one single application because it all runs on one instance and that one instance can increase in size. Horizontal scaling is designed to address some of the issues with vertical scaling, so let's have a look at that next. Horizontal scaling is still designed to cope with changes to incoming load on a system, but instead of increasing the size of an individual instance, horizontal scaling just adds more instances. The original one instance turns into two as load increases, maybe two more added. Eventually, maybe eight instances are required. As the load increases on a system, horizontal scaling just adds additional capacity.

The key thing to understand with horizontal scaling is that with this architecture, instead of one running copy of your application, you might have two or 10 or hundreds of copies, each of them running on smaller compute instances. This means they all need to work together, all need to take their share of incoming load placed on the system by customers, and this generally means some form of load balancer. A load balancer is an appliance which sits between your servers, in this case instances, and your customers. When customers attempt to access the system, all that incoming load is distributed across all of the instances running your application. Each instance gets a fair amount of the load and for a given customer, every mouse click, every interaction with the application, could be on the same instance or randomized across any of the available instances.

Horizontal scaling is great, but there are a few really important things that you need to be aware of as a solutions architect. When you think about horizontal scaling, sessions are everything. When you log into an application, think about YouTube, about Netflix, about your email. The state of your interaction with that application is called a session. You're using this training site right now and if I deleted your session right at this moment, then the next time you interacted with the site, you would be logged out. You might lose the position of the video that you're currently watching. On amazon.com or your home grocery shopping site, the session stores what items are in your cart. With a single application running on a single server, the sessions of all customers are generally stored on that server. With horizontal scaling, this won't work. If you're shopping on your home grocery site and you add some cat cookies to your cart, this might be using instance one. When you add your weekly selection of donuts, you might be using instance 10. Without changes, every time you moved between instances for a horizontally scaled application, you would have a different session or no session. You would be logged out, the application, put simply, would be unusable. With horizontal scaling, you can be shifting between instances constantly. That's one of the benefits. It evens out the load. And so horizontal scaling needs either application support or what's known as off-host sessions.

If you use off-host sessions, then your session data is stored in another place, an external database. And this means that the servers are what's called stateless. They're just dumb instances of your application. The application doesn't care which instance you connect to because your session is externally hosted somewhere else. That's really the key consideration with horizontal scaling. It requires thought and design so that your application supports it. But if it does support it, then you get all of the benefits. The first one of those benefits is that you have no disruption while you're scaling because all you're doing is just adding instances. The existing ones aren't being impacted. So customer connections remain unaffected. Even if you're scaling in, so removing instances because sessions should be off-host, so externally hosted, connections can be moved between instances, leaving customers unaffected. So that's a really powerful feature of having externally hosted sessions together with horizontal scaling. It means all of the individual instances are just dumb instances. It doesn't matter to which instance a particular customer connects to at a particular time because the sessions are hosted externally. They'll always have access to their particular state in the application.

And there's no real limits to horizontal scaling because you're using lots of smaller, more common instances. You can just keep adding them. There isn't the single instance size cap which vertical scaling suffers from. Horizontal scaling is also often less expensive. You're using smaller commodity instances, not the larger ones which carry a premium. So it can be significantly cheaper to operate a platform using horizontal scaling. And finally, it can allow you to be more granular in how you scale. With vertical scaling, if you have a large instance and go to an extra-large, which is one step above it, you're pretty much doubling the amount of resources allocated to that system. With horizontal scaling, if you're currently using five small instances and you add one more, then you're scaling by around 20%. The smaller instances that you use, the better granularity that you have with horizontal scaling.

Now, there's a lot more to this. Later in the course, in the high availability and scaling section, I'll introduce elasticity and how we can use horizontal scaling as a component of highly available and fault-tolerant designs. But for now, I'll leave you with a visual exam power-up. Visuals often make things easier to understand, and they help especially with memory recall. So when it comes to remembering the different types of scaling methods, picture this, two types of scaling. First, horizontal scaling, and this adds and removes things. So if we're scaling Bob, one of our regular course guest stars, then scaling Bob in a horizontal way would mean moving to two Bob, which is scary enough. But if the load required it, we might even have to move to four Bob. And if we needed huge amounts of capacity, if four Bob wasn't enough, if you needed more and more and more, and even more Bob, then horizontal scaling has you covered. There isn't really a limit. We can scale Bob infinitely. In this case, we can have so many Bobs. We can scale Bob up to a near-infinite level as long as we're using horizontal scaling. Scaling Bob in a vertical way, that starts off with a small Bob, then moves to a medium Bob, and if we really need more Bob, then we can scale to a large Bob. In the exam, when you're struggling to remember the difference between horizontal scaling and vertical scaling, picture this image. I guarantee with this, you will not forget it. But at this point, that's all of the theory that I wanted to cover. Go ahead, complete the video, and when you're ready, you can join me in the next.

Welcome back. This lesson will be a pretty brief one as we're going to be covering instant status checks and EC2 auto recovery. They're both pretty simple features, but let's quickly step through exactly what both of them do and what capabilities they offer because they're great things to understand. Every instance within EC2 has two high-level per instance status checks. When you initially launch an instance, you might see these listed as initializing, and then you might see only one of two passing, but eventually, all instances should move into the two out of two passed checks, which indicate that all is well within the instance. If not, you have a problem. Each of the two checks represents a separate set of tests, and so a failure of either of them suggests a different set of underlying problems.

The first status check is the system status, and the second is the instance status. A failure of the system status check could indicate one of a few major problems, such as the loss of system power, loss of network connectivity, or software or hardware issues with the EC2 host. So, this check is focused on issues impacting the EC2 service or the EC2 host. The second check focuses on instances, so a failure of this one could indicate things like a corrupt file system or incorrect networking on the instance itself. For example, maybe you've statically set a public IPv4 address on the internal interface of the operating system, which you now know won't work ever, or maybe the instance is having operating system kernel issues preventing it from correctly starting up.

Assuming that you haven't just launched an instance, anything but two out of two checks represents an issue that needs to be resolved. One way to handle it is manually, such as manually stopping and starting an instance, restarting it, or terminating and recreating an instance. There are manual activities that you could perform, but EC2 comes with a feature allowing you to recover automatically from any system check issues. You can ask EC2 to stop a failed instance, reboot it, terminate it, or you can ask EC2 to perform auto recovery. Auto recovery moves the instance to a new host, starts it up with exactly the same configuration as before, so all IP addressing is maintained, and if software on the instance is set to auto start, this process could mean that the instance, as the name suggests, automatically recovers fully from any failed status check issues.

Now, it's far easier to show you exactly how this works, so let me quickly switch over to my console. I'm currently logged in to the general AWS account, the management account of the organization. I'm using the IAM admin user, and I've currently got the Northern Virginia region selected. Now, the demo part of this lesson is going to be really brief, and so it's probably not worth you following along in your own environment. If you do want to, though, there is a one-click deployment attached to this lesson, so if you're following along, click that link, scroll to the bottom, check the acknowledgement box, and click create stack. It'll need to be in a create complete state before you continue, so if you are following along, pause the video, wait for your stack to move into create complete, and then you're good to continue.

So now we're in a create complete state, let's go ahead and move to the EC2 console. This one-click deployment link has created a single instance, so that should already be in place. Go ahead and select it and then click on the status checks tab. So, if we select the status checks tab for this particular instance, you'll see the system status checks and the instance status checks, and for both of these, my EC2 instance has passed, so the system reliability check has passed and the instance reachability check has passed, so that's good.

Now, if we wanted to create a process that will be capable of auto recovery on this instance, to do that, we'd click on the actions dropdown and then create status check alarm. Go ahead and do that, and that will open this dialogue. So, this is an alarm inside CloudWatch that will alarm if this instance fails any of these status checks. What we can do as a default is to have it send a notification to an SNS topic, and the conditions mean this notification will be sent whenever any status checks fail, so either of the two, for at least one consecutive period of five minutes. So, it will need to fail either of these status checks for one period in five minutes, and then this alarm will be triggered.

Now, we can also select this box, which means that action will be taken in addition to a notification being sent, and we can have it reboot the instance, which is just the equivalent of an operating system reboot. We can have it stop the instance, which is useful if we want to perform any diagnostics. We can have it terminate the instance. Now, this is useful if you have any sort of high availability configured, which I'll be demonstrating later in the course because what this means is if you terminate an instance, you can configure EC2 to automatically reprovision a brand new instance in its place. If we do this in isolation on a single instance, it will simply terminate the instance, and it won't be replaced, but what I want to focus on is this option, which is recover this instance. This uses the auto recovery feature of EC2. This feature will attempt to recover this instance; it will take a set of actions. It could be a simple restart, or it could be to migrate the instance to a whole new EC2 host, but importantly, it would need to be in the same availability zone. Remember, EC2 is an AZ-based service, and so logically this won't protect you against an entire AZ failure. It will only take action for an isolated failure, either the host or the instance.

Now, this feature does rely on having spare EC2 host capacity, so in the case of a major failure in multiple availability zones in a region, there is a potential that this won't work if there is not spare capacity. You also need to be using modern types of instances, such as A1, C4, C5, M4, M5, R3, R4, and R5. I'll make sure I include a link in the lesson text that gives a full overview of all of the supported types, and also, this feature won't work if you're using instance store volumes, so it'll only work on instances that solely have EBS volumes attached.

It's a simple way that EC2 adds some automation, which can attempt to recover an instance and avoid waking up a sysadmin. It's not designed to automatically recover against large scale or complex system issues, so do keep that in mind. It's a very simple feature, which answers a very narrow set of error-based scenarios. It's not something that's going to fix every problem in EC2. There are other ways of doing that, which we'll talk about later in the course.

Now, we are at the end of everything that I wanted to cover in this demo lesson, but we're not going to clear up the infrastructure that we used because I'll be using it in the following demo lesson to demonstrate EC2 termination protection. So, if you are following along with these in your own environment, then don't delete the one-click deployment that you used at the start of this lesson because we'll be using it in the following demo lesson. So that's it though, that's everything that I wanted to cover in this lesson. I did promise it would be brief. If you go ahead and complete the video, and when you're ready, I'll see you in the next.

Welcome back. In the previous lesson, I talked about EC2 launch types, and one of those types was reserved. Historically, there was only one type of reserved purchase option, but over time, AWS has added newer, more flexible options, and so reserved has become known as standard reserved. As I talked about in the previous lesson, these are great for known long-term consistent usage. If you need access to the cheapest EC2 running 24/7/365 every day for one or three years, then you would pick standard reserved, but you do have a number of other, more flexible options.

Scheduled reserved instances are pretty situational, but when faced with those situations, they offer some great advantages. They're great for when you have long-term requirements, but that requirement isn't something which needs to run constantly. Let's say you have some batch processing that needs to run daily for five hours. You know this usage is required every day, so it is long-term, and it's known usage, so you're comfortable with the idea of locking in this commitment, but a standard reserved instance won't work because it's not running 24/7/365. A scheduled reserved instance is a commitment; you specify the frequency, the duration, and the time. In this case, 2300 hours daily for five hours. You reserve the capacity and get that capacity for a slightly cheaper rate versus on-demand, but you can only use that capacity during that time window.

Other types of situations might be weekly data, so sales analysis which runs every Friday for a 24-hour period, or you might have a larger analysis process which needs 100 hours of EC2 capacity per month, and so you purchase a scheduled reservation to cover that requirement. You reserve capacity and get it slightly cheaper. There are some restrictions; it doesn't support all instance types or regions, and you need to purchase a minimum of 1200 hours per year. While you are reserving partial time blocks, the commitment that you make to AWS is at least one year, so the minimum period that you can buy for scheduled reserved is one year. This is ideal for long-term known consistent usage, but where you don't need it for the full time period. If you only need access to EC2 for specific hours in a day, specific days of the week, or blocks of time every month, then you should look at scheduled reserved instances.

Now let's move on because I want to discuss capacity reservations. I mentioned earlier in the course that certain events such as major failures can result in a situation where there isn't enough capacity in a region or an availability zone. In that situation, there's an order to things, a priority order which AWS uses to deliver EC2 capacity. First, AWS delivers on any commitments in terms of reserved purchases, and then once they've been delivered, they can satisfy any on-demand request, so this is priority number two, and then after both of those have been delivered, any leftover capacity can be used via the spot purchase option.

So capacity reservations can be useful when you have a requirement for some compute which can't tolerate interruption. If it's a business-critical process which you need to guarantee that you can launch at a time that you need that compute requirement, then you definitely need to reserve the capacity. Now, capacity reservation is different from reserved instance purchase, so there are two different components. There's a billing component and a capacity component, and both of these can be used in combination or individually. There are situations where you might need to reserve some capacity, but you can't justify a long-term commitment to AWS in the form of a reserved instance purchase.

So let's step through a couple of the different options that we have available. To illustrate this, we'll start with an AWS region and two availability zones, AZA and AZB. Now, when it comes to instance reservation and capacity, we have a few options. First, we could purchase a reservation but make it a regional one, and this means that we can launch instances into either AZ in that region, and they would benefit from the reservation in terms of billing. So by purchasing a regional reservation, you get billing discounts for any valid instances launched into any availability zone in that region. So while region reservations are flexible, they don't reserve capacity in any specific availability zone, and so when you're launching instances, even if you have a regional reservation, you're launching them with the same priority as on-demand instances.

Now, with reservations, you can be more specific and pick a zonal reservation. Zonal reservations give you the same billing discount that is delivered using regional reservations, but they also reserve capacity in a specific availability zone. But they only apply to that one specific availability zone, meaning if you launch instances into another availability zone in that region, you get neither benefit. You pay the full price and don't get capacity reservations. Whether you pick regional or zonal reservations, you still need to commit for either a one or three-year term to AWS, and there are just some situations where you're not able to do that. If the usage isn't known, or if you're not sure about how long the usage will be required, then often you can't commit to AWS for a one or three-year reserved term purchase, but you still need to reserve the capacity.

So there is another option. You can choose to use on-demand capacity reservations. With on-demand capacity reservation, you're booking capacity in a specific availability zone, and you always pay for that capacity regardless of if you consume it. So in the example that's on screen now, we're booking capacity within AZB for two EC2 instances, and we bill for that capacity whether we consume it or not. So right now with the example as on screen, we bill for two EC2 instances. What we can do is launch an instance into that capacity, and now we still bill for two, but we're using one. So if we don't consume any of that capacity in this case, if we only have the one EC2 instance, we're wasting billing for an entire EC2 instance. So with capacity reservations, you still do need to do a planning exercise and plan exactly what capacity you require, because if you do book the capacity and don't use it, you will still incur the charge.

Now, capacity reservations don't have the same one or three-year commitment requirements that you need for reserved instances. You're not getting any billing benefit when using capacity reservations. You're just, as the name suggests, reserving the capacity. So at any point, you can book a capacity reservation if you know you need some EC2 capacity without worrying about the one or three-year term commitments, but you don't benefit from any cost reduction. So if you're using capacity reservations for something that's consistent, you should look at a certain point to evaluate whether reserved instances are going to be more economical.

Now one last thing that I want to talk about before I finish this lesson is a feature called a savings plan. And you can think of a savings plan as kind of like a reserved instance purchase, but instead of focusing on a particular type of instance in an availability zone or a region, you're making a one or three-year commitment to AWS in terms of hourly spend. So you might make a commitment to AWS that you're going to spend $20 per hour for one or three years, and in exchange for doing that, you get a reduction on the amount that you're paying for resources.

Now savings plans come in two main types. You can make a reservation for general compute dollar amounts, and if you elect to create a general compute savings plan, then you can save up to 66% versus the normal on-demand price of various different compute services. Or you can choose an EC2 savings plan which has to be used for EC2, but offers better savings up to 72% versus on-demand. Now, a general compute savings plan is valid for various different compute services, currently EC2, Fargate, and Lambda. Now the way that this works is products have their normal on-demand rate, so this is true for EC2, Fargate, and Lambda, but those products also have a savings plan rate. And the way that this works is when you're spending money on an hourly basis, if you have a savings plan, you get the savings plan rate up to the amount that you commit. So if you've made a commitment of $20 per hour and you consume EC2, Fargate, and Lambda, you'll get access to all three of those services at the savings plan rate until you've consumed that $20 per hour commitment. And after that, you start using the normal on-demand rate.

So a savings plan is an agreement between you and AWS where you commit to a minimum spend, and in return, AWS gives you cheaper access to any of the applicable resources. If you go above your savings plan, then you begin to consume the normal on-demand rate. And over time, generally, you'd continually evaluate your resource usage within the account and adjust your savings plan usage as appropriate. Now, out of all the compute services available in AWS, if you only consume EC2, then you will get better savings by looking at an EC2 savings plan. But if you're the type of organization that's evaluating how you can use emerging architectures such as containerization or serverless, then you can pick a general savings plan, commit to a certain hourly spend, and then utilize that over the full range of supported AWS compute services.

And as a real-world hint and for the exam, this could allow an organization that's migrating away from EC2-based compute towards these emerging architectures to get cost-effective access to resources. So they'd use a general compute savings plan providing access to EC2, Fargate, and Lambda, and over time migrate away from EC2 towards Fargate and then over the long term, potentially from Fargate through to Lambda and fully serverless architectures. Now, for the exam, you only need to be aware that savings plans exist and exactly how they work, but in the real world, you should definitely do a bit of extra reading around savings plans because they're a really powerful feature that can help you achieve significant cost savings. With that being said, though, that's everything I wanted to cover in this theory lesson. So go ahead, complete the lesson, and then when you're ready, I'll look forward to you joining me in the next.