Category: AWS

Amazon Kinesis

Posted on by Osama Mustafa in AWS, Cloud

Amazon Kinesis for data collection and analysis

With Amazon Kinesis, you:

  • Collect, process, and analyze data streams in real time. Kinesis has the capacity to process streaming data at any scale. It provides you the flexibility to choose the tools that best suit the requirements of your application in a cost-effective way.
  • Ingest real-time data such as video, audio, application logs, website clickstreams, and Internet of Things (IoT) telemetry data. The ingested data can be used for machine learning, analytics, and other applications.
  • Can process and analyze data as it arrives, and respond instantly. You don’t have to wait until all data is collected before the processing begins.

Amazon Kinesis Data Streams

To get started using Amazon Kinesis Data Streams, create a stream and specify the number of shards. Each shard is a unit of read and write capacity. Each shard can read up to 1 MB of data per second and write at a rate of 2 MB per second. The total capacity of a stream is the sum of the capacities of its shards. Increase or decrease the number of shards in a stream as needed. Data being written is in the form of a record, which can be up to 1 MB in size.

  • Producers write data into the stream. A producer might be an Amazon EC2 instance, a mobile client, an on-premises server, or an IoT device.
  • Consumers receive the streaming data that the producers generate. A consumer might be an application running on an EC2 instance or AWS Lambda. If it’s on an Amazon EC2 instance, the application will need to scale as the amount of streaming data increases. If this is the case, run it in an Auto Scaling group. 
  • Each consumer reads from a particular shard. There might be more than one application processing the same data. 
  • Another way to write a consumer application is to use AWS Lambda, which lets you run code without having to provision or manage servers. 
  • The results of the consumer applications can be stored by AWS services such as Amazon S3, Amazon DynamoDB, and Amazon RedShift.

Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehose starts to process data in near-real time. Kinesis Data Firehose can send records to Amazon S3, Amazon Redshift, Amazon Elasticsearch Service (ES), and any HTTP endpoint owned by you. It can also send records to any of your third-party service providers, including Datadog, New Relic, and Splunk.

Regards

Osama

SQS vs. SNS

Posted on by Osama Mustafa in AWS, Cloud

Loose coupling with Amazon Simple Queue Service

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that use use to you to decouple and scale microservices, distributed systems, and serverless applications The service works on a massive scale, processing billions of messages per day. It stores all message queues and messages within a single, highly available AWS Region with multiple redundant Availability Zones. This ensures that no single computer, network, or Availability Zone failure can make messages inaccessible. Messages can be sent and read simultaneously.

A loosely coupled workload involves processing a large number of smaller jobs. The loss of one node or job in a loosely coupled workload usually doesn’t delay the entire calculation. The lost work can be picked up later or omitted altogether.

With Amazon SQS, you can decouple pre-processing steps from compute steps and post-processing steps. Building applications from individual components that perform discrete functions improves scalability and reliability. Decoupling components is a best practice for designing modern applications. Amazon SQS frequently lies at the heart of cloud-native loosely coupled solutions.

SQS queue types

Amazon SQS offers two types of message queues


STANDARD QUEUES

Standard queues support at-least-once message delivery and provide best-effort ordering. Messages are generally delivered in the same order in which they are sent. However, because of the highly distributed architecture, more than one copy of a message might be delivered out of order. Standard queues can handle a nearly unlimited number of API calls per second. You can use standard message queues if your application can process messages that arrive repetitively and out of order.

FIFO QUEUES

FIFO (First-In-First-Out) queues are designed to enhance messaging between applications when the order of operations and events is critical or where duplicates can’t be tolerated. FIFO queues also provide exactly-once processing but have a limited number of API calls per second. FIFO queues are designed to enhance messaging between applications when the order of operations and events is critical.

Optimizing your Amazon SQS queue configurations

When creating an Amazon SQS queue, you need to consider how your application interacts with the queue. This information will help you optimize the configuration of your queue to control costs and increase performance.

TUNE YOUR VISIBILITY TIMEOUT

When a consumer receives an SQS message, that message remains in the queue until the consumer deletes it. You can configure the SQS queue’s visibility timeout setting to make that message invisible to other consumers for a period of time. This helps to prevent another consumer from processing the same message. The default visibility timeout is 30 seconds. The consumer deletes the message once it completes processing the message. If the consumer fails to delete the message before the visibility timeout expires, it becomes visible to other consumers and can be processed again. 

Typically, you should set the visibility timeout to the maximum time that it takes your application to process and delete a message from the queue. Setting too short of a timeout increases the possibility of your application processing a message twice. Too long of a visibility timeout delays subsequent attempts at processing a message.

CHOOSE THE RIGHT POLLING TYPE

You can configure an Amazon SQS queue to use either short polling or long polling. Queues with short polling:

  • Send a response to the consumer immediately after receiving a request providing a faster response
  • Increases the number of responses and therefore costs. 

SQS queues with long polling:

  • Do not return a response until at least one message arrives or the poll times out.
  • Less frequent responses but decreases costs.

Depending on the frequency of messages arriving in your queue, many of the responses from a queue using short polling could just be reporting an empty queue. Unless your application requires an immediate response to its poll requests, long polling is the preferable option.

Amazon SNS

Amazon SNS is a web service that makes it easy to set up, operate, and send notifications from the cloud. The service follows the publish-subscribe (pub-sub) messaging paradigm, with notifications being delivered to clients using a push mechanism.

Amazon SNS publisher to multiple SQS queues

Using highly available services, such as Amazon SNS, to perform basic message routing is an effective way of distributing messages to microservices. The two main forms of communications between microservices are request-response, and observer. In the example, an observer type is used to fan out orders to two different SQS queues based on the order type. 

To deliver Amazon SNS notifications to an SQS queue, you subscribe to a topic specifying Amazon SQS as the transport and a valid SQS queue as the endpoint. To permit the SQS queue to receive notifications from Amazon SNS, the SQS queue owner must subscribe the SQS queue to the topic for Amazon SNS. If the user owns the Amazon SNS topic being subscribed to and the SQS queue receiving the notifications, nothing else is required. Any message published to the topic will automatically be delivered to the specified SQS queue. If the owner of the SQS queue is not the owner of the topic, Amazon SNS requires an explicit confirmation to the subscription request.

Amazon SNS and Amazon SQS

FeaturesAmazon SNSAmazon SQS
Message persistenceNoYes
Delivery mechanismPush (passive)Poll (active)
Producer and consumerPublisher and subscriberSend or receive
Distribution modelOne to manyOne to one

Regards

Osama

AWS API GATEWAY

Posted on by Osama Mustafa in AWS, Cloud

With API Gateway, you can create, publish, maintain, monitor, and secure APIs.

With API Gateway, you can connect your applications to AWS services and other public or private websites. It provides consistent RESTful and HTTP APIs for mobile and web applications to access AWS services and other resources hosted outside of AWS.

As a gateway, it handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls. These include traffic management, authorization and access control, monitoring, and API version management.

API Gateway sample architecture

API Gateway integrates with Amazon CloudWatch by sending log messages and detailed metrics to it. You can activate logging for each stage in your API or for each method. You can set the verbosity of the logging (Error or Info), and if full request and response data should be logged.

The detailed metrics that API Gateway can send to Amazon CloudWatch are:

  • Number of API calls
  • Latency
  • Integration latency
  • HTTP 400 and 500 errors

API Gateway features

Creates a unified API front end for multiple microservices.
Provides DDoS protection and throttling for your backend.
Authenticates and authorizes requests to a backend.
Throttles, meters, and monetizes API usage by third-party developers.

Regards

Osama

VPC Peering

Posted on by Osama Mustafa in AWS, Cloud

Connecting VPCs with VPC peering

When your business or architecture becomes large enough, you will find the need to separate logical elements for security or architectural needs, or just for simplicity’s sake. 

A VPC peering connection is a one-to-one relationship between two VPCs. There can only be one peering resource between any two VPCs. You can create multiple VPC peering connections for each VPC that you own, but transitive peering relationships are not supported. You will not have any peering relationship with VPCs that your VPC is not directly peered with. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account within a single Region.

To establish a VPC peering connection, the owner of the requester VPC (or local VPC) sends a request to the owner of the peer VPC. You or another AWS account can own the peer VPC. It cannot have a Classless Inter-Domain Routing (CIDR) block that overlaps with your requester VPC’s CIDR block. The owner of the peer VPC has to accept the VPC peering connection request to activate the VPC peering connection. 

To permit the flow of traffic between the peer VPCs using private IP addresses, add a route to one or more of your VPC’s route tables that points to the IP address range of the peer VPC. The owner of the peer VPC adds a route to one of their VPC’s route tables that points to the IP address range of your VPC. You might also need to update the security group rules that are associated with your instance to ensure that traffic to and from the peer VPC is not restricted. 

Benefits of VPC peering

Review some of the benefits of using VPC peering to connect multiple VPCs together.

  • bulletBypass the internet gateway or virtual private gateway. Use VPC peering to quickly connect two or more of your networks without needing other virtual appliances in your environment.
  • bulletUse highly available connections. VPC peering connections are redundant by default. AWS manages your connection.
  • bulletAvoid bandwidth bottlenecks. All inter-Region traffic is encrypted with no single point of failure or bandwidth bottlenecks. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and distributed denial of service (DDoS) attacks.
  • bulletUse private IP addresses to direct traffic. The VPC peering traffic remains in the private IP space.

 VPC peering for shared services

your security team provides you with a shared services VPC that each department can peer with. This VPC allows your resources to connect to a shared directory service, security scanning tools, monitoring or logging tools, and other services.

A VPC peering connection with a VPC in a different Region is present. Inter-Region VPC peering allows VPC resources that run in different AWS Regions to communicate with each other using private IP addresses. You won’t be required to use gateways, virtual private network (VPN) connections, or separate physical hardware to send traffic between your Regions.

full mesh VPC peering

each VPC must have a one-to-one connection with each VPC with which it is approved to communicate. This is because each VPC peering connection is nontransitive in nature and does not permit network traffic to pass from one peering connection to another.

The number of connections required has a direct impact on the number of potential points of failure and the requirement for monitoring. The fewer connections you need, the fewer you need to monitor and the fewer potential points of failure.

Regards

Osama

VPC endpoints

Posted on by Osama Mustafa in AWS, Cloud

A VPC endpoint enables private connections between your VPC and supported AWS services without requiring an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC do not require public IP addresses to communicate with resources in the service. Traffic between your VPC and the other service does not leave the AWS network.

Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components. They permit communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic.

Types of VPC endpoints

GATEWAY ENDPOINT

Specify a gateway endpoint as a route target in your route table. A gateway endpoint is meant for traffic destined to Amazon S3, or Amazon DynamoDB and remains inside the AWS network.

instance A in the public subnet communicates with Amazon S3 via an internet gateway. Instance A has a route to local destinations in the VPC. Instance B communicates with an Amazon S3 bucket and an Amazon DynamoDB table using unique gateway endpoints. The diagram shows an example of a private route table. The private route table directs your Amazon S3 and DynamoDB requests through each gateway endpoint using routes. The route table uses a prefix list to target the specific Region for each service.

INTERFACE ENDPOINT

With an interface VPC endpoint (interface endpoint), you can privately connect your VPC to services as if they were in your VPC. When the interface endpoint is created, traffic is directed to the new endpoint without changes to any route tables in your VPC.

For example, a Region is shown with Systems Manager outside of the example VPC. The example VPC has a public and private subnet with an Amazon Elastic Compute Cloud (Amazon EC2) instance in each. Systems Manager traffic sent to ssm.region.amazonaws.com is sent to an elastic network interface in the private subnet.

Gateway VPC endpoints and interface VPC endpoints help you access services over the AWS backbone.

A gateway VPC endpoint (gateway endpoint) is a gateway that you specify as a target for a route in your route table for traffic destined for a supported AWS service. The following AWS services are supported: Amazon S3 and Amazon DynamoDB.

An interface VPC endpoint (interface endpoint) is an elastic network interface with a private IP address from the IP address range of your subnet. The network interface serves as an entry point for traffic destined to a supported service. AWS PrivateLink powers interface endpoints and it avoids exposing traffic to the public internet.

Regards

Osama

Microservices

Posted on by Osama Mustafa in AWS, Cloud

Monolithic and microservice architectures

To learn the differences between monolithic and microservice architectures, and how to architect for microservices,

LOOSE COUPLING

Traditional monolithic infrastructures revolve around chains of tightly integrated servers, each with a specific purpose. When one of those components or layers goes down, the disruption to the system can be fatal. This configuration also impedes scaling. If you add or remove servers at one layer, you must also connect every server on each connecting layer.

With loose coupling, you use managed solutions as intermediaries between layers of your system. Failures and scaling of a component are automatically handled by the intermediary. Two primary solutions for decoupling your components are load balancers and message queues.

MICROSERVICES

Microservices are an architectural and organizational approach to software development. Using a microservices approach, you design software as a collection of small services. Each service is deployed independently and communicates over well-defined APIs. This speeds up your deployment cycles, fosters innovation, and improves both maintainability and scalability of your applications.

Autonomous

The component services in a microservices architecture are isolated from one another and communicate through an API. Because of this, you can develop, update, deploy, operate, and scale a service without affecting the other services. These services can be owned by small autonomous teams, allowing for an agile approach.

Specialized

You design each service for a set of capabilities that focuses on solving a specific problem. Teams can write each service in the programming languages best suited to that service. They can also host their services on different compute resources.

In this example, a monolithic forum application is refactored to use a microservices architecture: a user service, a topic service, and a message service. The /users service team runs the user service on AWS Lambda. The /topics service team runs the topics service on Amazon Elastic Compute Cloud (Amazon EC2). The /messages service team runs the messages service on containers. The microservices application is distributed across two Availability Zones and manages traffic with an Application Load Balancer.

What is a container?

A container is a self-contained environment that includes the all the components needed to run an application. This includes the runtime engine, your application code, dependencies such as libraries, and configuration information. You containers will deploy the same way on any server running Docker which gives your application portability, repeatability and scalability.

We build microservice infrastructures with containers. Although running Virtual Machines (VMs) in the cloud gives you a dynamic, elastic environment, you can simplify your developers’ processes. Containers provide a standard way to package your application’s code, configurations, and dependencies into a single object. 

Containers share an operating system installed on the server and run as resource-isolated processes, ensuring quick, reliable, and consistent deployments, regardless of the environment.

Containers and microservices

Containers are an ideal choice for microservice architectures because they are scalable, portable, and continuously deployable.

Earlier in this module, you learned how microservice architectures decompose traditional, monolithic architectures into independent components that run as services and communicate using lightweight APIs. With these microservice environments, you can iterate quickly, with increased resilience, efficiency, and overall agility. 

You can build each microservice on a container. Because each microservice is a separate component, it can tolerate failure better. If a container fails, it can be shut down and a new one can be started quickly for that particular service. If a certain service has a lot of traffic, you can scale out the containers for that microservice. This eliminates the need to deploy additional servers to support the entire application. Microservices and containers are also great for continuous deployment. You can update individual services without impacting any of the other components of your application.

LEVELS OF ABSTRACTION

A bare metal server runs a standalone operating system (OS) with one or many applications by using libraries. Costs remain constant, whether the server is running at 0 percent usage or 100 percent usage. To scale, you must buy and configure additional servers. It is also difficult to build applications that work on multiple servers since the OS on those servers would have to be the same. You also need to synchronize the application library versions.

With virtual machines, you isolate applications and their libraries with their own full OS. The downside of VMs is that the virtualization layer is “heavy.” Each VM has its own OS. This requires more host CPU and RAM, reducing efficiency and performance. Having an individual OS for each VM also means more patching, more updates, and more space on the physical host.

With a containerization platform, containers share a machine’s OS system kernel and the underlying OS file system is exposed. Sharing a machine’s OS system kernel allows shared libraries but can permit individual libraries as needed. This makes containers highly portable. You can also start and stop containers faster than VMs. Containers are lightweight, efficient, and fast.

Unlike a VM, containers can run on any Linux system, with appropriate kernel feature support and the Docker daemon. This makes them portable. Your laptop, your VM, your Amazon EC2 instance, and your bare metal server are all potential hosts. 

The lack of a hypervisor requirement also results in almost no noticeable performance overhead. The processes are communicating directly to the kernel and are largely unaware of their container silo. Most containers boot in only a couple of seconds. 

CONTAINERS ON AWS

When running containers on AWS, you have multiple options. 

Running containers on top of an EC2 instance is common practice and uses elements of VM deployments and containerization. This diagram shows the underlying server infrastructure—a physical server, the hypervisor, and two virtual guest operating systems. One of these operating systems runs Docker, and the other runs a separate application. The virtual guest OS with Docker installed can build and run containers. Though possible, this type of deployment can only scale to the size of the EC2 instance used. You also have to actively manage the networking, access, and maintenance of your containers. 

Using an orchestration tool is a scalable solution for running containers on AWS. An orchestration tool uses a pool of compute resources, which can include hundreds of EC2 instances to host containers. The orchestration tool launches and shuts down containers as demand on your application changes. It manages connectivity to and from your containers. It also helps manage container deployments and updates. 

Running containers on AWS

Deploying your managed container solutions on AWS involves selecting and configuring some components.

Amazon Elastic Container Registry (ECR)

Amazon Elastic Container Registry (Amazon ECR) is a managed Docker container registry. You push your container images to Amazon ECR and can then pull those images to launch containers. With Amazon ECR, you can compress, encrypt, and control access to your container images. You also manage versioning and and image tags. An Amazon ECR private registry is provided to each AWS account. You can create one or more repositories in your registry and store images in them. 

Amazon Elastic Container Service (ECS)

Amazon Elastic Container Service (Amazon ECS) is a highly scalable, high-performance container management service that supports Docker containers. Amazon ECS manages the scaling, maintenance, and connectivity for your containerized applications. 

With Amazon ECS, you create ECS services, which launch ECS tasks. Amazon ECS tasks can use one or more container images. Amazon ECS services scale your running task count to meet demand on your application.

You create an Amazon ECS cluster with dedicated infrastructure for your application. You can run your tasks and services on a serverless infrastructure managed by AWS Fargate. If you prefer more control over your infrastructure, manage your tasks and services on a cluster of EC2 instances. Your cluster can scale EC2 hosting capacity by adding or removing EC2 instances from your cluster. 

Amazon EKS 

Kubernetes is an open-source software that you can use to deploy and manage containerized applications at scale. Kubernetes manages clusters of Amazon EC2 compute instances and runs containers on those instances with processes for deployment, maintenance, and scaling. With Kubernetes, you can run any type of containerized applications using the same tool set on premises and in the cloud.
 

Amazon Elastic Kubernetes Service (Amazon EKS) is a certified conformant, managed Kubernetes service. Amazon EKS helps you provide highly available and secure clusters and automates key tasks such as patching, node provisioning, and updates.

  • Run applications at scale – Define complex containerized applications and run them at scale across a cluster of servers.
  • Seamlessly move applications – Move containerized applications from local development to production deployments on the cloud.
  • Run anywhere – Run highly available and scalable Kubernetes clusters.

Amazon EKS is a managed service that you can use to run Kubernetes on AWS without having to install and operate your own Kubernetes clusters. With Amazon EKS, AWS manages highly available services and upgrades for you. Amazon EKS runs three Kubernetes managers across three Availability Zones. It detects and replaces unhealthy managers and provides automated version upgrades and patching for the managers. Amazon EKS is also integrated with many AWS services to provide scalability and security for your applications.

Amazon EKS runs the latest version of the open-source Kubernetes software, so you can use all of the existing plugins and tooling from the Kubernetes community. Applications running on Amazon EKS are fully compatible with applications running on any standard Kubernetes environment, whether running in on-premises data centers or on public clouds.

Kubernetes architecture

The basic components of Kubernetes architecture are user interfaces, control plane, and data plane. Web user interfaces, such as dashboards or the command-line tool, kubectl, allow you to deploy, manage, and troubleshoot containerized applications and cluster resources. 

The control plane manages object states, responds to changes, and maintains a record of all objects. The data plane provides capacity such as CPU, memory, network, storage, and includes the worker node running in  containers in a pod.

AWS Fargate serverless cluster hosting

AWS Fargate is a technology for Amazon ECS and Amazon EKS that you can use to run containers without having to manage servers or clusters. With Fargate, you no longer have to provision, configure, and scale clusters of VMs to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing. 

Automation

Posted on by Osama Mustafa in AWS, Cloud

Infrastructure as code (IaC)

You can simplify the deployment of your AWS resources using an infrastructure as code approach. With and IaC solution, you create a template that describes all the resources that you want (like Amazon EC2 instances or Amazon RDS DB instances), and IaC solution takes care of provisioning and configuring those resources for you.

The benefits of infrastructure as code 

Gain the benefits of repeatability and reusability while building your environments. Build the same complex environments with one template, or a combination of templates.

For instance, a template can be designed so that different AMIs are used in the development or the production environments.

In this scenario, the template has been updated to add new security groups to the instance stacks. With one change to the templates, both environments can have the new security group resource added.

CloudFormation

The template describes the resources to be created

Essentially, CloudFormation is an API wrapper. When you create an EC2 instance in the AWS Management Console wizard, you initiate an API call to the Amazon EC2 service. The information you enter through the wizard is passed on as parameters. 

CloudFormation manages the dependencies and relationships.

Author your CloudFormation template with any code editor, check it into a version-control system such as GitHub or CodeCommit, and review files before deploying. 

Stacks

All resources in a stack are defined by the stack’s CloudFormation template. Stacks are a collection of AWS resources managed as a single unit. Stacks allow the creation and deletion of resources as a unit.

Change management in stacks

Change sets

Change sets allow you to preview how proposed changes to a stack might impact your running resources. For example, whether your changes will delete or replace any critical resources. AWS CloudFormation makes the changes to your stack only when you decide to execute the change set. You can create and manage change sets using the CloudFormation console, AWS CLI, or CloudFormation API.

Infrastructure tools

When building on AWS you can use different tools to help automate the deployment of infrastructure and manage those resources once deployed.

Tools for deployment

When choosing infrastructure deployment tools, you need to find a balance between convenience and control. Some tools give you complete control and have you choose every component and configuration. Though you can customize your deployment to fit your business needs, this requires greater expertise and more resources to manage and maintain. Other tools are designed for convenience and include preconfigured infrastructure templates for common solutions. Though these tools are easier to use and require less maintenance, you do not always have the ability to customize your infrastructure components. 

AWS Elastic Beanstalk

The goal of Elastic Beanstalk is to help developers deploy and maintain scalable web applications and services in the cloud without having to worry about the underlying infrastructure. Elastic Beanstalk configures each EC2 instance in your environment with the components necessary to run applications for the selected platform. With Elastic Beanstalk you can provision infrastructure to support common application designs, such as web applications and worker services.

AWS Solutions Library

AWS Solutions Library helps you solve common problems and build faster using the AWS platform. Solutions are vetted by AWS architects and are designed to be operationally effective, reliable, secure, and cost efficient.

AWS Cloud Development Kit (AWS CDK)

AWS CDK is a software development framework that defines your cloud application resources using a declarative model and familiar programming languages. AWS CDK includes a library of customizable constructs, which are building blocks consisting of one or more resources and include common configurations. You can use AWS CDK to generate CloudFormation templates and deploy your infrastructure along with your application runtime assets.

Automating infrastructure management with AWS Systems Manager


AWS Systems Manager makes it easier to bridge your existing infrastructure with AWS. Systems Manager helps you automatically collect software inventory, apply operating system (OS) patches, create system images, and configure Windows and Linux OSs. These capabilities help you:

  • Define and track system configurations
  • Prevent drift
  • Maintain software compliance of your Amazon EC2 and on-premises configurations 

With AWS Systems Manager, you can:

  • Centralize operational data from multiple AWS services and automate tasks across your AWS resources.
  • Create logical groups of resources such as applications, different layers of an application stack, or development and production environments.
  • Select a resource group and view its recent API activity, resource configuration changes, related notifications, operational alerts, software inventory, and patch compliance status.
  • Take action on each resource group depending on your operational needs.

You can open AWS Systems Manager from the Amazon EC2 console. Select the instances you want to manage, and define the management tasks you want to perform. Systems Manager is available at no cost to manage your Amazon EC2 and on-premises resources.

Benefits of Systems Manager

Shortens the time to detect problems

View operational data for groups of resources, so you can quickly identify any issues that might impact applications that use those resources. 

Automates tasks to increase efficiency

Automate operational tasks to help make your teams more efficient.

Improves visibility and control

Understand and control the state of your resource groups. 

Manages hybrid environments

Manage servers running on AWS and in your on-premises data center through a single interface.

Maintains security and compliance

Maintain security and compliance by scanning your instances against your patch, configuration, and custom policies.

Regards

Osama

AWS Auto Scaling 

Posted on by Osama Mustafa in AWS, Cloud

AWS Auto Scaling lets you build scaling plans that automate how groups of different resources respond to changes in demand. You can optimize availability, costs, or a balance of both. AWS Auto Scaling automatically creates all of the scaling policies and sets targets for you, based on your needs.

Auto scaling

AWS Auto Scaling monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. Using AWS Auto Scaling, you can set up application scaling for multiple resources across multiple services in minutes. 

The service provides a simple, powerful user interface that lets you build scaling plans for resources including Amazon EC2 instances and Spot Fleets, and other compute and database services that will be addressed later in the course. 

AWS Auto Scaling makes scaling simple with recommendations that let you optimize performance, costs, or balance between them.

Amazon EC2 Auto Scaling

With Amazon EC2 Auto Scaling, you can build scaling plans that automate how groups of different EC2 resources respond to changes in demand. You can optimize availability, costs, or a balance of both.

If you specify scaling policies, then Amazon EC2 Auto Scaling can launch or terminate instances as demand on your application increases or decreases. Amazon EC2 Auto Scaling integrates with ELB so you can attach one or more load balancers to an existing Amazon EC2 Auto Scaling group. After you attach the load balancer, it automatically registers the instances in the group and distributes incoming traffic across the instances.

Amazon EC2 Auto Scaling components

Launch templateAmazon EC2 Auto Scaling groupAuto scaling policy
What resources do you need?Where and how many do you need?When and for how long do you need them?
AMI
Instance type
Security groups
Roles		VPC and subnets
Load balancer
Define:
Minimum instances
Maximum instances
Desired capacity (optional)		Scheduled
On-demand
Predictive auto scaling
Scale-out policy
Scale-in policy

Launch template

A launch template is an instance configuration template that a group uses to launch EC2 instances. Included are the instance type, EBS volume, ID of the AMI, a key pair, security groups, and the other parameters that you use to launch EC2 instances.

Launch templates are the preferred method to configure your group in AWS because they provide:

  • A consistent experience
  • Simple permissions
  • Governance and best practices
  • Increased productivity

Optimize cost with EC2 Auto Scaling

Amazon EC2 Auto Scaling supports multiple purchasing options within the same group. You can launch and automatically scale a fleet of On-Demand Instances and Spot Instances within a single Auto Scaling group. In addition to receiving discounts for using Spot Instances, you can use Reserved Instances or a Savings Plan to receive discounted rates of the regular On-Demand Instance pricing. All of these factors combined help you to optimize your cost savings for EC2 instances, while making sure that you obtain the desired scale and performance for your application.

Using Amazon EC2 Fleet, you can define a combination of EC2 instance types to make up the desired capacity of your group. This is defined as a percentage of each type of purchasing option. Amazon EC2 Auto Scaling will maintain the desired cost optimization as your group scales in or out. Groups made up of mixed fleets still support the same lifecycle hooks, instance health checks, and scheduled scaling as a single-fleet group.

Regards

Osama

AWS Load Balancing

Posted on by Osama Mustafa in AWS, Cloud

A load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones to increase the availability of your application. A load balancer works with listeners. You can have more than one listener per load balancer. 

A listener checks for connection requests from clients, using the protocol and port that you configure. The load balancer forwards requests to one or more target groups, based on the rules that you define.

Each rule specifies a target group, condition, and priority. The traffic is forwarded to that group when the condition is met. You define a default rule for each listener. You can add rules that specify different target groups based on the content of the request. Each target group routes requests to one or more registered targets, for example EC2 instances, using the specified protocol and port number. You can register a target with multiple target groups.

Elastic Load Balancing

AWS Elastic Load Balancing (ELB) is one of the most widely used AWS services. It has been adopted by organizations of all sizes, in all geographies, and across every industry. ELBs automatically distribute traffic across multiple targets, provide high availability, incorporate security features, and perform health checks.

ELB features

ELB load balancers are the only load balancers available on AWS that natively connect users to your EC2 instances, container deployments, and AWS Lambda functions. Some key feature sets include the following:

  • High availability – ELB automatically distributes your traffic across multiple targets in a single Availability Zone or multiple Availability Zones. Examples of targets include EC2 instances, containers, and IP addresses.
  • Layer 4 or Layer 7 HTTP and HTTPS load balancing – You can load balance your HTTP or HTTPS applications for Layer 7-specific features. Alternatively, you can use strict Layer 4 load balancing for applications that rely purely on the TCP.
  • Security features – Use Amazon VPC to create and manage security groups associated with load balancers to provide additional networking and security options. You can also create an internal (non-internet-facing) load balancer.
  • Health checks – ELB load balancers can detect unhealthy targets, stop sending traffic to them, and spread the load across the remaining healthy targets.
  • Monitoring operations – To monitor the performance of your applications in real time, ELB integrates with CloudWatch metrics and provides request tracing.

Types of load balancers

Application Load Balancer

This load balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model. Application Load Balancers support the following: Content-based routing, applications that run in containers, and open standard protocols (WebSocket and HTTP/2). This type of balancer is ideal for advanced load balancing of HTTP and HTTPS traffic. 

Network Load Balancer

This load balancer is designed to handle tens of millions of requests per second while maintaining high throughput at ultra low-latency. Network Load Balancer operates at the connection level (Layer 4), routing connections to targets based on IP protocol data. Targets include EC2 instances, containers, and IP addresses. It is ideal for balancing TCP traffic.

Gateway Load Balancer

This load balancer makes it easy to deploy, scale, and manage your third-party virtual appliances. It provides one gateway for distributing traffic across multiple virtual appliances, and scales them up, or down, based on demand. This distribution reduces potential points of failure in your network and increases availability. Gateway Load Balancer transparently passes all Layer 3 traffic through third-party virtual appliances. It is invisible to the source and destination.

Classic Load Balancer

ELB common features

FeaturesApplication Load BalancerNetwork  Load BalancerGateway  Load Balancer
Health checks✔✔✔
CloudWatch metrics✔✔✔
Logging✔✔✔
Secure Sockets Layer (SSL) offloading✔✔
Connection draining✔✔✔
Preserve source IP address✔✔✔
Static IP address**✔
Lambda functions as a target✔✔✔
Redirects✔
Fixed-response actions✔

Regards

Osama

AWS Infrastructure

Posted on by Osama Mustafa in AWS, Cloud

The AWS Global Cloud Infrastructure is the most secure, extensive, and reliable cloud platform, offering over 200 fully featured services from data centers globally.

AWS Data Center

AWS pioneered cloud computing in 2006 to provide rapid and secure infrastructure. AWS continuously innovates on the design and systems of data centers to protect them from man-made and natural risks. Today, AWS provides data centers at a large, global scale. AWS implements controls, builds automated systems, and conducts third-party audits to confirm security and compliance. As a result, the most highly-regulated organizations in the world trust AWS every day.

Availability Zone – AZ

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. Availability Zones are multiple, isolated areas within a particular geographic location. When you launch an instance, you can select an Availability Zone or let AWS choose one for you. If you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests.

Region

Each AWS Region consists of multiple, isolated, and physically separate Availability Zones within a geographic area. This achieves the greatest possible fault tolerance and stability. In your account, you determine which Regions you need. You can run applications and workloads from a Region to reduce latency to end users. You can do this while avoiding the upfront expenses, long-term commitments, and scaling challenges associated with maintaining and operating a global infrastructure.

AWS Local Zone

AWS Local Zones can be used for highly demanding applications that require single-digit millisecond latency to end users. Media and entertainment content creation, real-time multiplayer gaming, and Machine learning hosting and training are some use cases for AWS Local Zones.

CloudFront – Edge Location

An edge location is the nearest point to a requester of an AWS service. Edge locations are located in major cities around the world. They receive requests and cache copies of your content for faster delivery.

Regards

Osama