AWS Could Technical Essentials

Week 1: Getting Started with AWS

Application will be built in a private network using Amazon Virtual Private Cloud or VPC.

We will host the application's backend code on Amazon Elastic Compute Cloud or EC2, which is a
service that essentially offers virtual machines on AWS. So let's go ahead and add those service to
our diagram as well. The employee data will be stored in a database which will also live inside of
this network. And this will be hosted using a service called Amazon Relational Database Service or
RDS, or we might be hosting it on Amazon DynamoDB. The images for the employees will be stored
using the object storage service Amazon Simple Storage Service, or what we call S3, which will
allow the unlimited storage of any file type like the images in this example. We are also going to use
Amazon CloudWatch for monitoring the solution. And we want to ensure that our application is
scalable and fault-tolerant. So I'm also going to add an Elastic Load Balancer here which will
distribute the traffic across the EC2 instances. And we will also add Amazon EC2 Auto Scaling to this
diagram, so that way our solution can scale out with demand and scale in when demand decreases.
For security and identity, we will be using Amazon Identity and Access Management or IAM
What is the Cloud?
In the past, companies and organizations hosted and maintained hardware such as compute,
storage, and networking equipment in their own data centers. They needed to allocate entire
infrastructure departments to take care of them, resulting in a costly operation that made some
workloads and experimentation impossible.

As internet usage became more widespread, the demand for compute, storage, and networking
equipment increased. For some companies and organizations, the cost of maintaining a large
physical presence was unsustainable. To solve this problem, cloud computing was created.

Cloud computing is the on-demand delivery of IT resources over the internet with pay-as-you-go
pricing. You no longer have to manage and maintain your own hardware in your own data centers.
Companies like AWS own and maintain these data centers and provide virtualized data center
technologies and services to users over the internet.

The Six Benefits of Cloud Computing.

 Pay as you go.
 Benefit from massive economies of scale.
 Stop guessing capacity
 Increase speed and agility.
 Stop spending money running and maintaining data centers.
 Go global in minutes

Types of Cloud Computing Deployment Models

Cloud

A cloud-based application is fully deployed in the cloud and all parts of the application run in the
cloud. Applications in the cloud have either been created in the cloud or have been migrated from
an existing infrastructure to take advantage of the benefits of cloud computing. Cloud-based
applications can be built on low-level infrastructure pieces or can use higher level services that
provide abstraction from the management, architecting, and scaling requirements of core
infrastructure.

Hybrid

A hybrid deployment is a way to connect infrastructure and applications between cloud-based

resources and existing resources that are not located in the cloud. The most common method of
hybrid deployment is between the cloud and existing on-premises infrastructure to extend, and
grow, an organization's infrastructure into the cloud while connecting cloud resources to the internal
system. For more information on how AWS can help you with your hybrid deployment, visit our
Hybrid Cloud with AWS page.

On-premises

The deployment of resources on-premises, using virtualization and resource management tools, is
sometimes called the “private cloud.” On-premises deployment doesn’t provide many of the
benefits of cloud computing but is sometimes sought for its ability to provide dedicated resources. In
most cases this deployment model is the same as legacy IT infrastructure while using application
management and virtualization technologies to try and increase resource utilization. For more
information on how AWS can help, see Use case: Cloud services on-premises.

AWS Global Infra

4 Aspect to Consider while selecting Server Region

4 factors to consider before selecting region:

Choose the Right AWS Region

Consider four main aspects when deciding which AWS Region to host your applications and
workloads: latency, price, service availability, and compliance.

Latency. If your application is sensitive to latency, choose a Region that is close to your user base.
This helps prevent long wait times for your customers. Synchronous applications such as gaming,
telephony, WebSockets, and IoT are significantly affected by higher latency, but even asynchronous
workloads, such as ecommerce applications, can suffer from an impact on user connectivity.

Price. Due to the local economy and the physical nature of operating data centers, prices may vary
from one Region to another. The pricing in a Region can be impacted by internet connectivity, prices
of imported pieces of equipment, customs, real estate, and more. Instead of charging a flat rate
worldwide, AWS charges based on the financial factors specific to the location.

Service availability. Some services may not be available in some Regions. The AWS documentation
provides a table containing the Regions and the available services within each one.
Data compliance. Enterprise companies often need to comply with regulations that require
customer data to be stored in a specific geographic territory. If applicable, you should choose a
Region that meets your compliance requirements

To recap, regions, availability zones, and data centers exist in a redundant nested sort of way. There
are data centers inside availability zones and availability zones inside regions. And how do you
choose a region? By looking at compliance, latency, pricing, and service availability.

Aws Regions;

Availablity Zone- AZ
Inside every Region is a cluster of Availability Zones (AZ). An AZ consists of one or more
data centers with redundant power, networking, and connectivity. These data centers
operate in discrete facilities with undisclosed locations. They are connected using
redundant high-speed and low-latency links. AZs also have a code name. Since they’re
located inside Regions, they can be addressed by appending a letter to the end of the
Region code name. For example:

 us-east-1a: an AZ in us-east-1 (Northern Virginia Region)

 sa-east-1b: an AZ in sa-east-1 (São Paulo Region in South America)
If you see that a resource exists in us-east-1c, you know this resource is located in AZ c of
the us-east-1 Region.
AWS Services

Scope AWS Services

Depending on the AWS Service you use, your resources are either deployed at the AZ,
Region, or Global level. Each service is different, so you need to understand how the scope
of a service may affect your application architecture. When you operate a Region-scoped
service, you only need to select the Region you want to use. If you are not asked to specify
an individual AZ to deploy the service in, this is an indicator that the service operates on a
Region-scope level. For region-scoped services, AWS automatically performs actions to
increase data durability and availability. On the other hand, some services ask you to
specify an AZ. With these services, you are often responsible for increasing the data
durability and high availability of these resources.

Maintain Resiliency

To keep your application available, you need to maintain high availability and resiliency. A
well-known best practice for cloud architecture is to use Region-scoped, managed
services. These services come with availability and resiliency built in. When that is not
possible, make sure the workload is replicated across multiple AZs. At a minimum, you
should use two AZs. If one entire AZ fails, your application will have infrastructure up and
running in at least a second AZ to take over the traffic.

Reading 1.4: Interacting with AWS

Every action you make in AWS is an API call that is authenticated and authorized. In
AWS, you can make API calls to services and resources through the

1. AWS Management Console,

2. the AWS Command Line Interface (CLI),
3. the AWS Software Development Kits (SDKs).
Security and the AWS Shared Responsibility Model

When you begin working with the AWS Cloud, managing security and compliance is a shared
responsibility between AWS and you.

What Is AWS Responsible For?

AWS is responsible for security of the cloud. This means AWS is required to protect and
secure the infrastructure that runs all the services offered in the AWS Cloud. AWS is
responsible for:

 Protecting and securing AWS Regions, Availability Zones, and data centers,
down to the physical security of the buildings
 Managing the hardware, software, and networking components that run AWS
services, such as the physical server, host operating systems, virtualization
layers, and AWS networking components

The level of responsibility AWS has depends on the service. AWS classifies services into three
different categories. The following table provides information about each, as well as the AWS
responsibility.
Access will be required at 3 spots-
At app level- who can login and access the user data base.
At the Amazon S3 level, where api making calls have to be verified & authenticated
And At network level.

AWS IAM ( identity access management) can manage these 2 functions

Then there is User- User Group etc.

Policies can be applied to the group also

What Is IAM?

IAM is a web service that enables you to manage access to your AWS account and
resources. It also provides a centralized view of who and what are allowed inside your
AWS account (authentication), and who and what have permissions to use and work with
your AWS resources (authorization). With IAM, you can share access to an AWS account
and resources without having to share your set of access keys or password. You can also
provide granular access to those working in your account, so that people and services only
have permissions to the resources they need. For example, to provide a user of your AWS
account with read-only access to a particular AWS service, you can granularly select which
actions and which resources in that service they can access.

IAM User Credentials

An IAM user consists of a name and a set of credentials. When creating a user, you can
choose to provide the user:

 Access to the AWS Management Console

 Programmatic access to the AWS Command Line Interface (AWS CLI) and AWS
Application Programming Interface (AWS API)
To access the AWS Management Console, provide the users with a user name and
password. For programmatic access, AWS generates a set of access keys that can be used
with the AWS CLI and AWS API. IAM user credentials are considered permanent, in that
they stay with the user until there’s a forced rotation by admins.

What Is an IAM Group?

An IAM group is a collection of users. All users in the group inherit the permissions
assigned to the group. This makes it easy to give permissions to multiple users at once. It’s
a more convenient and scalable way of managing permissions for users in your AWS
account. This is why using IAM groups is a best practice.

What Is an IAM Policy?

To manage access and provide permissions to AWS services and resources, you create IAM
policies and attach them to IAM users, groups, and roles. Whenever a user or role makes a
request, AWS evaluates the policies associated with them. For example, if you have a
developer inside the developers group who makes a request to an AWS service, AWS
evaluates any policies attached to the developers group and any policies attached to the
developer user to determine if the request should be allowed or denied.

IAM Policy Examples

Most policies are stored in AWS as JSON documents with several policy elements. Take a
look at the following example of what providing admin access through an IAM identity-
based policy looks like.

"Version": "2012-10-17",
 "Statement": [{

"Effect": "Allow",

"Action": "*",

"Resource": "*"

}]

}In this policy, there are four major JSON elements: Version, Effect, Action, and Resource.

The Version element defines the version of the policy language. It specifies the language
syntax rules that are needed by AWS to process a policy. To use all the available policy
features, include "Version": "2012-10-17" before the "Statement" element in all your
policies.

The Effect element specifies whether the statement will allow or deny access. In this
policy, the Effect is "Allow", which means you’re providing access to a particular resource.

The Action element describes the type of action that should be allowed or denied. In the
above policy, the action is "*". This is called a wildcard, and it is used to symbolize every
action inside your AWS account.

The Resource element specifies the object or objects that the policy statement covers. In
the policy example above, the resource is also the wildcard "*". This represents all
resources inside your AWS console.

Putting all this information together, you have a policy that allows you to perform all
actions on all resources inside your AWS account. This is what we refer to as an
administrator policy.

Let’s look at another example of a more granular IAM policy.

{

"Version": "2012-10-17",

"Statement": [{

"Effect": "Allow",

"Action": [

"iam: ChangePassword",

"iam: GetUser"

"Resource": "arn:aws:iam::123456789012:user/${aws:username}"

}]

}After looking at the JSON, you can see that this policy allows the IAM user to change their
own IAM password (iam:ChangePassword) and get information about their own user
(iam:GetUser). It only permits them to access their own credentials because the resource
restricts access with the variable substitution ${aws:username}.

Role Based Access in AWS

Principle of Least Privilege
Least privilege is a standard security principle that advises you to grant only the necessary
permissions to do a particular job and nothing more. To implement least privilege for access control,
start with the minimum set of permissions in an IAM policy and then grant additional permissions as
necessary for a user, group, or role.

Maintaining roles is easier than maintaining users. When you assume a role, IAM dynamically
provides temporary credentials that expire after a defined period of time, between 15 minutes and
36 hours. Users, on the other hand, have long-term credentials in the form of user name and
password combinations or a set of access keys
Consider Using an Identity Provider
If you want to have more than a handful of people working on your application, consider
managing employee identity information through an identity provider (IdP). Using an IdP, whether
it be an AWS service such as AWS Single Sign-On (SSO) or a third-party identity provider, provides
you a single source of truth for all identities in your organization. You no longer have to create
separate IAM users in AWS. You can instead use IAM roles to provide permissions to identities that
are federated from your IdP. For example, you have an employee, Martha, that has access to
multiple AWS accounts. Instead of creating and managing multiple IAM users named Martha in
each of those AWS accounts, you can manage Martha in your company’s IdP. If Martha moves
within the company or leaves the company, Martha can be updated in the IdP, rather than in every
AWS account you have.

Need of single sign on

If you have an organization that spans many employees and multiple AWS accounts, you may
want your employees to sign in with a single credential. AWS SSO is an IdP that lets your users sign
in to a user portal with a single set of credentials. It then provides them access to all their assigned
accounts and applications in one central location. AWS SSO is similar to IAM, in that it offers a
directory where you can create users, organize them in groups, and set permissions across those
groups, and grant access to AWS resources. However, AWS SSO has some advantages over IAM. For
example, if you’re using a third-party IdP, you can sync your users and groups to AWS SSO. This
removes the burden of having to re-create users that already exist elsewhere, and it enables you to
manage those users from your IdP. More importantly, AWS SSO separates the duties between your
IdP and AWS, ensuring that your cloud access management is not inside or dependent on your IdP.

Week 2
Compute as a Service on AWS

The first building block you need to host an application is a server. Servers often times can handle
Hypertext Transfer Protocol (HTTP) requests and send responses to clients following the client-
server model, though any API based communication also falls under this model.

These servers power your application by providing CPU, memory, and networking
capacity to process users’ requests and transform them into responses. For context,
common HTTP servers include:

 Windows options, such as Internet Information Services (IIS).

 Linux options, such as Apache HTTP Web Server, Nginx, and Apache Tomcat.

Choose the Right Compute Option

If you’re responsible for setting up servers on AWS to run your infrastructure, you have many
compute options. You need to know which service to use for which use case. At a fundamental level,
there are three types of compute options: virtual machines, container services, and serverless. If
you’re coming to AWS with prior infrastructure knowledge, a virtual machine can often be the
easiest compute option in AWS to understand. This is because a virtual machine emulates a physical
server and allows you to install an HTTP server to run your applications. To run these virtual
machines, you install a hypervisor on a host machine. This hypervisor provisions the resources to
create and run your virtual machines. In AWS, these virtual machines are called Amazon Elastic
Compute Cloud or Amazon EC2. Behind the scenes, AWS operates and manages the host machines
and the hypervisor layer. AWS also installs the virtual machine operating system, called the guest
operating system. Some AWS compute services use Amazon EC2 or use virtualization concepts under
the hood, therefore it is best to understand this service first before moving on to container services
and serverless compute.

Introduction to Amazon Elastic Compute Cloud

Amazon EC2 is a web service that provides secure, resizable compute capacity in the cloud. It allows
you to provision virtual servers called EC2 instances. Although AWS uses the phrase “web service” to
describe it, it doesn’t mean that you are limited to running just web servers on your EC2 instances.

You can create and manage these instances through the AWS Management Console, the AWS
Command Line Interface (CLI), AWS Software Development Kits (SDKs), or through automation tools
and infrastructure orchestration services.
In order to create an EC2 instance, you need to define:

Hardware specifications, like CPU, memory, network, and storage.

Logical configurations, like networking location, firewall rules, authentication, and the operating
system of your choice. When launching an EC2 instance, the first setting you configure is which
operating system you want by selecting an Amazon Machine Image (AMI).

What Is an AMI?
In the traditional infrastructure world, the process of spinning up a server consists of installing an
operating system from installation disks, installation drives, or installation wizards over the network. In
the AWS Cloud, this operating system installation is no longer your responsibility, and is instead built
into the AMI that you choose.

Not only does an AMI let you configure which operating system you want, you can also select storage
mappings, the architecture type (such as 32-bit, 64-bit, or 64-bit ARM), and additional software
installed.

What Is the Relationship Between AMIs and EC2 Instances?

EC2 instances are live instantiations of what is defined in an AMI, much like a cake is a live instantiation
of a cake recipe. If you are familiar with software development, you can also see this kind of
relationship between a Class and an Object.
A Class is something you model and define, while an object is something you interact with. In this case,
the AMI is how you model and define your instance, while the EC2 instance is the entity you interact
with, where you can install your web server, and serve your content to users.

When you launch a new instance, AWS allocates a virtual machine that runs on a hypervisor. Then the
AMI you selected is copied to the root device volume, which contains the image used to boot the
volume. In the end, you get a server you can connect to and install packages and any additional
software. In this case, you install a web server along with the properly configured source code of your
employee directory app.
One advantage of using AMIs is that they are reusable.

Amazon EC2 Instance Lifecycle

Your instance sizing will depend on both the demands of your application and the anticipated size
of your user base.

What Makes Up an EC2 Instance?

EC2 instances are a combination of virtual processors (vCPUs), memory, network, and in
some cases, instance storage and graphics processing units (GPUs). When you create an
EC2 instance, you need to choose how much you need of each of these components.

AWS offers a variety of instances that differ based on performance. Some instances
provide you with more capacity and others provide less. To get an overview of the
capacity details for a particular instance, you should look at the instance type. Instance
types consist of a prefix identifying the type of workloads they’re optimized for, followed
by a size. For example, the instance type c5.large can be broken down into the following
elements.

 c5 determines the instance family and generation number. Here, the instance
belongs to the fifth generation of instances in an instance family that’s
optimized for generic computation.
 large, which determines the amount of instance capacity.

What Are Instance Families?

Instance
Description Use Cases
Family

General Provides a balance of compute, memory, Scale-out workloads such as web

 Instance
Description Use Cases
Family
servers, containerized
and networking resources, and can be microservices, caching fleets,
purpose
used for a variety of workloads. distributed data stores, and
development environments.
High-performance web servers,
scientific modeling, batch
Ideal for compute-bound applications processing, distributed analytics,
Compute
that benefit from high-performance high-performance computing
optimized
processors. (HPC), machine/deep learning, ad
serving, highly scalable
multiplayer gaming.
Memory-intensive applications
such as high-performance
Designed to deliver fast performance for databases, distributed web-scale
Memory
workloads that process large data sets in in-memory caches, mid-size in-
optimized
memory. memory databases, real-time big-
data analytics, and other
enterprise applications.
Use hardware accelerators or co-
3D visualizations, graphics-
processors to perform functions such as
intensive remote workstations, 3D
Accelerated floating-point number calculations,
rendering, application streaming,
computing graphics processing, or data pattern
video encoding, and other server-
matching more efficiently than is
side graphics workloads.
possible with conventional CPUs.
Designed for workloads that require
high, sequential read and write access to NoSQL databases, such as
large data sets on local storage. They are Cassandra, MongoDB, and Redis,
Storage optimized to deliver tens of thousands of in-memory databases, scale-out
optimized low-latency random I/O operations per transactional databases, data
second (IOPS) to applications that warehousing, Elasticsearch, and
replicate their data across different analytics.
instances.

Where Does Your EC2 Instance Live?

By default, your EC2 instances are placed in a network called the default Amazon Virtual
Private Cloud (VPC). This network was created so that you can easily get started with
Amazon EC2 without having to learn how to create and configure a VPC. Any resource you
put inside the default VPC will be public and accessible by the internet, so you shouldn’t
place any customer data or private information inside of it. Once you get more
comfortable with networking on AWS, you should change this default setting to choose
your own custom VPCs and restrict access with additional routing and connectivity
mechanisms.

Architect for High Availability

Inside this network, your instance resides in an Availability Zone of your choice. As you
learned in AWS Cloud, AWS services that are scoped at the Availability Zone level must be
architected with high availability in mind. While EC2 instances are typically reliable, two is
better than one, and three is better than two. Specifying the instance size gives you an
advantage when designing your architecture because you can use more smaller instances
instead of a few larger ones. If your frontend only has a single instance and that instance
fails, your application goes down. On the other hand, if your workload is distributed
across 10 instances and one fails, you lose only 10 percent of your fleet and your
application availability is hardly affected. When architecting any application for high
availability, consider using at least two EC2 instances in two separate Availability Zones.
When you launch an instance, it enters the pending state (1). When the instance is
pending, billing has not started. At this stage, the instance is preparing to enter the
running state. Pending is where AWS performs all actions needed to set up an instance,
such as copying the AMI content to the root device and allocating the necessary
networking components. When your instance is running (2), it's ready to use. This is also
the stage where billing begins. As soon as an instance is running, you are then able to take
other actions on the instance, such as reboot, terminate, stop, and stop-hibernate. When
you reboot an instance (3), it’s different than performing a stop action and then a start
action. Rebooting an instance is equivalent to rebooting an operating system. The
instance remains on the same host computer and maintains its public and private IP
address, and any data on its instance store. It typically takes a few minutes for the reboot
to complete. When you stop and start an instance (4), your instance may be placed on a
new underlying physical server. Therefore, you lose any data on the instance store that
were on the previous host computer. When you stop an instance, the instance gets a new
public IP address but maintains the same private IP address. When you terminate an
instance (5), the instance store are erased, and you lose both the public IP address and
private IP address of the machine. Termination of an instance means you can no longer
access the machine.
hat Are the EC2 Pricing Options?

One of the ways to reduce costs with Amazon EC2 is to choose the right pricing option for
the way your applications run. There are three main purchasing options for EC2 instances:
on-demand, reserved, and spot instances.

Pay As You Go with On-Demand Instances

With On-Demand instances, you pay for compute capacity with no long-term
commitments. Billing begins whenever the instance is running, and billing stops when the
instance is in a stopped or terminated state. The price per second for a running On-
Demand instance is fixed. For applications that require servers to be running all the time,
you are less likely to benefit from the On-Demand pricing model, simply because there is
no situation where you will need to turn servers off. For example, you might want the web
server hosting the frontend of your corporate directory application to be running 24/7 so
that users can access the website at any time. Even if there are no users connected to your
website, you don’t want to shut down the servers supporting the site in case of potential
user activity. In the case when servers cannot be stopped, consider using a Reserved
Instance to save on costs.

Reserve Capacity with Reserved Instances (RIs)

RIs provide you with a significant discount compared to On-Demand instance pricing. RIs
provide a discounted hourly rate and an optional capacity reservation for EC2 instances.
You can choose between three payment options: All Upfront, Partial Upfront, or No
Upfront. You can select either a 1-year or 3-year term for each of these options. Depending
on which option you choose, you are discounted differently.

 All Upfront offers a higher discount than Partial Upfront instances.

 Partial Upfront instances offer a higher discount than No Upfront.
 No Upfront offers a higher discount than On-Demand.
On-Demand and No Upfront are similar since both do not require any upfront payment.
However, there is a major difference. When you choose an On-Demand instance, you stop
paying for the instance when you stop or terminate the instance. When you stop an RI, you
still pay for it because you committed to a 1-year or 3-year term. Reserved Instances are
associated with an instance type and an Availability Zone depending on how you reserve
it. The discount applied by a Reserved Instance purchase is not directly associated with a
specific instance ID, but with an instance type.

Save on Costs with Spot Instances

Another way of paying for EC2 instances is by using Spot Instances. Amazon EC2 Spot
Instances allow you to take advantage of unused EC2 capacity in the AWS Cloud. They are
available at up to a 90% discount compared to On-Demand prices. With Spot Instances,
you set a limit on how much you would like to pay for the instance hour. This is compared
against the current Spot price that AWS determines. If the amount you pay is more than
the current Spot price and there is capacity, then you will receive an instance. While they
are very promising from the billing perspective, there are some architectural
considerations you will need to consider in order to use them effectively. One
consideration is that your spot instance may be interrupted. For example, if AWS
determines that capacity is no longer available for a particular spot instance or if the Spot
price exceeds how much you are willing to pay, AWS will give you a 2-minute warning
before it interrupts your instance. That means any application or workload that runs on a
Spot instance must be able to be interrupted. Because of this unique consideration,
inherently fault-tolerant workloads are typically good candidates to use with Spot
instances. These include big data, containerized workloads, continuous
integration/continuous delivery (CI/CD), web servers, high-performance computing (HPC),
image and media rendering, or other test and development workloads.

Reading 2.3: Container Services on AWS

AWS offers a broad spectrum of compute offerings that give you the flexibility to choose
the right tool for the right job. The three main categories of compute are virtual machines,
containers, and serverless. There is no one-size-fits-all service because it depends on your
needs. The key is to understand what each option has to offer in order to build a more
appropriate cloud architecture for your use case. In this unit, you learn about containers
and how to run them on AWS. Containers can host a variety of different workloads,
including web applications, lift and shift migrations, distributed applications, and
streamlining of development, test, and production environments.

What Is a Container?

While containers are often referred to as a new technology, the idea started in the 1970s
with certain Linux kernels having the ability to separate their processes through isolation.
At the time, this was configured manually, making operations complex. With the evolution
of the open source software community, containers evolved. Today, containers are used
as a solution to problems of traditional compute, including the issue of getting software to
run reliably when it moves from one compute environment to another. A container is a
standardized unit that packages up your code and all of its dependencies. This package is
designed to run reliably on any platform, because the container creates its own
independent environment. This makes it easy to carry workloads from one place to
another, such as from development to production or from on-premises to the cloud.

What Is Docker?

When you hear the word container, you may associate it with Docker. Docker is a popular
container runtime that simplifies the management of the entire operating system stack
needed for container isolation, including networking and storage. Docker makes it easy to
create, package, deploy, and run containers.

What Is the Difference Between Containers and VMs?

Containers share the same operating system and kernel as the host they exist on, whereas
virtual machines contain their operating system. Since each virtual machine has to
maintain a copy of an operating system, there’s a degree of wasted space. A container is
more lightweight. They spin up quicker, almost instantly. This difference in startup time
becomes instrumental when designing applications that need to scale quickly during
input/output (I/O) bursts. While containers can provide speed, virtual machines offer you
the full strength of an operating system and offer more resources, like package
installation, a dedicated kernel, and more.

Orchestrate Containers

In AWS, containers run on EC2 instances. For example, you may have a large instance and
run a few containers on that instance. While running one instance is easy to manage, it
lacks high availability and scalability. Most companies and organizations run many
containers on many EC2 instances across several Availability Zones. If you’re trying to
manage your compute at a large scale, you need to know:

 How to place your containers on your instances.

 What happens if your container fails.
 What happens if your instance fails.
 How to monitor deployments of your containers.
This coordination is handled by a container orchestration service. AWS offers two
container orchestration services: Amazon Elastic Container Service (ECS) and Amazon
Elastic Kubernetes Service (EKS).

Manage Containers with Amazon Elastic Container Service (Amazon ECS)

Amazon ECS is an end-to-end container orchestration service that allows you to quickly
spin up new containers and manage them across a cluster of EC2 instances.

To run and manage your containers, you need to install the Amazon ECS Container Agent
on your EC2 instances. This agent is open source and responsible for communicating back
to the Amazon ECS service about cluster management details. You can run this agent on
both Linux and Windows AMIs. An instance with the container agent installed is often
called a container instance.

Once the Amazon ECS container instances are up and running, you can perform actions
that include, but are not limited to, launching and stopping containers, getting cluster
state, scaling in and out, scheduling the placement of containers across your cluster,
assigning permissions, and meeting availability requirements. To prepare your
application to run on Amazon ECS, you create a task definition. The task definition is a text
file, in JSON format, that describes one or more containers. A task definition is similar to a
blueprint that describes the resources you need to run that container, such as CPU,
memory, ports, images, storage, and networking information. Here is a simple task
definition that you can use for your corporate director application. In this example, the
runs on the Nginx web server. { "family": "webserver", "containerDefinitions": [ { "name":
"web", "image": "nginx", "memory": "100", "cpu": "99" } ], "requiresCompatibilities":
[ "FARGATE" ], "networkMode": "awsvpc", "memory": "512", "cpu": "256" }

Use Kubernetes with Amazon Elastic Kubernetes Service (Amazon EKS)

Kubernetes is a portable, extensible, open source platform for managing containerized

workloads and services. By bringing software development and operations together by
design, Kubernetes created a rapidly growing ecosystem that is very popular and well
established in the market. If you already use Kubernetes, you can use Amazon EKS to
orchestrate these workloads in the AWS Cloud. Amazon EKS is conceptually similar to
Amazon ECS, but there are some differences.

 An EC2 instance with the ECS Agent installed and configured is called a
container instance. In Amazon EKS, it is called a worker node.
 An ECS Container is called a task. In the Amazon EKS ecosystem, it is called a
pod.
  While Amazon ECS runs on AWS native technology, Amazon EKS runs on top of
Kubernetes.
If you have containers running on Kubernetes and want an advanced orchestration
solution that can provide simplicity, high availability, and fine-grained control over your
infrastructure, Amazon EKS is the tool for you.

Arch.
Security

1. Network Acl
2. Security Group

Network Acl

Pink line- like a firewall around subnets control traffic ( what traffic will enter and leave)

Security group- around EC

Database layout

Dynamo DB