AWS Fundamentals: AWS Cloud-Native

MONITORING APPLICATION :

Amazon Cloud-watch, you can monitor your cloud infrastructure intelligently. Cloud-watch will collect data from your cloud-based infrastructure in one centralized location. With this data, you can create statistics, which drive operational procedures using features such as Cloud-watch Alarms, which create alarms and trigger automated events based on those statistics.

Let’s consider this situation. You get reports from your user base that they’re noticing a latency in your services. Since you now have been made aware of an issue, you can start looking at your system to figure out what the cause of the issue is. Upon investigation, you realize that the CPU load is around 95 percent across all of your server instances.

In traditional way :

you would page an admin, who then launches another server to help bring the load down across the servers. The problem with this approach, manually responding to a problem, is that your users experience interruption before you can mitigate the disruption to your services.

In AWS way :

instead of waiting until hearing about latency from users, instead, you can create an alarm that says, if a group of EC2 instances has CPU over 60 percent for more than 5 minutes, trigger an auto scaling policy, automatically launch a new server into the pool, and alert an admin.

Cloud-watch Logs is a place where you can send your log files for viewing in the console, and to stream to other services, like Lambda or Amazon Elasticsearch for analytics. Cloud-watch is integrated with over 70 AWS services. You can use Cloud-watch to set alarms, visualize logs and metrics side-by-side, take automated actions, troubleshoot operational issues, and discover insights to optimize your applications. Getting started with Cloud-watch is easy and there’s no up-front commitment or minimum fee.

For more information, https://aws.amazon.com/cloudwatch/.

SCALING APPLICATION :

Load balancing :

Introducing Amazon Elastic Load Balancer (ELB), and the idea behind elastic load balancing is it is a regional service, that launches inside your VPC. When you launch it, you have got a number of flavors you can choose from based on your application needs, whether you just want pure network load balancing or sophisticated application-level load balancing, they can send to different parts of your application based on what it sees, but the fundamentals are the same.

The traffic comes in, and the elastic load balancer knows all of the different instances that are signed up to take traffic, and in fact if you have auto scaling set up, and more instances come online, then the elastic load balancer can absolutely send traffic to those as well. The advantage then is automatic traffic distribution, to the instances, and it doesn’t even have to come from external traffic.

ELB can also be used internally to help decouple instances. For example, you might have a front-end web server fleet, that then wants to communicate to an application tier. Instead of having each front-end web server know each application tier, you can simply have your elastic load balancer in between, take care of handling all those relationships.

ELB offers three types of load balancers that all feature the high availability, automatic scaling, and robust security that are necessary to make your applications fault-tolerant.

1. An Application Load Balancer operates at the request level (Layer 7), routing traffic to targets–such as EC2 instances, microservices and containers–within Amazon VPC, based on the content of the request. It’s ideal for the advanced load balancing of Hypertext Transfer Protocol (HTTP) and Secure HTTP (HTTPS) traffic.
2. A Network Load Balancer operates at the connection level (Layer 4), routing connections to targets–such as Amazon EC2 instances, microservices, and containers–within Amazon VPC, based on IP protocol data. It’s ideal for load-balancing Transmission Control Protocol (TCP) traffic.
3. The Classic Load Balancer provides basic load balancing across multiple Amazon EC2 instances, and it operates at both the request level and the connection level.

Auto scaling :

Previously, we built our application and launched it on two separate EC2 instances. Those EC2 instances lived in two separate Availability Zones and two public subnets. We then had our private subnets with our database instances in them. We also created an elastic load balancer. Our elastic load balancer distributed traffic across our EC2 instances.

Let’s imagine a scenario where our application starts to get really popular. As more people visit our application, the demand on our two web servers is going to go up. At some point, our two instances aren’t going to be able to handle that demand, and we’re going to need more EC2 instances. Instead of launching these instances manually, we want to do it automatically.

Auto Scaling is what allows us to provision more capacity on demand, depending on different thresholds that we set, and we can set those in CloudWatch. EC2 instances that are created inside an Auto Scaling group, meaning, they’re identical, they can launch as needed by the Auto Scaling engine, all connected through the elastic load balancer.

We can configure the scaling policies. So, for scaling policies, what we’re talking about here, is you can set up a scaling policy with CloudWatch that whenever your instance capacity reaches a certain limit or any other metric that you would like, you can add more instances to the pool, which would deploy more EC2 instances into your Auto Scaling group.

1. You had your EC2 instances. Again, they’re part of the Auto Scaling group. They’re identical, they’re launched as part of the launch configuration.
2. As they were put under stress, they all reported down to the CloudWatch engine, saying their CPUs are overloaded.
3. CloudWatch went into an alarm state and told the Auto Scaling engine, “Give me more EC2 instances.” As they each came online, they all reported back to the elastic load balancer, they got traffic, ending up giving us all the scalability we need.
4. Now, if we wait around long enough, what we would see is, as the CPU load dropped off, then one by one, they would each get terminated, because we no longer need them, bringing our state all the way back down to the basic two we need, the minimum number for this particular group.
5. All of that done without any human intervention.