AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) certification video training course by prepaway along with practice test questions and answers, study guide and exam dumps provides the ultimate training package to help you pass.

Managing EC2 at Scale - Systems Manager (SSM) & Opswork

13. SSM Session Manager Hands On

So, on the left, locate Session Manager, and we want to establish an SSH session between our two instances. So if you have a look at my delegation security, the security group does not have any SSH security group rules inbound, okay?

Yet we're going to be able to start a session, and this session is going to start. For example, on my product instance, we can start a session right here, and as you can see, I am connected directly into my easy instance, so I can do HECO Hello World, and here we go.

We have some information around Hello World, and we can run any command, so we can do LS and look at all the directories, so the user can easily go to home, and we need to go sudo to be elevated. So I was elevated to pseudo-su, and then we could do CD home (which was simple for the user), and now I am in my EC.

There are two users listed in the directory, and I can do whatever I want with them. Okay, we could see if Http is installed, so we could do sudo yam install and Httpd, and obviously it's already installed because we installed it before using a run command, so that's pretty cool because this entire session will be logged, OK? because the session manager handles it And also, my instance does not have any SSH inbound security rules, yet I am able to run some commands within it. This is the Session Manager's power. Now I can just terminate this.

Okay? And now if I go back into my session manager, I can look at session history and see that history was being created right here. And finally, you could edit the preferences of SessionManager to have an idle timeout, to have KMS encryption for your sessions, and to run the session as a specific user for your next instances. OK, so the username could be, for example, "EC2 user" if you wanted to enable Cloud Watch logging if it's relevant for your Amazon Linux you can enable Cloud Watch logging. So do you want to log all your sessions to Cloud Watch logs?

Yes. as well as three logging Do you want to send all of the log data to Amazon S3, as well as some Linux Shell and Windows Shell profiles? To be honest, it's quite useful. And all this can be edited right here. And I know a lot of companies and people use Session Manager from within Systems Manager to execute actions on your instances because it is way more controlled and also has a lot more compliance around it. So that's it. I hope you liked it, and I will see you in the next lecture.

14. SSM Cleanup

Okay, so to clean up this section, if we go into Fleet Manager, as we can see, under Fleet Manager, we have three managed instances, OK? And so that means that we need to terminate them. So to make sure we don't have any running costs, take your three instances and terminate them, and you should be good to go. So that's it for this lecture. I hope you like it, and I will see you in the next lecture.

15. AWS OpsWorks Overview

So it's just a quick lesson. find out what is meant by "scalabhighly available" (availability).Because this is a beginner's level, feel free to lecture if you are very confident in the concept. However, scalability implies that your application system may obstruct rapid adaptation. And so there are two scalability levels. There's going to be scalability, elasticity, or horizontal scalability. Scalability differs from high availability as a result. They' buti different. different.

So what I'd like to do is to deepen all of these distinctions, and we'll center all of the examples of good practice to make things work. So let's talk about scalability. salability. Vertical silty indicates that the instance size must be increased. So let's take a phone opera example. r example. We have an operator who we think is fantastic, but he can only take five minutes. We now have an operator, a more capable operator who can take up to ten minutes. So we've basically promoted our junior to actor, operator, and evaluator, which means better and better.

all center. operator, overloaded, and he overloaded I don't want to hire ant, hire operator, and double dust capacity vertically. Actually, fact, I'll say "operator." You know what? I'll hire six. There are evaluators, horizontally scaled centers, and left centers. So you have distributed systems when you have scaling, and this is what happens when you have a web application or an application. However, keep in mind that application consolidation can result in a disorganized system.

And I believe it is now possible to subscribe to cloud services such as EC2 horizontally. Two, simply right-just-right-click on the web page, and we have an instance that we can apply horizontally. Now, let's talk about availability. High availability is frequently associated with horizontal scaling, but not always. If AWS is available, the availability of your application or system means that it is in a datacenter or two. And the ability to survive a loss is critical to availability. So incentive falls, and we flee.

So let's talk about operators. operators. Maybe I have three phones in the first building in New York, and three phones in the second building, but on the other side of the country. Francisco. Now, if my building's Internet and phone connections go down, that's fine; everything will still work. But my second building in San Frastillico is still fine, and they can still take calls. one calls. In that case, a Center for All Diseases is available. Now. High availability, also known as passive. For example, we have relatively high availability when we have R, but it is not active.be active. And this is where "hscaling" and "l scaling" come into play. So, for example, I have all of my phone calls in two different buildings in New York. New York.

They're all taking calls at the same time. 2for EC two, what mean? that mean? The scale of vertices increases with increasing body size. Itscalinglled scow. So, or down. So, for example, the smallest size available in AWST today is nano, or two Nano.

instance. And I'm sure the gaps will widen as time passes.oes along. ......... a a.s.m.m...,..,..,..,..,.Ely large. scaling That is, when you increase the number of instances, you increase the number of instances (AWS calls it "scaled out" or "scaled out"), and when you decrease the number of instances, you decrease the number of instances. As a result, auto-scaling group balancers would be possible. When you run the same application across AZs, you get high availability. little AZ.

So this is for an au group with a Grou Multi-AZas mulitas balancer that is also a LanMulti-AZas mulitas balancer. So that's it for now. k rundown. k rundown. So we're fine on the terms High availability and scalability They're necessary for you to understand when you look at the exam questions, because they can trick you some times. So make sure you're very confident with those. They're pretty easy when you think about them. Remember the call center in your mind when you have these questions. Okay, that's good. I will see you at the next lecture.

EC2 High Availability and Scalability

1. [SAA/DVA] What is High Availability and Scalability ?

Now let's learn about load balancing, and a question you may have is, "What is load balancing?" Well, a load balancer is going to be a server or a set of servers that will forward traffic that is received to multiple back-end or downstream instances or servers. So the idea is that, for example, we have three easy instances, and they're going to be fronted by an elastic load balancer, which is a set of servers behind the scenes. Now, what happens when you have, for example, three users directly connecting to your elastic load balancer? Well, the first one is going to have its load sent to one backend and two instances. And because there's load balancing, if another user is connecting to your elastic load balancer, it will be sent to another EC2 instance, and then finally, if a third user is connecting to your elastic load balancer, that user will again be load balanced and sent to the third EC2 instance. So the idea is that the more users you have, the more the load is going to be balanced across EC's two instances. But the idea is that your users do not know which back-end instances they are connected to; they just know that they have to connect to your elastic load balancer, which gives them only one endpoint of connectivity only.

Now, why should you use a load balancer? Where you're going to spread the load across multiple downstream instances, you're going to expose a single point of access to your application. As I just said, you're going to seamlessly handle failures of downstream instances because the load bouncer will have some health check mechanisms and can understand which instances it can send traffic to. You can perform health checks on your instances, provide SSL termination so that your websites receive https-encrypted traffic, enforce stickiness with cookies, achieve high availability across zones, and separate private traffic from private traffic on your cloud; we'll go over these concepts in greater detail later. So the elastic load balancer is a managed load balancer, as such a device will be managing it and guaranteeing that it will be working no matter what it is. It will take care of upgrades, maintenance, and high availability, and it will provide you with a few configuration hubs to tweak the behaviour of the load balancer. The idea is that using an elastic load balancer is a no-brainer because it will cost you less than setting up your own load balancer, and if you have to manage your own load balancer, it will be a nightmare from a scalability perspective.

As a result, the load balancer is integrated with a wide range of AWS offerings and services. The idea is that it can be integrated with as few as two instances, but we'll likely see auto-scaling groups, Amazon, ECS, CertificateManager, Cloud Watch, Route 53, Wave Global Accelerator, and other services in the future. So the idea is that a load balancer is a no-brainer when it comes to load balancing on AWS. Now, I mentioned health checks, so help checks are a way for your elastic load balancer to verify whether or not an ECQ instance is properly working, because if it's not working properly, then we don't want to send any traffic to that instance.

So they're crucial for load balancers, and they're done by using a port and a route to check the health of them. So for example, in this example, I have the protocol as Http, the port as 4567, and the endpoint as "health," because maybe this route is an easy way from an application perspective to check the health of my application. And if the ECQ instance does not respond with an okay response, which is usually the 200 status code of HTTP, then the instance will be marked as unhealthy and the elastic load balancer will not send traffic to that instance. OK, so now you have four kinds of managed load balancers on AWS. You have the classic load balancer, known as CLD, from the "older generation," or the V one, which was introduced in 2009. Now it's using its compatible http://, TCP, SSL, or secure TCP. And overall, AWS does not want you to use that load balancer anymore, so it's going to be shown as deprecated within the console but still available to use.

Then we have newer generations of load balancers, so we have the application load balancer from 2016, also called ALB, and this one supports the HTTP, HTTPS, and WebSocket protocols. Then we have the network load balancer from 2017, which supports the TCP, TLS, Secure TCP, and UDP protocols. And then finally, we have the gateway load balancer from 2020 GWL, which operates at the network layer. So there are three. and the IP Protocol. And I showed it to you right here on this slide. but this will not be discussed, if at all, in this section because, in my opinion, the first three are relevant for this section, but the gateway load balancer would be relevant for a networking section, and therefore this will not be discussed in this section, no matter what. Okay? And if it's not discussed in the course, then obviously it's not relevant for your exam, obviously.

So overall, it is definitely recommended for you to use the newer generation load balancers, as they provide more features and some load balancers can be set up as internal. So private access for the network or external public load balancers, for example, for your websites and public applications Finally, you need to understand the security around load balancers so users can access them from anywhere using HTTP or HTTPS. And therefore, the security group rule is going to look something like this, where the portrait can be 80 or four, four, three, and the source is going to be zero, zero, zero, which means anywhere. And so we allow the users to connect to our load balancer, but then the cool thing is that the ECQ instances should only allow traffic coming directly from the load balancer, and therefore the security group rule of your EC2 instances is going to look a little bit different.

So it's going to allow HTTP traffic on port 80, and the source of it is not going to be an IP range; it's going to be a security group. So we're going to link the security group of the EC2 instance to the security group of the load balancer. And effectively what this will do is that it will say that the EC two instance is only allowing traffic if the traffic originates from the load balancer which is an enhanced security mechanism. So that's it for the overview of load balancers. I hope you liked it. And obviously, in this section, we're going to discuss a lot more around classic application load balancers and network lobbies. So I'll see you in the next class.

Prepaway's AWS Certified SysOps Administrator - Associate: AWS Certified SysOps Administrator - Associate (SOA-C02) video training course for passing certification exams is the only solution which you need.