Gain in-depth knowledge for passing your exam with Exam-Labs AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) certification video training course. The most trusted and reliable name for studying and passing with VCE files which include Amazon AWS Certified SysOps Administrator - Associate practice test questions and answers, study guide and exam practice test questions. Unlike any other AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) video training course for your certification exam.

EC2 for SysOps

12. EC2 Instance Types Deep Dive

So on AWS: And for the exam, you kind of need to know the instance types, but not all of them because there are so many, just the main ones. So let me give you a quick rundown of the instance types available on AWS. The R instance is the application that uses a lot of RAM. So R for RAM, such as in memory cache, in memory databases, or whatever. So this is our instance for Ram. C is for good CPU or compute. As a result, this is typically where databases or applications that perform numerous computations, such as big data, reside. This is a good instance for these. M is in the middle; think medium, think Medium, think Middle.So it's between RAM and the CPU. So you use M instances for a Web app or something very general. I is for good IO or instance storage. So when you need a lot of good disc operations, this is a database you're going to need. You also require the "I" instance. G stands for GPU. So G instances include a GPU and are ideal for video rendering or even machine learning, as GPU is used in machine learning. And then there are the instances we've been using so far, T 2 or T 3. And we've been using T-2 because that's the one in the free tier. But they're called burstable instances. So you get a good burst performance for a short period of time, but if you abuse that burst, you lose a burst and your capacity. We'll see this in a second. And then we have "t" two, "t" three, all unlimited. which gives you unlimited. Burst. So overall, in the real world, to choose the instance type you need, I suggest you use the Ecto instances info website. It is amazing. So let's get started right away. We type EC2 instance info, and here we get basically a comparison of all the instances on AWS. And this is a very big table, as you can see. And there's way more than just what I told you. There are some Z instances or whatever, but what you need to remember is the one I gave you. So RCMIGNT is okay. And so just explore that table. It's kind of neat to see what each instance does. They provide you with instant storage, CPU performance, memory, and cost, which is extremely useful. And they also give you some information if you want to reserve your instances and so on. So let's get back to our little course. T2, T3 are thus the worst of all possible scenarios. And so with this instance, that means that overall, when the instance is running, you get good performance, okay? CPU performance, it's doing fine. And then sometimes you may need to process something very unexpected. Perhaps there is a spike in load in your application, and your CPU skyrockets to 100% in this case. During these spikes, the CPU can do something called a burst. And a burst is like a boost of power, and the CPU is very good during that burst. But if your machine bursts, it uses burst credit. And as you can expect, if the credits are all gone, then the CPU becomes bad, or, I may say, terrible. And then when your load is over, when the CPU has stopped bursting, you gain back the credits over time. So this is what the burstable instances are. They're good, then they kill credits. And then when you need them the most, when they have a very unexpected load, they're amazing. And then if you abuse that, you just lose all the capacity, and they become very bad. so they can be amazing. But basically, if you run low on credit all the time, then you probably shouldn't use T Two and T Three. You should probably use something like a C or M type instance. So how do we see the credit usage and balance? Well, in Cloud Watch, we can see this. And so, as you can see, this is just for a dummy instance that I have. But when the CPU skyrockets, you can see that the credit usage here is very, very high, and the credit balance goes down. But after the CPU credit usage is done and we're not using it anymore, we slowly gain back our credit balance to a normal level. And so this is what you have to deal with. You have to be very careful and obviously monitor the credit usage and balance over time, otherwise you may have surprises. Now, with the CPU credits, you basically give them a different space, and you can find this in the documentation. But, in general, the larger the instance, and if you have TWO large instances, the faster you'll earn credits and the better the CPU will be. And finally, there is a thing called "Two. T three. Unlimited. And, as of November 2017, you have an unlimited burst credit balance. That means you can burst for as long as you want, but you're going to pay for it. And so you need to make sure that you don't burst without reason. And it's a new offering, so be very careful. I find it very nice, but it needs to be for very specific kinds of use cases, and you need to monitor the health of your instances, otherwise you're going to pay a lot of money. You can also read more on this blog. So, in terms of instance types, I believe what you should remember most is which type of instance to use if you require RAM, CPU Medium, IO, or GPU. And also remember how T-2 and T-3 work under the hood. They become very, very bad if you don't expect how they work. If you get a large load, you may experience unexpected production issues. Okay, so that was it; I hope you liked it, and I will see you in the next lecture.

13. Burstable Instances

So let's take a look now at burstable types of instances in AWS. For example, t = 2 or t = 3, but just a t family overall. So that means that when you have a T2 or T3 type of instance, you are using it, and the instance will have OKCP performance. And then when the machine needs to process something very unexpected, for example, that requires a lot of CPU for a spike in load, it can burst. That means that the CPU can become very good and can handle this spike for you. So then when the machine bursts, it uses what's called a burst credit. And as your ECU instance has its lifecycle, it will accumulate burst credit. And then, when the CPU is intensely being used, the burst credits will be used as well. So if all credits are gone, the CPU becomes really bad. and that means that you're not using the right type of instance. And I wish you this in graphs right now. So if the machine stops bursting, the CPU credits are getting backed up over time, and you can reuse them whenever you need them. So burst of all incidents can beamazing to handle unexpected type of traffic. And if they handle it correctly, it could be a really difficult situation for you. However, if you have an instance that consistently runs out of credit, you should consider switching to a different type of instance because you may not be using the type of family correctly. So, if you look closely, you'll notice that this is from Cloud Watch monitoring. As we can see, as soon as the CPU level spikes, there will be a decrease in the CPU credit balance. As you can see here, there's a spike in usage of credit, and that means that here the CPU credit balance will go down, and then once the spike stops, credit will be reacquillated to go back to a different balance. Okay, so if we look at the credits, different types of instances will earn credits at a different rate. As you can see, for a T2 micro, we have one vCPU with a launch credit of 30, and you earn six credits per hour, with a maximum credit of 144 and a baseline performance of 10%. Okay, so what happens when the credits are exhausted? So I did run a little experiment for you to see. So I ran the CPU stress command to pickup 100% CPU utilisation on a T two micro. And then we can see that after all the credits are exhausted, the actual measured CPU utilisation will drop. So let's have a look. This is again from Cloud Watch. So I did launch my instance, and then I ran the stress command. As you can see, the CPUs skyrocketed and went all the way to 100%, and they did so on the right hand side. We can now look at the CPU credit balance. So it started at 30, which is the number of CPU credits you get when you launch the two micros. And then because the CPU solution was skyrocketing at 100%, the credit balance was being used. And as we go along in time, the CPUcurrent credit balance drops, drops, drop, drop, drops, whichallows my utilisation to stop peak, but when theCPU credit balance reached the zero. So when we had no more credits and, as you can see, even though the stress command was still being run, the CPU solution dropped all the way to 10%, which is the baseline. As we can see now, there is a lower CPU. So when there is no more credit on your CPU, even though you are running your instance at full capacity, the measured CPU utilisation will be really low and will not be at 100%, which is the behaviour you should know going into the exam. So how can we tell you that? So we have T 23 unlimited, which isto give you an unlimited burst credit balance. So this time you don't have a credit balance. You can just tap into it as much as you want. That means that you're going to pay extra money if you go over the credit balance, but you will not lose in performance. And in case you have research that goes over the 24-hour baseline, you get additional pay for the number of CPUs per hour you're using. So be careful. If you have a CPU instance that really always runs at 100%, you will not be shown that behavior, and you will pay a lot of money. Okay? So be careful and monitor the CPU of your instances. So this is what I want to show you in this graph. So we can see that the CPU solution right here peaks at 100%, and we're also using the CPU credit usage a lot in cloud watch, okay? five credits per hour. And if we look at the CPU credit balance, we started at zero. This is the blue line right here, which means that first we are tapping into this 24-hour period surplus credit balance. So we are tapping into it and then, when we reach 72, which is how many credits we can use in 1 hour for this type of instance. The CPU surplus credit charge is then applied to what was charged. which is a feature of T-3 unlimited. or T two unlimited. That's the extra CPU balance that was given to you, and you're paying for it. But it still allows your CPU transition to remain stable at 100% and give you the performance you need. So, if I launch an instance and look at Amazon X two, it will choose TWO micro, and I will click on next configure instance details. Scroll down. As you can see, we have a credit specification of type unlimited. And if I do so, then I'm going to unlimited mode, and additional charges may apply, but at least I will get the performance that I need. And it would be the same if you wanted to use a T-three. Okay? And finally, if I look at my T2 Micro right now and go into monitoring, I can have a look at the credits. So if I scroll down in here to the very bottom, I can look at CPU credit usage. So how many CPU credits were being used every hour as well as my CPU credit balance? And so if I just view this in metrics to give you a larger graph in Cloud Watch metrics, As you can see, I started at about 30 credits, and over time, because I haven't been using my GP Easy to Instance a lot, I've been accumulating credits. And when I was using my CPU instance, my easy instance, then some CPU credits were being consumed here as well. Okay, so that's it for this lecture. I hope you liked it, and I will see you in the next lecture.

14. Elastic IPs

So now let's talk about elastic IP. So when you stop and start a new instance, it will change its public IP. And if you need to have a fixed public IP, then you need an elastic IP. So this is for use cases where you need a consistent IP address across your two EC instances. So it's an IPV-4 elastic IP that you own as long as you don't delete it. So it's a reservation. And so the idea is that you attach this elastic IP to one EC2 instance at a time, and that EC2 instance will inherit the IPV 4 from it. Okay, you can remap this IP across instances, and we'll see this in the hands on.And you don't pay for the elastic IP if it's attached to a server, which is a good thing, but if you just reserve the elastic IP without attaching it to a server, then you're going to be billed for it. So Elastic IP, why do we use them? Well, the use case is that you can mask the failure of an instance or software by rapidly remapping the address that your instance is accessible at to another instance in your account that is also running the software. And by default, you can have up to five elastic IPs in your account. You can ask to increase that, but the idea is that you should avoid using elastic IPS. At least that's my personal opinion, unless you really have to. which is why you can only have five elastic IP in your account. Other options for passing that include using a random public IP and instead registering a DNS name to it, possibly using Route53, or using a load balancer with a static host name, and the load balancer is smart enough to redirect to your correct EC2 instance. Now let's see elastic IPS in action. So I have my first instance here and I need to makesure that I'm going to have a security group that's going tobe open so I'm going to find a security group and makesure from the rules that SSH is going to be open toall to anywhere and click on Save Rule. Here we go. We're good to go. So I have my first instance, but I'm going to create a second instance. I will call my second instance So I'll go to Micro and click on Add Storage, Add Tags, and the name is my second instance of configuring a security group. I will choose the same security group as before. So LSSes launch the demo key pair and launch my instance. Now we have two easy instances being run, and what I'm going to do is first set them up. So I'm going to go into EC2-instanceconnect to connect to my instance. This is EC-2 instance number one. I'm going to make sure that I remove my hello dot TXT.And so I'm going to so there's no files in here. Now I'm going to just create a new file. For example, one TXT will be a touch hello. As you can see, now we have a file named hello and an instance of one TXT available to us, which is enough. So I've set up my first instance, and then for my second instance, I'm going to do the exact same thing. I'm going to connect to it using easy-to-instance connect, and I'm going to touch a new file named hello-instance-two.txt, which shows that, yes, we are on instance number two. Okay, so now that my two instances are available, as you can see, they have different IPV 4 addresses. And so what I'm going to do is first attach elastic IP to my first instance. So to do so on the left-hand side, I'm going to go into elastic IPS and allocate a new elastic IP address from Amazon's pool of IPV4 four address.But you could bring your own if you wanted to. It's been allocated this IP. And as we can see now, this IPV4 right here is accessible to me. And so what I can do is that I can attach it to my easy to instance action, and then I can associate this elastic IP address with an instance, and I'm going to attach it to my first P address withSo now it is associated with my first instance. So, if we go into my instances and look at my first instance, we can see that the public IPV4 number is 18 198, which is the same as my previous IP address. That is elective. So what I mean is that if I do an SSH command now and then replace the public IP by the one I have from the elastic IP and connect to it, we do LS. As you can see, I am on instance one because it says hello, instance one TXT. So I can disconnect. And what I will do is launch the exact same command, but after remapping my elastic IP beforehand. So what I can do is go back to my elastic IP action. I will disassociate this elastic IP. So this will remove it from my current EC2 instance, and then I will associate this elastic IP with my second instance, and then associate, so it is now associated with the second EC2 instance. And so if I rerun this command right here, we're in business. And we get some warning because the remote host identification has changed. So I'm on a different EC2 instance, and this is the security that my SSL command has, which is saying that, Hey, it looks like you're connected to a different host even though you're using the same command. So this is expected for us, but this is a good warning to know in case you're being attacked. And so if I do clear my screen and do LS this time, I see Hello. Instance Two TXT, which showed that I'm connected to my second instance. So this is really the power of elastic IP. Here, you can use the same command and have it rejected by two different instances. And so this is how we can mask the failure of instance one, for example, by remaxing the elastic IP to the second instance. So to finish this, please make sure to terminate your second instance and go to your Elastic IP. And all you have to do is disconnect this elastic IP. And then, when this is done, you can release the elastic IP address in order not to be billed for it because it will be unused. Okay, so that's it for this lecture. I hope you liked it, and I will see you in the next lecture.

15. CloudWatch Metrics for EC2

Okay, this is super important for the exam to know how Cloud Watch is linked to ECU. super, super important. So let's go ahead and see this. AWS provides some metrics for your easy-to-instances, and AWS will push these metrics for you. You have some basic monitoring, such as the metrics being collected at five-minute intervals, but you can enable detailed monitoring, in which case these metrics will be collected at a 1-minute interval. And these metrics include CPU, network disk, and a status check metric. Remember these four. They're very important. Then you'll be able to use custom metrics. By definition, they are yours to push. They're custom. And so the basic resolution of your customer metric is 1 minute, but you can go into a high-resolution customer metric, which is all the way to 1 second. You may want to push custom metrics for ease of use, but that includes RAM or application-level metrics. For example, if you do that, then you have to make sure that your EC2 instance does have an IMRole that allows it to push metrics to Cloud Watch. So all the metrics included for ECTwo are ones you need to know them.So the first metric you need to know is CPU. We will get the CPU utilisation as a metric, and in case we have T-2 or T-3 instances that burst, we can get the credit usage for the burst and the credit balance for the network. We're able to figure out how much network is going in and out of our instance for the status check; it's basically checking whether or not our instance is healthy. We got an instant status, which is Amazon checking if the ECQ VM is working, or a system status, which is Amazon checking if the underlying hardware is working. and so these are very important ones. These are Amazon health checks, so you don't have any controls over that, but it basically gives you an idea, and you need to be able to differentiate between your instance status and your system status. Finally, only instance stores supported instant stores for two instances. We get disc information; we'll get the read and write operations, or bites, for our instance store. And finally, RAM is not included in the AWS EC. Two metrics. This is a common question at the exam. They ask you: Can you get the RAM from CloudWatch? No, you cannot. AWS does not push the RAM usage in Cloud Watch. It is for you to push. Okay, so let's have a look at our monitoring metrics, for instance. So we are going into this monitoring tab, and then we can have a look at all the metrics in there, which I can add into a cloud dashboard to make it a little easier to see. So I can create a new dashboard, which I'll call Easy Metrics. And okay, click on "Add to Dashboard." And that's my Dashboard name. I just got an easy two. And then click on "Create. Here we go. and then add to the dashboard. So I am in my dashboard from Cloud Watch, and we can have a look at all the metrics. So first of all, we know the CPU utilisation rate. So this is something that can be varied between zero and 100%. And this is a very common metric to monitor status checks. is going to be something we'll see soon, which is around how to have a look at whether your EC2 instances are having a failure on the hardware level or the software level. As a result, the metrics on failure can be obtained by being between zero and one. Networking in and out is quite obvious, as is how much network goes in and out of your EC2 instance. and number of packets as well. Discrete and disc writes appear to be zero. And it's normal because we have an EBS volume attached to our EC 2 instance. The disc reads and writes metrics are going to be seen on the EBS volume itself. Okay, but if your EC2 instance was a simple two instance with an instance store, which means that the drive and storage are physically attached to your EC2 instance, you'd see these metrics populate. Okay? This is something everyone should know and be aware of. Finally, for CPU credit usage, this is going to be seen here for burstable types of instances, otherwise it will be zero. And we can also have a look at the CPU credit balance. As you can see, as we're not using our IS two instance right now, the CPU credit balance is going up over time. And finally, if you wanted to enable detailed monitoring for each instance, this is how you would do it. So you click on Monitoring and then on Manage Detailed Monitoring, and you can enable it. So this is going to show you graphs with a one-minute period instead of five. So right now this is a five-minute period, but we can go into a one-minute period. But you're going to incur extra costs if you do enable detailed monitoring, which I will not do. Okay, so that's it for this lecture. I hope you enjoyed it, and remember to delete your Cloud dashboard at the end. So delete this dashboard and you're good to go. I will see you at the next lecture.

16. CloudWatch - Unified CloudWatch Agent – Overview

So let's talk about a way for us to collect metrics and logs from within our EC2 instances. These are the Unified Cloud Watch agents. So this is for virtual servers. It could be for your ETI instances or your on-premise servers. And you're going to connect additional system-level metrics such as the RAM processes, use the space, et cetera. And you can also send the logs to CloudWatch logs because, by default, if you launch an Easy-Two instance, there will be no files or logs that will be sent from the ETI instance to Cloud Watch logs without using an agent. And that agent could be the CloudWatch unified agent. So the idea is that if you wanted to get a memory metric from within your two instances, the only way you could do it is by using the Cloud Watch unified agent. Then, if you wanted to configure your agent, you could do so by using the SSM Parameter Store and storing the configuration in a central location, or you could specify a configuration file. Alternatively, you have a Unified Cloud Watch agent on your EC2 instance and want to send metrics and logs to Cloud Watch. So for this, you would just configure the agent and make sure you have the right permissions. It's also true if you wanted to use a server from within your own corporate data center. So on premise, you would still install UnifiedCloud Which Agent, you would specify the Ian permissions, and then you would be able to push the logs and push the metrics. So they're important because you are interacting with the SSM parameter store as well as the CloudWatch clouds and Cloud Watch metrics services. Then you should be able to have the correction permissions attached to your Im role on your ECU instance or attached to your access keys that are deployed on your on-premises servers. Finally, any metrics pushed by the Unified Cloud to which agents begin with the prefix CW Agent. So this is going to be in this namespace. You can configure and change this, but at least this is the default one. So something you need to know that comes up in the exam is that there is a proxy plug-in on the cloud called Which Agents, and that means that with this proxy plug-in, you're going to collect metrics and monitor system utilisation of individual processes running on your Linux or Windows servers. For example, you will get some information around how much time a CPU will be used by a process, how much memory a process will be using, or the processes that are running directly on your EC2 instance. So you can select which processes to monitor by PID file. So you can get the PID and the process ID number. If you want to filter the processes to monitor again, you can get the name of the process or the pattern, and all metrics related to the statistics of your processes on your Linux or Windows servers will begin with the Proxtat prefix, so proxy underscore CPU time. proxy under CPU usage, and so on. So keep in mind that the only way to get some information about the processes running and social metrics is to use the Unified Cloud Watch agents deployed on your two instances and configured to use that plug-in. So that's it for this lecture. I hope you liked it, and I will see you in the next lecture.

Pay a fraction of the cost to study with Exam-Labs AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) certification video training course. Passing the certification exams have never been easier. With the complete self-paced exam prep solution including AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) certification video training course, practice test questions and answers, exam practice test questions and study guide, you have nothing to worry about for your next certification exam.

Hide