AWS Compute Explained for Beginners - CLF C02

Added: 2026-05-31

[00:00:00]Hey, this is Andrew Brown from Exam Pro, and we are looking computing services.

[00:00:04]And before we jump into the entire suite of computing services AWS have, let's just talk about EC2 for a moment, which allows you to launch virtual machines. So, what is a virtual machine? Well, a virtual machine or VM is an emulation of a physical computer using software. Server virtualization allows you to easily create, copy, resize, or migrate your server. Multiple VMs can run on the same physical server, so you can share the cost with other customers. So, imagine if your server or computer was an executable file on your computer, okay? So, that's the kind of way you want to think about it. When we launch a VM, we call it an instance. And so, EC2 is highly configurable server where you can choose the AMI, so the Amazon machine image, that affects options such as amount of CPUs or vCPUs, virtual CPUs, the amount of memory, so RAM, the amount of network bandwidth, the operating system, so whether it's Windows, Ubuntu, Amazon Linux 2, uh the ability to attach multiple virtual hard drives for storage, so elastic block store. Um and so, the Amazon machine image is a predefined configuration for a VM, so just remember that. And so, EC2 is also considered the backbone of AWS because the majority of AWS services are using EC2 as the underlying servers, whether it's S3, RDS, DynamoDB, or Lambdas. That is what it's using, so um when I say also, it's just because when we talk about the AWS network, that is the backbone for uh global infrastructure uh and the networking at large, and so EC2 is for the services, okay?

[00:01:39]Hey, this is Andrew Brown from Exam Pro.

[00:01:41]So, we just looked at what EC2 is. Well, let's look at more of the broader services for computing, and these are the more uh common ones that you'll come across. There's definitely more than just what we're going to see on this single slide here. So, break this down with virtual machines, containers, and then serverless. Well, for virtual machines, remember that's an emulation of a physical computer using software and EC2 is the main one. Uh but for our VM category, we have Amazon Lightsail.

[00:02:05]This is a managed virtual server service. It is the friendly version of EC2 virtual machine. So, when you need to launch a Linux or Windows server, but you don't have much AWS knowledge, you can launch a WordPress here and uh you can hook up your domain and stuff like that. Um so, this is a very good option for beginners. We have containers, so virtualizing an operating system or OS to run multiple workloads on a single OS instance. So, containers are generally used in microservice architecture when you divide your application into smaller applications that talk to each other.

[00:02:36]So, here we would have ECS, Elastic Container Service. This is a container orchestration service that supports Docker containers. Launches a cluster of servers on EC2 instances with Docker installed. So, when you need Docker as a service or you need to run containers.

[00:02:51]We have Elastic Container Registry, ECR.

[00:02:53]This is a repository of container images. So, in order to launch a container, you need an image. An image just means a saved copy. A repository just means a storage that has version control. We have ECS Fargate or just Fargate now. People are kind of forgetting that it's it runs on ECS these days. That's why I have it in there. It is a serverless orchestration container service. It is the same as ECS except you pay on demand per running containers. So, with ECS, you have to keep a EC2 server running even if you have no containers running. So, AWS manages the underlying server, so you don't have to scale or upgrade the EC2 server. So, there's the advantage over ECS, okay? Then we have Elastic Kubernetes Service, EKS. This is a fully managed Kubernetes service. Kubernete- or uh so, Kubernetes, uh commonly abbreviated to K8, is an open-source orchestration software that was created by Google. It's generally uh the standard for managing do So, when you need to run Kubernetes as a service, then we have serverless category. So, when the underlying servers are managed by AWS, you don't worry or configure servers. AWS Lambda is a serverless function service. You can run code without provisioning or managing servers. You upload small pieces of code, choose how much how much memory, how how long you want the function to run is allowed to run before timing out, and you are charged based on the run time of the serverless function rounded to the nearest 100 milliseconds.

[00:04:17]So, there you go.

[00:04:23]Hey, this is Andrew Brown from Exam Pro, and we are comparing virtual machines to containers. So, I know we covered this prior, but I just want to do it one more time just to make sure that we fundamentally understand the difference before we jump into containers. So, the idea is that if you were to request an EC2 instance, it has a host operating system that we don't really know much about, but we don't really need to know.

[00:04:44]And then the idea is you have a hypervisor, which allows you to deploy virtual machines.

[00:04:49]And so, when you launch an EC2 instance, you're actually launching a VM on top of a hypervisor on a server with on within the AWS data centers servers there. And you're going to choose an operating system, so like Ubuntu, and it might come with some pre-installed packages, or you're going to install your own libraries, packages, and binaries. And then you're going to decide what kind of workloads you want to run on there. So, it could be Django, MongoDB, so your database, and some kind of queuing system like RabbitMQ. The difficulties with virtual machines is you're always going to end up with some unused space because you're going to want to have some head room to make sure that you know, if you know, Django needs more memory or or MongoDB needs more storage that you have that room that you can grow into.

[00:05:31]But, the idea is that you're always paying for that even when you're not utilizing it. And so, you know, that can be not as cost-effective as you'd like it to be. So, when we're looking at doing this again, and we are using containers, Um instead of the hypervisor, we have container virtualization. A very common one would be called Docker Daemon for Docker, of course. And so now you're launching containers, and so maybe you have Alpine, and this is for your web app, and then you install exactly the libraries, packages, and binaries you need for that. And then for uh MongoDB, you want to have a different OS, different packages, and same thing with RabbitMQ. Maybe you want to run it on FreeBSD. And the idea is that uh you know, you're not going to have this waste because it it's kind of changed in the sense that these containers are flexible, so they can expand or decrease based on the the use case of what they need. Uh and you know, if you use particular services like AWS Fargate, you know, you're paying like for running the containers, not necessarily uh for uh over provisioning, okay? So, VMs do not make best use of space, apps are not isolated, which could cause uh config conflicts, security problems, or resource hogging.

[00:06:41]Containers allow you to run multiple apps which are virtually isolated from each other. Launch new containers, configure OS uh dependencies per container, okay?

[00:06:53]Hey, this is Andrew Brown from Exam Pro, and we are taking a look at the concept of microservices. And to understand microservices, we first need to understand monoliths or monolithic architecture. And the idea here is that we have one app which is responsible for everything, and the functionality is tightly coupled. So, I'll get get my pen tool out here, and just to highlight, notice that there is a server, and everything is running on a single server, whether it's load caching, the database, um maybe the marketing website, the front-end JavaScript framework, the back-end with its API, uh the uh ORM connected to background tasks, things like that. And that's the idea of a monolith, and that's what um a lot of people are used to doing. But the idea with microservice architecture is that you have multiple apps which are responsible for one uh one thing, and the functionality is isolate and stateless. And so just by uh leveraging um various cloud services or bolting it onto your service, uh you know, you are technically using microservice architecture. So, maybe your web app is all hosted um in containers, so you have your APIs, your your ORM, your reports. Maybe you've abstracted out some particular functions into lambda functions. You have your um marketing website hosted on S3. You have your front-end JavaScript hosted on S3.

[00:08:08]You're now using a lot of elastic load balancer, uh elastic cache, RDS, SQS. And that's the idea between monoliths and microservices, okay?

[00:08:23]Well, let's take a look here at Kubernetes, which is an open-source container orchestration system for automating deployment, scaling, and management of containers. It was originally created by Google and now maintained by the Cloud Native Computing Foundation, so the CNCF.

[00:08:37]Kubernetes is commonly called K8. The eight represents the remaining letters for Kubernetes, which is odd because everyone calls it Kubernetes with the S on there, but that's just what it is.

[00:08:47]The advantage of Kubernetes over Docker is the ability to run containers distributed across multiple VMs. A unique component of Kubernetes are pods.

[00:08:56]A pod is a group of one or more containers with with shared storage, network resources, and other shared settings.

[00:09:02]So, here is kind of an example where you have your Kubernetes master. It has a scheduler controller ETCD you might be using.

[00:09:09]It uses an API server to run nodes.

[00:09:12]Within the nodes, we have pods, and within the pods, we have containers.

[00:09:16]Kubernetes is ideally for microservice architectures where a company has tens to hundreds of services they need to manage. I need to really emphasize that.

[00:09:25]Tens to hundreds of services, all right?

[00:09:28]So, you know, Kubernetes is great, but just understand that it is really designed uh to be used for massive amounts of microservices. If you don't have that need, you might want to look at something just easier to use, okay?

[00:09:45]All right, let's take a look here at Docker, which is a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers.

[00:09:54]So, Docker was the earliest popularized open-source container platform, meaning there's lots of tutorials. There's a lot of services that integrate with Docker or make it really easy to use. And so, when people think of containers, they generally think of Docker. There's of course a lot more options out there than Docker to run containers, but this is what people think of. And so, we said it's a suite of tools. So, the idea is you have this Docker CLI. So, these are CLI commands to download, upload, build, run, and debug containers. A Dockerfile, a configuration file on how to provision a container. Docker Compose, which is a tool and configuration file when working with multiple containers.

[00:10:30]Docker Swarm, an orchestration tool for managing deployed multi-container architectures. Docker Hub, a public online repository for containers published by the community for download.

[00:10:40]And one really interesting thing that came out of Docker was the Open Container Initiative OCI, which is an open governance structure for creating open industry standards around container formats and runtimes. So, Docker established the OCI, and it is now maintained by the Linux Foundation. And so, the idea is that you can write a Dockerfile or or do things very similarly and use different types of technologies that use containers. As long as they're OCI compatible, you can use them.

[00:11:09]So, Docker has been losing favor with developers due to their handling of introducing a paid open-source model, and alternatives like Podman are growing, and that's why we're going to talk about Podman next, okay?

[00:11:24]Let's take a look here at the container services offered on AWS.

[00:11:28]So, we have primary services that actually run containers, provisioning and deployment on, you know, tooling around provisioning deployment and supporting services. So, the first here is Elastic Container Service ECS.

[00:11:39]Um and the advantage of this service is that it has no cold starts, but it is a self-managed EC2. So, that means that uh you're going to be always paying for the resource as it is running. All right?

[00:11:49]Then you have AWS Fargate. So, this is more robust than uh using AWS Lambda. It can scale to zero costs um and it's uh being managed by AWS managed EC2.

[00:12:00]However, it does have cold start. So, you know, if you need containers launching really fast, you might be wanting to use ECS. Then you have Elastic Kubernetes Service EKS. This is uh open source. It runs Kubernetes. Um and this is really useful if you want to avoid vendor lock-in.

[00:12:17]Um which is not really a problem, but uh that or is just you want to run Kubernetes. Then you have AWS Lambda.

[00:12:23]So, you only think about the code. Uh it's designed for short-running tasks.

[00:12:27]Uh if you need something that runs longer, you'd want to use uh that is serverless, you'd use AWS Fargate, which is serverless containers. You can deploy custom containers. So, prior AWS Lambda just had um pre-built runtimes, which were containers. But now you can create any kind of container and uh use that uh on AWS Lambda.

[00:12:45]For provisioning deployment, you can use Elastic Beanstalk. So, um it can uh deploy Elastic Container Service for you. Um which is very useful. That'll Now there's App Runner, which kind of overlaps on what Elastic Beanstalk does, but it specializes It specializes for containers. Um and I believe that it can Actually, I don't know what it uses underneath because it is a managed service. So, Elastic Beanstalk is um open. You can see what is running underneath. In App Runner, I don't believe you can see what is running underneath. It's just taken care of by AWS. Then there's AWS uh Copilot CLI.

[00:13:18]So, this allows you to build, release, operate production-ready containerized applications on App Runner, ECS, and AWS Fargate. For supporting services, you have Elastic Container Registry. This is a repo for your containers. Not necessarily just Docker containers, but containers in general, probably OCI compliant containers. X-Ray so analyze and debug between uh microservices. So, you know, it's distributed tracing. Then you have Step Functions to stitch together Lambdas and ECS tasks to uh create um um uh a state machine. And the only thing I don't have on here would be, you know, being able to launch an EC2 instance from the marketplace that has um a uh a container runtime installed like Docker. Uh I just don't feel that that's uh very relevant for the exam, but it is another option for containers. Not something that people do very often, but there you go.

[00:14:10]So, let's take a look at serverless services on AWS. And this is not including all of them because we're looking at the most purely serverless services. Uh if we tried to include all the serverless services, it would just be too long of a list. Uh but let's take a look here. So, um before we do, let's just redefine what is serverless. So, when the underlying servers, infrastructure, and operating system is taken care by the CSP, serverless is generally by default highly available, scalable, cost-effective. You pay for what you use. The first one is DynamoDB, which is a serverless NoSQL key-value and document database. It's designed to scale to billions of records with guaranteed consistent data returned in at least a second. You do not have to worry about managing shards. You have Simple Storage Service S3, which is a serverless object storage service. You can upload very large and unlimited amounts of files. You can pay for what you store. You don't worry about the underlying file system or upgrading the disk size. We have ECS Fargate, which is a serverless orchestration container service. It's the same as ECS except you pay on demand per running container.

[00:15:11]With ECS, you have to keep a EC2 server running even if you have no containers running where AWS manages the underlying server, so you don't have to scale or upgrade the EC2 server.

[00:15:22]We have AWS Lambda, which is a serverless function service. You can run code without provisioning or managing servers. You upload a small piece of code, choose how much memory you want, how long you want the function is allowed to run before timing out. You're charged based on the run time of the service function rounded to the nearest 100 milliseconds. We have step functions. This is the state machine service.

[00:15:44]It coordinates multiple services into serverless workflows, easily share data among Lambdas.

[00:15:51]Have a group of Lambdas wait for each other, create logical steps, also work with Fargate tasks. We have Aurora Serverless. This is a serverless on-demand version of Aurora. So, when you want most of the benefits of Aurora, but trade You have to trade off those cold starts or you don't have lots of traffic or demand. So, things serverless services that we could have put in here as well is like API Gateway, AppSync, AWS Amplify, um and those are like the the first two are application integrations. You could say SQS, SNS. Those are all serverless services, but you know, again, we'd be here all day if I I listed them all, all right?

[00:16:31]All right, let's take a look at what is serverless. And we did look at it from a server perspective earlier in the course, but let's just try to abstractly define it and talk about the architecture. So, serverless architecture generally describes fully managed cloud services, and the classification of a cloud service being serverless is not a boolean answer. It's It's not a yes or no, but an answer on a scale where a cloud service has a degree of serverless. And I do have to point out that this definition might not be accepted by um everybody because serverless is one of those uh terms where um we've had a bunch of different cloud service providers define it differently. And then we have thought leaders that have a particular concept of what it is. So, you know, I just do my best to try to make this practical here for you, but a serverless service could have all or most of the following characteristics. And so, it could be highly elastic and scalable, highly available, highly durable, secure by default. It abstracts away the underlying infrastructure and are built based on the execution of your business tasks. A lot of times that that cost is not is not always represented as something that is like, I'm paying X for compute.

[00:17:44]It could be abstracted out into some kind of credit that doesn't necessarily map to something physical. Then we have serverless can scale to zero, meaning when it's not in use, the serverless resources cost nothing.

[00:17:57]And these two last topics basically pull into pay for value. So, you don't pay for idle servers. You're paying for the value that your service provides.

[00:18:08]And my friend Daniel, who runs the serverless Toronto group, he likes to describe serverless as being similar to like energy efficient rating. So, an analogy of serverless could be similar to energy rating labels, which allows consumers to compare the energy efficiency of a product. So, some services are more serverless than others. And again, you know, some people might not agree with that, where there is a definitive yes or no answer, but I think that's the best way to look at it, okay?

[00:18:38]Hey, this is Andrew Brown from Exam Pro, and we're taking a look at higher performance computing services on AWS.

[00:18:43]So, before we do, we got to talk about the Nitro system. So, this is a combination of dedicated hardware and lightweight hypervisor enabling faster innovation and enhanced security. All new EC2 instance types use the Nitro system. And the Nitro system is designed by AWS, okay? So, this is made up of a few things. We have Nitro cards.

[00:19:02]These are specialized cards for VPCs, EBS, instance storage, and controller cards. You have Nitro security chips.

[00:19:09]These are integrated into the motherboard, protects hardware resources. And we have the Nitro hypervisor. This is the lightweight hyper uh visor memory and CPU allocation bare metal like performance. There's also uh Nitro Enclaves, but you know, that's a bit out of scope here, but that's has to do with like EC2 isolation, okay?

[00:19:25]Uh then we have bare metal instances, so you can launch EC2 instances that have no hypervisor, so you can run workloads directly on the hardware for maximum performance and control. We have the M5, the R5 um EC2 instances that can run bare metal. There's other ones I believe I've seen as well, but um you know, it what if you are running bare metal, you can just go investigate at the time of, okay? We have Bottlerocket. This is a Linux-based open-source operating system that is purpose-built by AWS for running containers on VMs or bare metal hosts.

[00:19:55]Then uh let's just define what HPC is.

[00:19:57]So, it's a cluster of a hundred of thousands of servers with fast connections between each of them with the purpose of boosting computing capacity. So, when you need a supercomputer to perform computational problems too large to run on a standard computer or computers or would take too long, this is where, you know, HPC comes into play. One solution here is AWS Parallel Cluster, which is uh an AWS supported open-source cluster management tool that makes it easy for you to deploy and manage high-performance computing HPC clusters on AWS. So, hopefully that gives you uh an idea of this stuff, okay?

[00:20:36]Hey, this is Andrew Brown from Exam Pro, and we're taking a look at edge and hybrid computing services. So, what is edge computing? When you push your computing workloads outside of your network to run close to the destination location, uh so, an example would be pushing computing to run on phones, IoT devices, external servers not within your cloud network. What is hybrid computing? When you're able to run workloads on both your on-premise data center and the AWS uh VPC, okay? So, we have a few services here starting with AWS Outposts. This is a physical rack of servers that you can put into your data center. AWS Outposts allows you to use AWS API and services such as EC2 right in your data center.

[00:21:17]Then we have AWS Wavelength. This allows you to build and launch your applications in a telecom data center.

[00:21:22]By doing this, your applications will have ultra-low latency since they will be pushed over the 5G network and be closest as possible to the end user.

[00:21:31]Um so, they've partnered with things like Verizon, Vodafone, Business, and a few others, but those are the two noticeable ones, okay? We have VMware Cloud on AWS. So, this allows you to manage on-premise virtual machines using VMware within EC2 instances. The data center must be using VMware for virtualization for this to work, okay? Then we have AWS Local Zones, which are edge data centers located outside of the AWS region, so you can use AWS closer to the edge destination when you need faster computing, storage, databases in populated areas that are outside of AWS region, you could do this. There are some other edge offerings on AWS that aren't listed here, like SageMaker has what's called like Neo SageMaker. On the list, you do edge computing with ML, but I mean, this is good enough, okay?

[00:22:22]Hey, this is Andrew Brown from ExamPro, and we are taking a look at Local Zones, which are data centers located very close to densely populated areas to provide single-digit millisecond low-latency performance. So, think like 7 milliseconds for that area. So, here is a map of Local Zones that exist and ones that are coming out. I believe the orange ones are probably ones that are on their way. And so, to use a Local Zone, you do need to opt in, so you got to go talk to AWS, probably open a support ticket to get access to it. The first one to ever be launched was the LA one, and so, um you know, when you want to see it, it looks just like a availability zone. It's going to show up under whatever region that is, cuz these are always tied to existing regions. So, the LA one is tied to US West uh region and the AZ would look like US West 2 {hyphen} LAX {hyphen} 1A, okay? So, only specific AWS services have been made available. So, there's uh particular EC2 types, EBS, Amazon FSx, application load balancer, Amazon VPC. They probably have extended it to more services. Do you need to know that for the exam? No, but you know, the point is is that there's a limited subset of things that are available. The purpose of local zone is to support highly demanding applications sensitive to latency. So, media and entertainment, electronic design and automation, ad tech, machine learning.

[00:23:40]So, kind of makes sense. Like you look at LA, they're in the media entertainment and so they're dealing with lots of media content. So, it has to be really low for them, okay?

[00:23:52]Hey, this is Andrew Brown from Exam Pro and we are taking a look at AWS Wavelength Zones. And these allow for edge computing on the 5G networks and applications will have ultra-low latency being as close as possible to the users.

[00:24:05]So, AWS has partnered with various telecom companies to utilize their 5G networks. So, we're looking at Verizon, Vodafone, KDDI, SK Telecom. And so, the idea here is that you will create a subnet tied to a wavelength zone and then just think of it as like an availability zone, but it's a wavelength zone and then you can launch your VMs to the edge of the targeted 5G network. So, that's the network you're using AWS to uh deploy an EC2 instance and then when users connect to you know, those radio tower those um the cell towers, uh they're going to be routed to um you know, nearby hardware that is running those virtual machines, okay? And that's all it is. It's just it's just EC2 instances.

[00:24:47]Um but you know, the advantage here is that it's like super super low latency, okay?

[00:24:58]Hey, this is Andrew Brown and we are looking at AWS Outposts and this is a fully managed service that offers the same AWS infrastructure, services, APIs, tools to virtually any data center, co-location space, or on-premise facility for a truly consistent hybrid experience. And just to kind of summarize it, it's a rack of servers running AWS stuff on your physical location, okay? So, before we jump into the service or technology itself, uh let's talk about what is a rack server or just a rack. So, it's a frame designed to hold and organize IT equipment. So, here's an example of a 42U rack.

[00:25:33]Uh and there's the a concept of rack heights. So, the U stands for rack units or U spaces uh with it equal to 1.75 in and the industry standard rack is a 48U.

[00:25:46]Um so, that is a 7 ft rack. So, uh a full uh size rack cage is commonly the 42 high. Okay? And uh in it, you might have equipment that is of different sizes, so they could be 1U, 2U, 3U, or 4U high. So, here's an example of, you know, of an interior of a rack and notice that like 1U, 2U, 4U, they're all a little bit shaped differently, uh but they give you kind of an idea of, um you know, what those are.

[00:26:14]So, AWS Outposts comes in three form factors, the 42U, the 1U, and the 2U.

[00:26:20]So, the uh the first one here, the 42U, this is basically a full rack of servers provided by AWS. So, you're not just getting the frame, it actually comes with, you know, servers.

[00:26:30]Uh and so, AWS delivers it to your preferred physical site fully assembled and ready to be rolled into the final position. It is installed by AWS and the rack needs to be simply plugged in to the power and network. And there's a lot of details about um the specs on this on the AWS website, so, you know, I'm not going to go through them all here. Um then there are services that you can just place into your existing racks. So, we have the 1U. So, this is suitable for 19-in wide, 24-in deep cabinets. It's using AWS Graviton 2 CPUs and you can have up to 64 virtual CPUs. We have 128 GB, 4 TB of local NVMe storage.

[00:27:10]And then you have the U, or sorry, the 2 U.

[00:27:14]So, suitable for 19-in wide, 36-in deep Intel processors, up to 128 virtual CPUs, 256 GB of memory, 8 TB of local NVMe storage. So, there you go.

[00:27:31]Hey, this is Andrew Brown from Exam Pro and we are taking a look at EC2, also known as Elastic Compute Cloud. And so, this is a highly configurable virtual server, or it's also known as a virtual machine. And that's what we're going to generally refer to it.

[00:27:44]EC2 is resizable compute capacity. It takes minutes to launch new instances and anything and everything on AWS uses EC2 instances underneath. That's why we generally call it the backbone to all the AWS services. And you're going to just have to choose a few options here.

[00:27:58]So, the first thing you'll need to do is choose your OS via your Amazon Machine Image. So, that's where you get Red Hat, Ubuntu, Windows, Amazon Linux, SUSE. It might also come with pre-installed libraries and things like that. Then you can choose your instance type. That's going to determine things like your VCPUs, your memory. So, here you can see how many there are and you'll have like a monthly cost.

[00:28:20]And that's the name of the instance type. Then you have to add storage. So, very commonly you're attaching elastic block storage or elastic files system or service.

[00:28:30]And so, you know, if you do choose your EBS, you are going to have to determine what type it is. So, whether it's a solid state drive, a hard disk drive, a virtual magnetic tape, or even attaching multiple volumes, not just a single one.

[00:28:44]And the last thing is configuring your instance. So, this is configuring the security groups, the key pairs, user data, IAM roles, placement groups, all sorts of things. So, we will experience in that because we will show you how to launch an EC2 instance, and it'll make a lot of sense if it does not make sense right now, okay?

[00:29:04]All right, let's take a look here at EC2 instance families. So, what are instance families? Well, instance families are different combinations of CPU, memory, storage, and networking capacity. And instance families allow you to choose the appropriate combination of capacity to meet your applications unique requirements. Different instance families are different because of the varying hardware used to give them their unique properties. And we do talk about this thing about capacity reservation, where AWS can actually run out of a particular type of instance family because they just don't have enough hardware in that data center, and so you have to reserve it.

[00:29:36]But let's go through the different types of instance families. The first is general purpose, and these are the names of the different families. A very popular ones is the T2, um, the T2. And one that's really interesting is the Mac, which actually allows you to run um, a a Mac server.

[00:29:53]So, these are great balance of compute, memory, and network resources. So, you're going to be using these most of the time. Use cases here would be web servers, code repositories, things like that. Then you have compute optimized, so um, they all start with C. No surprise there. They're ideal for compute bound applications that benefit from high performance processor. Their edge cases here are scientific modeling, dedicated gaming servers, ad server engines, things like that. Then you have memory optimized.

[00:30:19]Um, and so there's a variety here. These are fast performance for workloads that process large data sets in memory. Um, they're great for in-memory caches, in-memory databases, real-time big data analytics. Then you have accelerated optimized, so this is your P2, P3, P4, things like that. These are hardware accelerators or co-processors. These are great for machine learning, computational finance, seismic analysis, speech recognition. If you're doing uh, uh ML on AWS, you're you'll start coming across these types. AWS technically has a separate page on Sagemaker ML machines, but they're all pulling from these instance families, okay? Then we have storage optimized, so I3, I3en, things like that. Uh these are highly high sequential read and write access to very large data sets on local storage.

[00:31:04]The use cases here would be NoSQL, in-memory or transactional databases, data warehousing. For the certified cloud practitioner, you just need to generally know these five categories, not the names of the instance families.

[00:31:15]If you're doing um associates or above, you definitely want to know these things in a bit more detail. And I want to say that commonly instance families are called instance types, but an instance type is a combination of size and family. But even AWS's documentation doesn't make this family distinction clear, but I know this because, you know, in Azure they make that very clear and and TCP, and so I'm bringing that language over here to just kind of normalize it for you, okay?

[00:31:44]Let's take a look at what EC2 instance types are. So, an instance type is a particular instance size and instance family, and a common pattern for instance sizes you'll see is things like nano, micro, small, medium, large, extra large, 2x large, 4x large, 8x large. And you know, generally they're to the power of twos, but sometimes it'll be like 12, 14, 16, where it's even. Uh and so, when you go to launch EC2 instance, uh you're going to have to choose that instance type. And so, here you can see you know, there here's our T2 micro, and then we have um the small, the medium, the large, the extra large.

[00:32:22]Okay, but there are exceptions to this pattern for sizes. So, you know, there is one particular one called uh dot metal, and so that's going to indicate that this is a bare metal machine. And then sometimes you get these oddball ones like uh 9x large. So, you know, the rule of power of two or even numbers is not always the case.

[00:32:39]But generally it'll be pretty even for, you know, the start here, okay? Just talking about instance sizes, so the EC2 instance sizes generally double in price and attribute. So, just bringing up these numbers a little bit closer, starting at the small here, you're going to notice 1 2 doesn't maybe double there, but 4 and here we see 12 24 almost doubles there almost doubles there, but I want to I'll show you that the price is generally almost double.

[00:33:05]So, 16 33 67 135 and so a lot of times like you always have the option to say, "Okay, do I want to go to the next instance size up or have an additional instance of the same size?" And sometimes it's a better approach to get an additional instance because then you can distribute it across another AZ, but then you also meet additional capacity. So, there you go.

[00:33:31]Okay, so now I want to show you Elastic IP commonly abbreviated to EIP and so all that is is just a static IP an IP that does not change because this EC2 instance here, notice that it's 54 163 4104.

[00:33:46]And what would happen if we were to stop this instance, not reboot it, but stop it because for whatever reason we had to or or for whatever reason.

[00:33:55]And if we were to stop this instance and we were to restart it Okay?

[00:34:02]And we have to wait for it to stop. But that IP address is going to change, okay?

[00:34:09]So, 54 163 4104, hopefully we can observe that.

[00:34:13]I'm just going to write that down so we do not forget.

[00:34:17]So, I can prove to you that it does change.

[00:34:22]And now that it it's still stopping here.

[00:34:26]So, as that stopping, we're just going to go ahead and get our Elastic IP and I will prove that as we go here. So, I'm going to go over to here.

[00:34:33]And so what I want to do is reserve or allocate an elastic IP address. And so I'm going to say US East 1.

[00:34:39]And it's going to say from the Amazon pool of IPv4 addresses. So AWS has a bunch of IP addresses they're holding on to. And so you can just allocate one.

[00:34:49]And once you've allocated, that's your IP address. So, coming back to here.

[00:34:54]Okay, this is stopped.

[00:34:56]Notice there's no public IP address.

[00:34:58]We're going to start it again.

[00:35:03]Okay, and then we'll just check box it on and we just have to wait a little while to see what the IP address is going to be. I'm going to tell you it's going to be something else.

[00:35:13]So, if I go back here, this is 54 235 12 110. And our original one was 54 163 4104.

[00:35:21]So, the reason why it's important to have the same address is that if you have a load balancer, well, not load balancer, but if you have a domain pointing to your your server and you reboot, then the route you have a dang a dangling a path or route where Route 53 was going to be pointing to nothing. And so AWS does have things to mitigate that like aliases and things like that. But in general, you know, there's cases where you just have to have a static IP address. And so we had allocated one over here. And if we want to assign it, we're going to associate that elastic IP address. We're going to drop it down, choose a CC2 instance.

[00:35:59]I suppose the private IP as well. And then we're going to go ahead and hit allocate or associate.

[00:36:06]And once it's associated, it should now have 34 199 121 116. So, we go over here.

[00:36:15]And we're going to take a look here. And that's its IP address. We can pull it up.

[00:36:20]Okay.

[00:36:21]And that's that. So, yeah, that's elastic IP.

[00:36:28]Okay, so now that we um have our Elastic IP, we have our EC2 instance running.

[00:36:32]Let's say um you know, we lose the server, we terminate it. So, we would lose all of our configuration. So, if we wanted to bake this AMI to save it for later, what we'd have to do is go and create an image. So, to do that, we go to the top here and we go to Images and Templates and we can create an image or we can create a template, which is a lot better. But, for the time being, we're just going to go ahead and create an image. And when you create an image, you're basically creating an AMI. And so, here I'm just going to say uh my EC2 and I'm going to go 000 to just kind of like number it. So, that's a very common numbering, just do three zeros and then increment by one.

[00:37:04]And so, here I can just say my Apache server.

[00:37:08]And so, it's going to save some settings like the fact that there is a a volume.

[00:37:12]You could uh save some tags there. And so, I might go ahead and add a tag and just say name and we'll just say my EC2 server or so that it remembers that.

[00:37:22]Okay?

[00:37:23]And then what we'll do is go ahead and create our image.

[00:37:27]And so, this can take a little bit of time. If we go over to uh images here, it's going to be spinning for a while and uh we'll just wait until it's done, okay? All right, so after waiting a little while here, our AMI is ready. So, we're just waiting for it to go available. If you do not see it, just make sure you hit the refresh um because sometimes AWS will just spin forever um and so, that's just something you'll have to do.

[00:37:50]So, you know, hopefully that makes sense. What we'll do is go make our way back over to instances here and we can launch one this way. Well, actually, we can do it over from um the AMI page. So, what I'm going to do is just terminate this instance. We're all done with it.

[00:38:05]Okay? And we'll hit terminate. It's totally fine. And it had a message about Elastic IPs about releasing them. So, when it does that, the Elastic IP is still over here. So, it did not release it. So, what we're going to do is go ahead and disassociate the Elastic IP.

[00:38:21]Okay? And then we're also going to release the IP address because if we don't, we're going to have this IP address that's sticking around that we're not using. It'll basically going to charge us a dollar a month over a month. So, just be aware of those because that's just kind of like a hidden cost there. But, uh what we're going to do is go over to AMI and we're going to select it here. We're going to go to actions and we're going to go ahead and launch.

[00:38:41]And what it's going to do is make us fill all this other stuff again. So, if you had made a launch template, uh we wouldn't have to fill it all this stuff.

[00:38:48]It'd be part of it, but that's what I'm trying to show you with this AMI stuff.

[00:38:51]So, um instead of filling out all this, what I'm going to do is now go create a launch template just to kind of show you that that would be a much easier way to work.

[00:39:02]So, we go over to EC2 instances.

[00:39:04]And then on the left-hand side, we're looking for a launch template. Launch uh launch configurations is the old thing.

[00:39:10]Um launch templates. Here we go.

[00:39:13]So, what we'll do is create ourselves a launch template. We'll just say my Apache server.

[00:39:19]And then down below, we need to choose our AMI. So, we're going to go here and we need to type it in. So, what did we call it? My EC2.

[00:39:31]I really don't like this uh search here.

[00:39:32]It's very slow and frustrating, but once we find it, whoops. That's why I don't like it because a lot of times you'll be loading and you'll end up clicking the wrong thing.

[00:39:41]Okay, so Uh I don't like this. Okay. We'll type in my Give it a second.

[00:39:53]There it is. Just wait because it will keep loading. And then once it's loaded, hit enter.

[00:39:59]And so, it has that instance selected and then from there, uh don't include it in the launch template. So, here we could be explicit. I would say I want this to be a T2 T2 micro, but we could exclude it if we wanted to. We could specify the key pair here. Um not that we really want to use key pairs, but we'll say my EC2 instance. Then down down here for the networking, we can specify that security group we created.

[00:40:21]So, we created one here called my EC2 SG.

[00:40:24]Um storage is fine. It's going to be encrypted. Network interface is fine.

[00:40:29]Advanced details, what I want to do is set the IAM instance profile. That's really important because we don't want to have to figure out that role every single time.

[00:40:37]So, put that there.

[00:40:39]And that should be everything. And we could put user data in there, but it's already baked into our AMI, so we don't have to worry about anything. So, what I'm going to do here is go ahead and create this launch template.

[00:40:50]And then we're going to view this launch template. And so, now what we can do is then use it to launch an instance. Okay?

[00:40:58]And so, we're going to look here and it's very similar to the EC2, but except it's vertical. So, we're going to have one instance, it's going to use that AMI, that instance type. So, you can see how you can override them, which is nice. We're going to check the advanced details and make sure that IAM profile is set. And we'll go ahead and launch this from a template.

[00:41:16]So, from there we can go ahead and click the instance value there.

[00:41:20]And just be aware that when you do click through links like that, you'll end up with a search. So, I always just check box that off so I can see what I'm doing.

[00:41:26]And so, we're just waiting for this instance to show up. And the only thing I noticed is it didn't set our darn tags. So, I wanted the name in there and I think it's because we set it in the AMI, but it didn't carry over to the launch template. So, I'd have to go back to the launch template and update it probably.

[00:41:40]So, if I go into here into the launch template.

[00:41:43]Um we can probably modify create a new version.

[00:41:49]And then add tags there.

[00:41:51]So, we'd say name.

[00:41:54]Uh my uh Apache server.

[00:41:58]I realize I'm changing it uh between them. And so, that should allow us to have a version two. So, we'll create that.

[00:42:04]And but anyway, that will be for the next time we launch it, okay?

[00:42:09]And so, this instance is running. I'm going to go grab the IP address.

[00:42:13]The server may or may not be ready.

[00:42:15]We'll take a look here.

[00:42:17]And so it's just spinning. If it's spinning, it's either the server is not ready or our port's not open. So it was just getting ready to work there. So it is working now.

[00:42:27]So that is our launch template. So now we know we don't have to worry about losing our stuff and if we need to make new versions, we can just bake new AMIs and increment them as and and attach them as new versions to the launch template, okay?

[00:42:45]All right. So what I want to show you in this follow along is to set up an auto scaling group for our EC2 instance. And the idea behind this is that we'll be able to always ensure that a single server is running or increase the capacity if the demand requires it. So in order to create an auto scaling group, we can go all the way down below to here.

[00:43:05]Um and so you know, I really don't like the auto scaling group form, but it's okay. We'll work our way through it. So the first thing is we'll have to create our or name our auto scaling group. So let's just say my ASG. And then we'll have to select a launch template, which is great cuz we already have one. And then we'll have to select a version. I'm going to select version two so that it applies that tag name.

[00:43:24]And we'll go to next.

[00:43:26]And so here it's going to need to select a VPC and then we need some subnets. So we're going to choose three just because to have high availability, you have to be running in at least three different availability zones. So that's why we have three different subnets.

[00:43:41]And then down below we have the instance type requirement. So T2 micro, launch template looks good to me. So we'll go ahead and hit next.

[00:43:51]And then from here we can choose to do a load balancer. And so I want to do the load balancer separate. So we won't do it as of yet, but very often if you're going to have an auto scaling group, you're going to usually have a load balancer. But we'll talk about that when we get to that point there. So we'll just go to the bottom here and hit next.

[00:44:07]And so, this is what's important. So, how many do you want to be always running? And so, we always want to have one and maybe the maximum capacity is two and you want the desired cast capacity to be to be around a particular number. So, if you had three and you set the desired is two, um there are things that could try to work to always make sure there's two, but we just want to have one for this example. We can set up a scaling policy.

[00:44:28]So, I do target tracking scaling policy.

[00:44:31]And so, here we could do it based on a bunch of different things. So, if the CPU utilization when it was 50% it would launch another server. So, that might be something we might want to set. So, I'll We're not going to uh try to trigger the scaling policy, but we might as well just apply cuz it's not too hard. And then you can also do a scaling uh scale in protection policy. So, if you want to make sure it does not um uh reduce the amount of servers, that's something you can do.

[00:44:54]We can add a notification to say, "Hey, there's a scaling policy happening here." which is fine. We don't have to worry about that. Um and then there's tags. So, add tags uh to help you search, filter, etc. Um so, I'm going to put a tag here. I'm going to just say name. I'm just wondering if this is going to attach to the EC2 instance or is this for the auto scaling group? You can optionally choose to add tags to instances by specifying tags in your launch template. So, we already did that, so I don't need to put a tag here.

[00:45:19]And so, we can review our um auto scaling group and go ahead and create that auto scaling group.

[00:45:26]Okay? And so, that auto scaling group expects there to be a single instance.

[00:45:31]So, what's going to do is it's going to start uh launching an instance. And so, what I'm going to do is just get rid of this old server because we don't need it anymore, this old one here. Okay?

[00:45:42]And you can already see okay, that the load balancer is launching this new one here. And remember we updated our version two to have that name, so that's how we know that it is. So, if we go back over to our auto scaling group, okay? It's now saying there is an instance. We don't have a status as of yet.

[00:46:04]And so, there are ways of doing uh status checks to uh for it to determine whether or not the server is working.

[00:46:10]Um because if the server is unhealthy, what it would do is it would actually kill it and then start up a new one, right? So, if I go down below, it's right now doing the EC2 health check. An EC2 health check just means that is the server working, right? Um is it running?

[00:46:23]Doesn't necessarily mean like, "Hey, can I load this web app?" Um but, you know, it's very simple. So, we'll give it a moment here to start up and just make sure that it's working.

[00:46:37]Okay. And I think it's ready. So, if I take that IP public IP address here and paste it in, there it is, okay?

[00:46:43]So, if we were to tell it to increase the capacity to three, then what it would do is it would launch three, and then it should probably launch it all evenly to those other It should evenly launch it to all those other uh availability zones, and then we'll have something that is highly available, okay?

[00:47:00]So, that's pretty much it for this, and then we'll move on to auto scaling groups.

[00:47:08]All right. So, we have our uh EC2 instance now managed by an auto scaling group. And the great thing is is that if we terminate this instance, this auto scaling group will launch another uh instance to meet our particular capacity. Um the only thing though is that if we were to have multiple EC2 instances running, like three of them, um how would you distribute traffic to them all, right? So, you know, you have an IP address coming in from the internet, uh but let's say you want to evenly distribute it, and that's where a load balancer comes into play.

[00:47:38]And even if you have a single server, you should always have a load balancer because it just makes it a lot easier for you to scale when you need to.

[00:47:45]And you it it acts as an intermediate layer where you can attach a web application firewall. You can attach an SSL certificate for free.

[00:47:52]So, there's a lot of reasons to have a load balancer. So, what we'll do is go down below on the left-hand side and we're going to make our way over to load balancers and we're going to create ourselves a new load balancer. So, I'm going to hit create load balancer here.

[00:48:06]And you're going to see we have a lot of options. Application load balancer, network load balancer, gateway load balancer, and then the classic load balancer. And so, we are uh running an application, so I'm going to create an application load balancer. And here I'm going to say my ALB um for an application load balancer.

[00:48:22]This is going to be internet-facing.

[00:48:23]It's going to be IPv4.

[00:48:25]Um we're going to let it launch in the default um subnet and we're going to choose the same the same uh uh AZs, right? So, that we get the same subnets as our that that are in our auto scaling group and that's really important, okay?

[00:48:41]And then here um you know, we need to have a security group and I just feel like selecting the same one here cuz that should work.

[00:48:49]No problem there.

[00:48:51]And we want to make sure that we can listen on port 80 and then it's going to be forwarding it to a a um a target group. And it looks like I might have a target group there from before. So, just to reduce that confusion, you won't have this problem. I'm just going to double-check if that's true.

[00:49:07]So, do I have a target group from there from before? Yes, I do. That came from I'm not sure. It might have been created by um Elastic Beanstalk and wasn't deleted.

[00:49:18]Okay. So, I'll go back over to here just so there's less confusion and we were selecting our target group. So, we're going to have to create a new target group.

[00:49:29]So, go over here.

[00:49:30]And here you can choose whether it's instance, IP, Lambda, application load balancer. So, you could point it specifically to an IP address and so, if it was a static IP address, that would make sense.

[00:49:40]Uh apparently, you can port uh point it directly to instances. I don't remember seeing that option before.

[00:49:47]I guess that makes sense. Yeah, no, sorry. That makes sense cuz I would go to uh VPCs, okay? Or sorry, uh ASGs, auto scaling groups. It's just that you are pointing them to auto scaling groups, you're not pointing them to instances. So, that's why that's confusing. So, I'm going to say my um target group. It'll be for port 80 here.

[00:50:04]Um protocol HTTP 1 is fine. We want to be in the same um VPC, so that's fine as well.

[00:50:11]And down below we have our health check.

[00:50:13]And so, the forward slash means that it's going to hit the index HTML page.

[00:50:16]And so, if it gets back um something healthy and that that something healthy is going to be um uh port 80, then it's going to be considered good. And then we can say the threshold of checks. I'm just going to reduce this so it's not so crazy. So, we'll say three, uh two, and then 10.

[00:50:34]Okay.

[00:50:35]And then it expects back a 200, which I think that's what we'll get back. So, we'll go ahead and hit next. And so, now we have our target group. And it should register instances. So, it's saying, "Hey, we detected this and this fits the requirements for this." So, this is now uh this EC2 instance is now in this target group, okay? So, we can go back over here and we can now drop down and choose Oops, hit the refresh button.

[00:51:01]And choose our target group.

[00:51:04]So, I'm not seeing it here. So, I'm going to go back over here.

[00:51:08]Oh, we didn't create it. Okay.

[00:51:11]And now we can go back, hit refresh, and there it is.

[00:51:16]And yeah, that looks all good. So, we'll go ahead and hit create load balancer.

[00:51:21]We can view the load balancers, and these create really fast. If we scroll on up, what we can do is now access our server through this DNS name, okay? So, we copy that, paste that on in there.

[00:51:34]Does it work?

[00:51:40]Not as of yet. So, if it's not working there, because we did say look at these instances, another way is to directly associate your auto scaling group with the load balancer.

[00:51:50]So, if I go into here and we hit uh edit.

[00:51:55]There is a way Aha, load balancer. So, we want to associate this way and we want to say this target group here.

[00:52:05]And also while we're here, we might as well set it to ELB, so it's going to use the ELB check. So, that makes it so the auto scaling group if it wants to uh restart a server, it's going to use the ELB's check, which is a lot more sophisticated.

[00:52:16]And then what we'll do is go hit update.

[00:52:19]Okay?

[00:52:22]And now, if we go back over to our load balancer, I'm just going to close some of these tabs, so it's less confusing.

[00:52:30]Uh load balancer here.

[00:52:34]I think we should be able to see through here whether it is seeing it.

[00:52:39]Let's go down below, listeners, monitoring, integrated services. No, it's going to be through the target group.

[00:52:48]Okay?

[00:52:52]I mean, it already had it there. So, maybe it's just that it hasn't finished the check. So, over here it has a health status check. Oh, now it's healthy, okay? So, if it's healthy in the target group and the load balancer is pointing to it, then it should technically work.

[00:53:05]So, we're going to go ahead and uh copy the DNS again here, make a new tab, paste it in.

[00:53:15]And there it is, okay? So, that's how you're going to access um all your all your instances that are within your auto scaling groups, you're going to always go through the DNS. And so, if you had a Route 53 uh domain, like you had your domain managed by AWS, you just point to the load balancer and that's how you hook it up. So, that's pretty much it. So, yeah, there you go.

[00:53:40]Hey, it's Andrew Brown from Exam Pro and we're looking at cost and capacity management computing services. So, before we talk about them, let's define what is cost management. So, this is how do we save money and we have capacity management. How do we meet the demand of traffic and usages through adding or upgrading servers? So, let's get to it.

[00:53:57]The first are the different types of EC2 pricing models. So, you got spot instances, reserved instances, saving plans. These are ways to save on computing by paying up in full or partially or by committing to a yearly contract or multi-year contract uh or by being flexible about the availability interruption to computing services. We have AWS Batch. So, this plans, schedules, and executes your batch compute workloads across the full range of AWS computing services, which can utilize spot instances to save money. We have AWS Compute Optimizer. So, suggests how to reduce costs and improve performance by using machine learning to analyze uh you uh your previous usage history.

[00:54:38]We have EC2 Auto Scaling Groups. So, ASGs. These automatically add or remove EC2 servers to meet the current demand all of traffic. They will save you money and meet capacity since you only run the amount of servers you need. Then, we have ELB. So, Elastic Load Balancer. So, this distributes traffic to multiple instances. We can reroute traffic from unhealthy instances to healthy instances and can route traffic to EC2 instances running in different availability zones.

[00:55:06]And then, we have Elastic Beanstalk here, which is easy for deploying web applications without developers having to worry about setting up and understanding the underlying AWS services, similar to Heroku. It's a platform as a service. So, not all these are about cost. Some of them are about capacity management like ELB.

[00:55:23]Um but, yeah, there you go.

[00:55:35]>> To remember EC2 are virtual machines.

[00:55:36]So, we have on-demand, spot, uh reserved, dedicated, and AWS savings plans. So, what we'll do is look at these in summary here, and then we'll dive deep onto each of these different pricing models. So, for on-demand, you are paying the a low cost. And also, you have a lot of flexibility with this plan. Uh you are paying per hour, so this is a pay-as-you-go model. Uh hour or you can be paying uh down to the second, which we'll talk about uh the caveats there when we get to the on-demand section. This is suitable for workloads that are going to be short-term, spiky, unpredictable workloads uh that cannot be interrupted, and it's great for first-time applications. And the on-demand uh pricing model is great when you need the least amount of commitment. For spot pricing, you can see we can save up to 90%, which is the greatest savings about of all these models here. Uh the idea here is you're requesting spare computing capacity that AWS is not using, and that's where you're going to get that savings. You have flexible start and end times, uh but your workloads have to be able to handle interruptions because these servers can be stopped at any time to be giving to more priority customers. Uh and this is great for non-critical background jobs, very common for like scientific computing uh where jobs can be started and stopped at any given time. This has the greatest amount of savings. Then you have reserved or reserved instances.

[00:56:48]This allows you to save up to 75%. This is great for steady-state or predictable usage. You're committing uh with AWS uh for EC2 usage over a period of 1 or 3-year terms. You can resell on on uh unused reserved instances, so you are not totally stuck with this if you buy them. This is great for the best long-term savings. Then you have dedicated, so these are just dedicated servers, and technically not a pricing model, but more so that the fact that it can be utilized with pricing models. Um but the idea here is it can be used with on-demand, reserved, or even spot. This is great when you need to uh have a guarantee of isolated hardware for enterprise requirements, and this is going to be the most expensive. Uh so, yeah, there you go. And we'll dive deep here, okay?

[00:57:37]So, the on-demand pricing model is a pay-as-you-go model where you consume compute and then you pay later. So, when you launch an EC2 instance, by default, you are using that on-demand pricing.

[00:57:49]And on-demand has no upfront payment and no long-term commitment. You are charged by the second up to a minimum of 60 seconds, so technically a minute or the hour. So, let's just talk about the difference between those uh per second billing and those per hour billing. So, per second are for Linux, Windows, Windows with SQL Enterprise, Windows with SQL Standard, Windows with SQL Web instances that do not have a separate hourly charge. And then everything else is going to be um per hour. And so, you know, when I'm launching EC2 instances, I can't even tell when something's per second or per hour. You just have to know that it has a separate hourly charge. But generally, you know, if you're just launching things, it's going to probably be the per second billing.

[00:58:31]When you look up the hourly or the uh the pricing, it's always shown in the hourly rate. So, even if it is using uh per second billing, when you uh look up that pricing, it's always going to show it to you like that. But on your bill, you'll see it down to the second, okay?

[00:58:46]Up to the first 60 seconds. Uh and on-demand is great for workloads that are short-term, spiky, or unpredictable.

[00:58:53]Uh but when you have a new app development, this is where you want to experiment. And then when you're ready to uh start saving because you know exactly what that workload's going to be over the span of a year or three, that's where we're going to get into reserved instances, which we'll cover next.

[00:59:11]Hey, this is Andrew Brown from Exam Pro, and we are taking a look at reserved instances, also known as RI. And this is um a bit of a complex topic, but uh you know, if we do get through it, it's going to serve you well through uh multiple AWS certifications. So, let's give it a bit of attention here. So, RIs designed for applications that have a steady state, predictable usage, or required reserved capacity. So, the idea is that you are saying to AWS, I'm going to make a guaranteed commitment saying this is what I'm going to use and I'm going to get savings because AWS knows that you're going to be spending that money, okay? So, the idea here is that the reduced pricing is based on this kind of formula where we have term, class offering, the RI attributes, and payment options. Technically, the RI attributes don't exactly factor into it other than the fact that they an RI attribute could be like the instance type size, but I'm going to put that in the formula there just because it is an important component. So, let's take a look at each of these components of the formula to understand how we're going to save. So, the first is the term. The term The idea here is the longer the term, the greater the savings. So, you're committing to a 1-year or 3-year contract with AWS. Um and one thing you need to know is that these do not renew.

[01:00:21]So, at the end of the year, the idea is that you have to purchase again. And when they do expire, your instances are just going to flip back over to on demand with no interruptions to service.

[01:00:32]Then you have class offerings. And so, the idea here is the less flexible the offering, the greater the savings. So, the first is standard, and this is up to a 75% reduction in the price compared to on demand. And the idea here is you can modify some RI attributes, which we'll we'll talk about when we get to the um RI attributes section there. Then you have convertible, so you save up to 54% reduced pricing compared to on demand.

[01:00:55]And you can exchange RIs based on the RI attributes if the value is greater or equal in value. And there used to be a third class called schedule, but this no longer exists. So, if you do come across it, just know that AWS is not planning on offering this again for whatever reason. I'm not sure why.

[01:01:12]Then there are the payment options. So, the greater upfront, the greater the savings. So, here we have all upfront.

[01:01:18]So, full payment is made at the start of the term. Partial upfront, so a portion of the cost must be paid upfront and the remaining hours in the terms are billed at a discounted rate. And then there's no upfront, so you are billed at a discounted hourly rate for every hour within the term regardless of whether the reserved instance is being used. And this is really great, this last option here, because basically you're saying to AWS, you're saying like, "I'm just going to pay my bills usual, but I'm going to just tell you what it's going to be and I'm going to save money." So, if you know that you're going to be using a T2 medium for the next year, uh you can do that and you're just going to save money, okay? So, RIs can be shared between multiple accounts within an organization and unused RIs can be sold in the reserved instance marketplace, but we'll talk about the limitations around that when we get a bit deeper in here. Just to kind of show you what it would look like in AWS console and they updated it. I love this new UI here. The idea here is you're going to filter basically your requirements and that's going to show you RIs that are available and then you'll just choose the desired quantity. You can see the pricing stuff there. You're going to add it to cart.

[01:02:18]You're going to check out and that's how you're going to purchase it, okay?

[01:02:26]Hey, it's Andrew Brown from Exam Pro and we are taking a look at spot instances.

[01:02:29]So, AWS has unused compute capacity that they want to maximize the utility of their idle servers. All right, so the idea is just like when a hotel offers booking discounts to fill vacant suites or planes offer discounts to fill a vacant seats, all right? So, spot instances provide a discount of 90% compared to on-demand pricing. Spot instances can be terminated if the computing capacity is needed by other on-demand customers, but from what I hear, rarely, rarely does spot instances ever get terminated. Um it's designed for applications that have flexible start and end times or applications that are only feasible at very low compute cost. So, you see some options here like load balancing workloads, flexible workloads, big data workloads, things like that. Um there is another service called AWS Batch, which is for doing batch processing and this is very common what you use um spot with. And so, you know, if you find the spot interface too complicated, you're doing batch processing, you want to use this service instead. Um there are some termination conditions, so instances can be terminated by AWS at any time. If your instance is terminated by AWS, you don't get charged for a partial uh hour of usage. If you terminate an instance, you will be still charged for an hour uh that it ran. So, there you go.

[01:03:46]Hey, this is Andrew Brown from Exam Pro, and we are taking a look at AWS Savings Plans. And this is similar to Reserved Instances, but simplifies the purchasing process. So, it's going to look a lot like RI the start here, but uh I'll tell you how it's a bit different, okay? So, there are three types of saving plans.

[01:04:00]You have compute saving plan, EC2 Instance Saving Plans, and SageMaker Saving Plans. Uh and so, you just go ahead and choose that. You can choose two different terms, so 1 year, 3 year, so it'll be simple as that. And then you choose the following payment options, so you have all up front, partial payment, and no up front. And then you're going to choose that hourly commitment. You're not having to think about standard versus convertible, uh uh regional versus zonal, RI attributes. It's a lot simpler. Uh and let's just talk about the three different saving plans or types in a bit more detail. So, you have compute. So, compute saving plans provides the most flexibility and helps to reduce your cost by 66%. These plans automatically apply to EC2 instances usage, AWS Fargate, AWS Lambda service usage, regardless of the instance family, size, AZ, region, OS, or tenancy. Then you have EC2 instances, so this provides the lowest prices, offering saving up to 72% in exchange for commitment to usage of instance uh individual instance families in a region. So, automatically reduce uh your cost on the selected instance family in the region, regardless of AZ, size, OS, tenancy. Gives you the flexibility to change your usage between instances with a within a family in that region. And the last is SageMaker. So, helps you reduce SageMaker cost by up to 64% automatically apply to SageMaker usage regardless of instance family size, component AWS region. If you don't know what SageMaker is, that's AWS's ML service, and it uses EC2 instances, or specifically ML EC2 instances. So, everything's basically using EC2 here, um but there you go.