What is Cloud Computing?

In the past we had on premise servers. These servers would sit in a datacentre, the issue with
the on-premises servers is that they require maintenance, they cannot scale, and they require a
lot of work.

We can replace on-premises servers with cloud server. The cloud servers allow us to have on-
demand delivery of computing power, DB storage, apps, and more. This means that we pay
as we go and pay only for what we’ve asked for.
We can create an identical server of what we have on-prem, we can adjust the amount of CPU
cores, the amount of RAM, and so on. We will get the cloud server instantly. As we can
access everything through an interface.

We have 3 types of clouds:

1. Private cloud:
This cloud allows complete control over the resources, but its private and used within
a single organization and its not exposed to the public. It’s used to secure sensitive
apps.
2. Public cloud:
this cloud is owed and operated by 3rd party cloud service and provided over the
internet. (AWS, GCP and Azure are examples of public clouds)
3. Hybrid cloud:
this cloud is a combination of on-prem servers and services from the cloud, which
allows control over sensitive assets in the private infra.

Advantages of using cloud computing:

1. On-demand self service – use resources without human interaction from the provider.
2. Broad network access – resources can be accesses over the network, and by different
client platforms.
3. Multi-tenancy and resource pooling – the physical server are accesses by everyone,
but each infra is secure and private.
4. Rapid elasticity and scalability – scale on demand and dispose resources when
needed.
5. Measured service – usage is measured, and we pay per what we have used.

Advantages of cloud computing:

1. Trade capital expenses for operational expenses – we pay for what we use, we don’t
need hardware, we just rent it from AWS.
2. Benefit from massive economies of scale.
3. Stop guessing capacity – since we know how much we need, there is no need to
guess.
4. Increased speed and agility.
5. No money spent on running and maintaining data centres.
6. Go global in minutes.
Types of cloud computing:

 Infra as a service (IAAS) – networks, computers, DB. (EC2)

 Platform as a service (PAAS) – no need to manage infra, focus on deployment and
management of apps. (Elastic Beanstalk)
 Software as a service (SAAS) – product that is run by the service provider. (Gmail,
Dropbox, Zoom)

When we use on-prem servers, we have control over everything.

Then, if we us IAAS, then we have control over apps, data, runtime, middleware and
networks, computers and DB are run by AWS.
When we use PAAS, then we have control over the data and the apps, because we only
deploy, all other things are taken care by AWS.
If we use SAAS then everything is controlled over AWS.

Fundamental pricing on the cloud:

 Compute – pay per compute time.

 Storage – pay per how much data you store in AWS.
 Data transfer OUT of the cloud.

Aws Cloud:

AWS cloud infra is built using different regions, and the region spread is global.
A region is a cluster of datacenters.

How to choose a region for our application:

 Compliance – maybe our government has legal requirements which we must fulfill.
 Proximity – we want to choose our server close to our customers, to avoid latency.
 Not all services are available over all the regions.
 Pricing is different in each region.

AWS availability zones – these zones are what create a region.

Each region has at least 3 AZ. For example, the region ap-southeast-2 has 3 AZ:
ap-southeast-2a, ap-southeast-2b, ap-southeast-2c.
Each AZ is one or more discrete data center with redundant power, networking and
connectivity.
Each AZ is separate from the others, so they are isolated in a case of disaster.
The AZs relate to high bandwidth and ultra low latency networking.

AWS points of presence (Edge Locations) – These allow to deliver content to users with
low latency.
IAM – Identity and Access Management
Introduction
The IAM is a global service, in this service, we can create users and assign them to groups.
When we first created our AWS account,we created a root account, the root account is created
by default, and it should not be used and shared.
What we should do is to create users and assign them into groups.
Groups can contain only users, and not groups.
Note that a user doesn’t have to be assigned into a group, and a user can be assigned into
multiple groups.

In IAM we can set permissions to different groups/users. To set for a user/group a permission
we need to create a JSON file called policy.
In AWS we want to give users and groups the least number of permissions needed.

When we create users, we can connect to AWS through root or through the IAM user that we
have created.
IAM Policies
We can create policies and attach them to groups; these policies declare what permission the
users will have.
So, if we create a policy to a group, all users that belong to that group will inherit that policy
permissions.
If a user doesn’t belong to group, it can still inherit from a policy (inline policy)

IAM Policies Structure:

Consists of
• Version: policy language version, always include “2012-10-17”
• Id: an identifier for the policy (optional)
• Statement: one or more individual statements (required)
Statements consists of
• Sid: an identifier for the statement (optional)
• Effect: whether the statement allows or denies access (Allow, Deny)
• Principal: account/user/role to which this policy applied to
• Action: list of actions this policy allows or denies
• Resource: list of resources to which the actions applied to
• Condition: conditions for when this policy is in effect (optional)
IAM MFA
To protect users in AWS, we can define 2 mechanisms:
1. Create a password policy:
The password policy can set a minimum password length, to require specific chars, to
allow IAM users to change their own password, to require changing the password
after some time, to prevent password re-use, and so on.
2. MFA – Multi Factor Auth:
users have access to our AWS account and can change configs or delete resources.
Thats why we must protect our root and IAM users.
MFA is the combination of a password + security device that we own.

The main benefit of using MFA is if the password is stolen or hacked, the account is not
compromised, since the hacker also need the device to log in.

MFA devices options:

 Google auth (for phone only)
 Authy (support for multiple tokens on a single device)
 Universal 2nd Factor (U2F) Security Key – a physical device that can hold different
tokens.
 Hardware Key Fob MFA Device – provided by Gemalto.
 Hardware Key Fob MFA Device for AWS GovCloud (US)
AWS Access Keys, CLI, and SDK
There are 3 options to login into an AWS account:
 AWS Management Console (protected by password + MFA. This is how we
connected until now)
 AWS Command Line Interface (CLI) – protected by access keys.
 AWS Software Developer Kit (SDK) – protected by access keys.

Access Keys are generated through the AWS console.

The keys are like passwords.

The AWS CLI is a CLI that allows us to interact with AWS services through the command
line.
In this CLI each command starts with the word keyword aws.

The AWS SDK is a software development kit, that is language-specific API, and it enables
access and management to AWS services through code. It is Embedded in the app, and
supports different programming languages, mobiles SDK, and IoT devices SDK.

To create Access Keys, we are going to the user, security credentials, and then create access
keys.
This will allow us to connect through a CLI with our credentials.
To configure the access keys on the cli run: aws configure

We can also use AWS CloudShell instead of using the CLI.

We can specify where to run each command using - - region
we can also download and upload files to the CloudShell.

IAM Roles for Services

Some AWS services will need to perform actions on our behalf.
To do so, we will need to assign permissions to AWS services so they can perform these
actions.
We will assign the AWS services IAM ROLES.
We can set roles for ec2 instances, lambda functions, and CloudFormation.

When we create a role for a service we need to set a policy.

IAM Security Tools
 IAM Credentials Report (At the account level):
This is a report that will list all the account’s users and the status of their credentials.

 IAM Access Advisor (At the user level):

This tool will show the service permissions granted to a user and when those services
were last accessed.
We can use this information to revise user policies, since if a user didn’t user a
permission for a long time, we can remove the permission.

Shared Responsibility Model For IAM

AWS is responsible for:
1. The infra, and the global network security.
2. Configuration and vulnerability analysis.
3. Compliance validation.

The user is responsible for:

1. The creation of users, groups, roles, policies management and monitoring.
2. The enablement of MFA on all accounts.
3. The rotations of all keys.
4. The use of IAM tools to apply the needed permissions.
5. The analysis of patterns and review of permissions.

So, in other words, AWS is responsible for the infra, and we are responsible of how we use
the infra.

To summarize:
IAM role – role for a service that will use AWS.
IAM user – user created to use AWS with permissions.
IAM policy – a JSON file containing permissions.
EC2 – Elastic Compute Cloud
 NOTE – We will want to create a budget, since we don’t want to spend money on
AWS services.

EC2 Basics
EC2 is an Elastic Compute Cloud service, which is user as Infra As a Service (IAAS).
Through EC2 We can:
 Rent VMs (EC2 instances)
 Store data on Vdrives (EBS)
 Distribute load across machines (ELB)
 Scale services using auto scaling group (ASG)

EC2 Sizing and Configurations options:

 Which OS to us: Linux, windows, MAC OS.

 How much compute power and cores to use (CPU).
 How much random-access memory we can have (RAM).
 How much storage space to use:
In either Network attached (EBS and EFS).
Or hardware attached (EC2 Instance Store).
 Network card – the speed of the card and what public IP we will use.
 The firewall rules – security group.
 The bootstrap script (configure at first launch) – EC2 User Data.

EC2 User Data:

We can configure our EC2 instances to boot using a script.

This action is called bootstrapping and will launch commands when the machine starts.
This script will run only one at the start of the instance.
When we use this script, we would usually want to:
 Install updates.
 Install software.
 Download common files.
Note that the script will run using root user, and as long the script is, the longer time it will
take for the instance to load.

AMI = Amazon Machine Image

EC2 Instance Types
We can use different types of EC2 instances depending on the use case.
We have:
 General purpose:
Great for diversity of workloads such as webservers or code repositories.
It is balanced between compute, memory and networking.
 Compute optimized:
Great for compute intensive tasks that require high performance processors, such as:
batch processing workloads, media transcoding, high performance web servers, high
performance computing (HPC), ML, dedicated gaming servers.
Instances that under this type are starting with the letter C.
 Memory optimized:
Fast performance for workloads that process large data sets in memory (RAM).
Used for:
High performance, relational/non-relational databases. Distributed web scale cache
stores. In-memory databases optimized for BI (business intelligence). Applications
performing real-time processing of big unstructured data
Instances that under this type are starting with the letter R.
 Accelerated computing
 Storage optimized:
Great for storage-intensive tasks that require high, sequential read and write
access to large data sets on local storage.
used for:
High frequency online transaction processing (OLTP) systems. Relational & NoSQL
databases. Cache for in-memory databases (for example, Redis). Data warehousing
applications. Distributed file systems
 HPC optimized
 Instance features
 Measuring instance performance.

Naming Convention:

M5.2XLarge
M: instance class
5: generation
2XLARGE – size within the class.
Security Groups and Classic Ports
Security groups are the fundamental of network security in AWS.
The security groups are like firewalls, but only contains allow rules.
The security groups can reference by IP or by security group.

If create an EC2 instance, we can set what traffic will be able to go inbound (To the EC2),
and what traffic the EC2 can send to the internet (Outbound traffic).
The security groups can also regulate access to different ports of the instance and the IP
ranges.

The security groups can be attached to multiple instances, it is also locked down to a region /
VPC combination and does live “outside” the EC2 – so if traffic is blocked the EC2 instance
won’t see it.

It’s good to maintain one separate security group for SSH access.

If your application is not accessible (time out), then it’s a security group issue.
(a timeout is when the browser keep on trying to connect the instance)
If your application gives a “connection refused“ error, then it’s an application
error or it’s not launched.

By default:
• All inbound traffic is blocked.
• All outbound traffic is authorised.

If we would set an instance (1) with a security group that authorises 2 other security groups,
then when we initialize instances (2, 3) from the authorised security groups then the instances
(2,3) can access instance (1).

Important Ports:
• 22 = SSH (Secure Shell) - log into a Linux instance
• 21 = FTP (File Transfer Protocol) – upload files into a file share
• 22 = SFTP (Secure File Transfer Protocol) – upload files using SSH
• 80 = HTTP – access unsecured websites
• 443 = HTTPS – access secured websites
• 3389 = RDP (Remote Desktop Protocol) – log into a Windows instance
SSH
To connect to our EC2 instance machine, we need the SSH protocol to connect into it.
We can connect also via putty, or via EC2 Instance Connect, which only works on Amazon
Linux AMI (AMI = Amazon Machine Image).

To connect at Linux or windows:

Ssh -i KeyPairFile.pem ec2-user@PUBLIC_IPV4_ADDRESS

EC2 Instance Roles

To let the EC2 instance run command and get API calls by our name we need to do:
aws configure
BUT, THIS IS VERY DANGEROUS SINCE WE ADD OUR LOGIN AND PASSWORD
AND THEN SOMEONE CAN USE THE EC2 INSTANCE IN OUR NAME.
Instead, we must create a role and give it to the EC2 instance, so the instance can have the
least number of permissions.
To add a role to an EC2 instance, go to actions, security, modify IAM role.

EC2 Instances Purchasing Options

• On-Demand Instances – short workload, predictable pricing, pay by second
• Reserved (1 & 3 years):
 Reserved Instances – long workloads (up to 72% discount) – will allow you to set
instance type, tenancy, region, OS, and so on.
 Convertible Reserved Instances – long workloads with flexible instances (up to 66%
discount) – will allow you to change the instance type, OS, and so on.
• Savings Plans (1 & 3 years) –commitment to an amount of usage, long workload –
commit to a certain type of usage, after the use of the usage, the paying will be on demand.
• Spot Instances – short workloads, cheap, can lose instances (less reliable) – the most cost-
efficient instances, useful for workloads that resilient to failure, and not suitable for critical
jobs or databases, since the instance can be lost.
• Dedicated Hosts – book an entire physical server, control instance placement – the most
expensive option.
• Dedicated Instances – no other customers will share your hardware – the hardware is
yours for the instance.
• Capacity Reservations – reserve capacity in a specific AZ for any duration – reserve on-
demand instances capacity in an AZ. No time commitment and no billing discount. You will
pay if you use or won’t use the instances.
Shared Responsibility Model for EC2
AWS is responsible for:
 the infra
 the isolation on physical hosts
 replacement of faulty hardware
 compliance validation.

The User should:

 Security group rules – who will access the instance
 OS patches and updates – you must update the OS.
 Software and Utils installed – must be updated manually.
 IAM Roles assigned to EC2 and IAM user access management
 Data security on your instance.

To summarize:

EC2 User Data – script that runs only 1 time when we create the instance.
Security Group – like a firewall that states what will go in and out.
EC2 Instance Role – Link to IAM roles, and what permissions that EC2 has.
EC2 Instance Storage
EBS Volume
An EBS (Elastic Block Store) Volume is a network drive you can attach to your instances
while they run.

It allows instances to persist data, even after their termination. Which means that if we
would terminate an instance and have an EBS, we would still be able to move the data to
another instance, and the data would persist.

They can only be mounted to one instance at a time. And they are bound to a specific AZ. We
can think of them as a “network USB stick”.

Note that an EBS is a network drive and not a physical drive, so it uses the network to
communicate to the instance which could result in a bit of latency.
To move a volume across, we need to snapshot it. Also, we must provision the capacity.
(the configuration needs to be the size and the i/o operations/sec)

We can have instance with few EBS’s but, only 1 EBS connected to an instance.
Also, we can create an EBS but leave him unattached.

Delete on Termination attribute:

When we create an instance, it will have a root EBS attached to it. We can also attach more
EBS to the instance.
The delete on termination attribute controls the EBS behaviour when an EC2 instance is
terminated.
By default, the root EBS (which is created when we create the instance), is deleted – the
attribute is enabled.
By default, any other attached EBS volume is not deleted – the attribute is disabled.
This can be controlled by the AWS console / AWS CLI.
The use case for this can be to preserve the root volume when the instance is terminated, to
persist data.

 Note that if we add an EBC volume, we also need to mount it to the instance.
EBS Snapshot
A snapshot is a backup of the EBS volume, which can be created at any point in time.
It is recommended to detach a volume and then take a snapshot, but we can also take a
snapshot without detaching.
We can copy snapshots across AZ or region.

EBS Snapshots Features:

 EBS Snapshot Archive – this moves the snapshot to an “archive tier” which is 75%
cheaper.
The downside in this feature that although it is cheaper it takes between 24-72 hours
to restore a snapshot from the archive.
 Recycle Bin for EBS Snapshots – this sets up rules to save a deleted snapshot, the
snapshot will be saved between 1 day to 1 year depending on the rules set.

AMI
The AMI is an Amazon Machine Image.

The AMI is a customization of an EC2 instance, and can include software, configs, OS,
monitoring tools and so on. It allows faster boot time since all the software is already pre-
packed.

The AMI is built for a specific region, but then can be copied across regions.

We can launch EC2 instance from:

 A public AMI – which is provided by AWS.
 Own AMI – which we can make and maintain.
 An AWS Marketplace AMI – which is an AMI someone else made and can sell.

To create an AMI and use it:

1. Start an EC2 instance and customize it.
2. Stop the instance.
3. Build the AMI (note that there will be also an EBS snapshots)
4. Launch instances from that AMI.
Note that if we create instances and add User Data, the new User Data won’t override the
existing User Data from the AMI but will be appended.
EC2 Image Builder
This service is used to automate the creation of VM or container images.
Also, it can automate the creation, maintain, validate and test EC2 AMIs.

Working Process of EC2 Image Builder:

1. The EC2 Image Builder is going to create a Builder EC2 Instance.
2. The EC2 instance is going to build components (like software, updates)
3. Then the EC2 Image Builder is going to create a new AMI.
4. To test the AMI a Test EC2 Instance is created. And different tests are run (does the
AMI working, is it secure?)
5. After the tests are completed, the AMI is distributed.
We can also set a schedule (weekly, or when a package gets an update, or manually)

EC2 Instance Store – Physical drive

The EBS volumes are network drives, that are good, but have “limited” performance. Since
we use network, it can cause some latency.
Thats why if we need a high-performance hardware disk, we can use EC2 Instance Store.
That store is physical, because we don’t use network, and the disk is physical, the
performance is better.

The EC2 Instance Store attributes:

 Better I/O performance.
 Can lose their storage if the Instance is stopped.
 Good for buffer / cache / scratch data / temporary content.
 There is a risk to lose the data if the hardware fails in the AZ/Region.
 There is a need to backup and create replications.
EFS – Shared network file system
An EFS (Elastic File System) is a managed NFS (network file system), that can be mounted
on 100s of EC2.
This makes EFS a shared network file system.

EFS works with Linux EC2 in multiple-AZ.

The EFS is highly available, scalable, expensive, where you pay per use, and not per total
capacity, since there is no capacity planning.

EBS VS EFS:

 EBS Is available only in one AZ. Where EFS is available in multiple AZ at the same
time.

EFS Infrequent Access (EFS-IA): Move unused files to cheaper storage class.

This is a storage class that is cost-optimized for files that are not accessed everyday.
It gives up to 92% lower cost compared to standard EFS.

When we use EFS-IA, the EFS will move the files to EFS-IA based on the last time they were
accessed.

To enable EFS-IA we need a lifecycle policy, we can declare to EFS-IA to move files that are
not accessed for the last X days to EFS-IA

While using EC2 Storage:

AWS is responsible for:

 The infra
 The replication for data for EBS volumes and EFS drives (in case some hardware
dies, we will no be impacted)
 Replacing faulty hardware.
 Ensuring their employees cannot access your data.
We are responsible for:
 Creating snapshots / backups to not lose data.
 Set up data encryption.
 Any data of the drives.
 Understanding the risk of using EC2 instance store, since we can lose the data.
Amazon FSx
This is a launch 3rd party high-performance file system on AWS. Which is fully managed.
Under Amazon FSX we have:
 FSX for Lustre
 FSX For windows file server
 FSX for NetApp ONTAP.

Amazon FSX for Windows File Server:

This is a fully managed, highly reliable and scalable Windows native shared filesystem,
which is built on windows file server.
This FSX supports SMB protocol and Windows NTFS. It is also integrated with Microsoft
active directory.
This allows connection from AWS or from on-prem infra.

This means that if we have 1 FSX on AZ1, and another FSX on AZ2, then we can connect to
the shared filesystem either from an instance or through SMB.

Amazon FSX for Lustre: (HPC)

This is a fully managed, high-performance, scalable file storage for High Performance
Computing (HPC).

The name Lustre is Linux + cluster.

Allows: ML, Analytics, Video processing, financial modelling and so on.

It scaled up to 100S GB/s, millions of IOPS, sub-MS latencies.

We can connect to this FSX either from a Linux server, or from EC2 instanced. Then, the data
is linked into an Amazon S3 Bucket.
ELB (Elastic Load Balancing) and ASG (Auto Scaling
Group)

High Availability, Scalability, Elasticity:

Scalability means that an application or a system can handle greater loads by adapting.
There are two kinds of scalability:
1. Vertical scalability - size
2. Horizontal scalability -size (which is also known as elasticity)
Scalability is linked but different to high availability.

Vertical scalability:

Vertical scalability means increasing the size of the instance.

So if we have an application that run on t2.micro, we can scale the application vertically and
run it on t2.large, which can operate much faster, and handle bigger processes.
Vertical scalability is very common for non-distributed systems, such as a database.
Theres usually a limit to how much we can vertically scale (since we increase the size we can
reach the limit in the hardware.

Horizontal scalability:

Horizontal scalability means increasing the number of instances / systems for an

application.
Horizontal scaling implies distributed systems.
This is very common for web apps / modern apps.
Its easy to horizontally scale, using EC2 and ASG.

High Availability: (redundancy)

High availability usually goes hand in hand with horizontal scaling (if we add more, we need
to be at more places).
This means that if we run an app / system, we need to run in at least 2 AZ.
The goal of this is to survive a data centre loss. (so, in case 1 falls, we have another running).

When we scale horizontally, we would use

 ASG
 Load Balancer.
When we want to create high availability, we would use:
 Auto Scaling Group in a multi-AZ mode.
 Load Balancer in a multi-AZ mode.

Scalability VS Elasticity VS Agility

Scalability: this is the ability to accommodate a larger load by making the hardware stronger
(scale up), or by adding nodes (scale out).

Elasticity: once a system is scalable, we need to add some “auto-scaling” to the system, so it
the scale will be based on the load. This is “cloud-friendly”, we pay per use, and we match
the demand so we can optimize the cost.

Agility: new IT resources are only a click away, which we can reduce time to make those
resources available to us, from weeks to just minutes.

Elastic Load Balancing (ELB)

A load balancer is a server that forwards internet traffic to multiple servers (EC2 Instances in
our case) downstream.
We will be publicly exposing the load balancer to the users.

We would want to use a load balancer because:

 It spreads load across multiple downstream instances.
 Exposes a single point of access (DNS) of our app.
 Handles failures of downstream instances (since the load balancer sits before the
instances, the user won’t know if an instance is down)
 Can do regular health checks on the instances.
 Provide SSL termination (HTTPS) for websites.
 High availability across zones.

An ELB (Elastic Load Balancer) is a manager load balancer.

AWS guarantees that it will be working, it also takes care of upgrades, maintenance, and its
high availability.
The ELB is easy to set with only few configs.

We can create our own load balancer, although it will cheaper, it will take more time and
effort to make, maintain, and integrate.

There are 3 kinds of load balancers:

1. ALB (Application Load Balancer) – HTTP or HTTPS only – layer 7. Here, the DNS
is static (as a URL)
2. NLB (Network Load Balancer) – ultra high performance, allows for TCP and UDP
balancing – layer 4. Here, the IP is static through Elastic IP.
3. GWLB (Gateway Load Balancer) – layer 3. Here, the protocol used is GENEVE on
IP packets.
We will want to use it if we want to route traffic to create a classic firewall, or
Intrusion detection, or analyse traffic.
here, the packets are sent to the GWLB, then, to a 3rd party security virtual appliance,
back to the GWLB, and then to the app.

ASG (Auto Scaling Group)

In real life, the load on websites and apps can change.
In the cloud, we can create and terminate servers quickly.
The goal of ASG is to:
  Scale out (add EC2) to match an increased load.
 Scale in (remove EC2) to match a decreased load.
 Ensure we have a minimum and maximum number of machines running.
 Register new instances to the load balancer (ELB and ASG work together).
 Replace unhealth instances we new ones and register them.
This saves us cost, since we run at the optimal capacity all the time.

When we create an ASG we can configure:

 Minimum size of instances.
 Actual size / desired capacity of instances.
 Maximum size of instances.
The ASG is capable of scaling in / out, depending on the load.

Auto Scaling Groups – Scaling Strategies

 Manual Scaling: Change desired amount.
 Dynamic Scaling: Respond to changing demand
Simple / Step Scaling:
When a CloudWatch alarm is triggered (CPU > 70%), add 2 units
When a CloudWatch alarm is triggered (CPU < 30%), remove 1 unit.
Target Tracking Scaling:
Setting the ASG CPU to stay around 40%, then the ASG can increase the number of
units, to reduce CPU usage, to decrease number of units to not use to many instances.
Scheduled Scaling:
Scale based on known patterns, like increase the capacity to 10 instances at 5pm on
Friday.
 Predictive Scaling: uses ML to predict future traffic, and automatically provision the
right number of instances in advance. It is useful when the load has predictable time-
based patterns.
Amazon S3
S3 Overview
Amazon S3 is one of the main building blocks of AWS and advertised as an “Infinitely
Scaling” Storage. Many websites use S3, and many AWS services uses S3 as an integration.

S3 is used for variety of things, from backup and storage to disaster recovery (in case a region
fails), to archive files. It is used in hybrid cloud storage, as application hosting platform, to
host media, and so in.

Buckets:

S3 stores objects (files) in “buckets” (directories).

Buckets must have a globally unique name (across all regions in all accounts).
Although s3 looks like a global service, the buckets are defined at the region level.
The buckets must have a naming convention1.

S3 Objects:

Objects (files) have a key, the key is the full path of the file:
S3://my-bucket-name/my_file.txt
If we nest a file under more files (not considered directories), then we have a prefix + the
object name:
S3://my-bucket-name/my_folder1/another_folder/my_file.txt

Objects have values, the values are the content of the body.
The value size is up to 5TB.
In case the value is greater then 5TB, then the “multi-part upload” option must be used.
The objects also have:
Metadata (key-value pairs of system or user metadata).
Tags (Unicode key-value pairs [up to 10]) – which is useful for security.
Version ID.

1
No uppercase, no underscores, not an up, must start with lowercase or number, not start with xn, not start end
with s3alias
S3 Security: Bucket Policy
Types of securities

 User Based Security:

This security is set using IAM policies – which defines which API calls should be
allowed for a specific user from IAM.
 Resource Based Security:
Bucker Polices – bucker wide rules from the S3 console – allows access from using
within the account or from other accounts (cross account permission).
Object Access Control List (ACL) – finer grain (can be disabled).
Bucket ACL – less common (can be disabled).

Note that an IAM user can access an S3 bucket if:

He has IAM permission ALLOWED OR, the resource policy ALLOWS him.
AND there’s no explicit DENY.

We can also encrypt object in Amazon S3 using encryption keys.

S3 Bucket Polices

The example below gives access to everyone to view all the objects in the bucket.

JSON based policies

• Resources: buckets and objects to allow / deny access to.
• Effect: Allow / Deny
• Actions: Set of API to Allow or Deny (what the action the user can do)
• Principal: The account or user to apply the policy to (in the example above – everyone – this
makes the bucket public)

Use S3 bucket for policy to:

• Grant public access to the bucket
• Force objects to be encrypted at upload
• Grant access to another account (Cross Account)

Bucket settings to Block Public Access

• These settings were created to prevent company data leaks

• If you know your bucket should never be public, leave these on
• Can be set at the account level

To allow public access to the bucket:

1. Go to bucket permissions.
2. Untick the Block public access.
3. Then add policies.

Amazon S3 – Static Website Hosting

S3 can host static websites and have them accessible on the internet.
The website URL will depend on the region.
If you get a 403 forbidden error, make sure the bucket policy allows public reads!
To allow Static Website Hosting:
1. Go to properties
2. Enable Static website hosting
3. Declare home page as index.html
4. Add index.html file
5. To access the site, copy the URL from the properties in the static website hosting.
Amazon S3 – Versioning
You can version your files in Amazon S3:
• It is enabled at the bucket level
• Same key overwrite will change the “version”: 1, 2, 3….
• It is best practice to version your buckets:
Protect against unintended deletes (ability to restore a version)
Easy roll back to previous version
• Notes:
Any file that is not versioned prior to enabling versioning will have version “null”
Suspending versioning does not delete the previous versions

Amazon S3 – Replication (CRR & SRR)

• Must enable Versioning in source and destination buckets
• Cross-Region Replication (CRR)
• Same-Region Replication (SRR)
• Buckets can be in different AWS accounts
• Copying is asynchronous
• Must give proper IAM permissions to S3

Use cases:
• CRR – compliance, lower latency access, replication across accounts
• SRR – log aggregation, live replication between production and test accounts

The creation of replication is done in management -> replication rules

This is done in the origin bucket, to target into the new bucket.
S3 Storage Classes
1. Amazon S3 Standard - General Purpose
2. Amazon S3 Standard-Infrequent Access (IA)
3. Amazon S3 One Zone-Infrequent Access
4. Amazon S3 Glacier Instant Retrieval
5. Amazon S3 Glacier Flexible Retrieval
6. Amazon S3 Glacier Deep Archive
7. Amazon S3 Intelligent Tiering

Note – we can move object through classes manually, or using S3 Lifecycle configs, which
moves the objects automatically.

S3 Durability and Availability:

Durability (how long objects is durable):

The objects in S3 are in high durability across multiple AZ (99.9% durable).
This means that if we store 10 million objects with S3, we can expect in average to loss a
single object once every 10000 years.

Availability (how long an object is available):

This is a measurement that tells how readily available a service is.
It varies depending on the storage class.
For an example, S3 standard has 99.99% availability – which means that it wont be available
for 53 minutes a year.

Amazon S3 Standard - General Purpose

• 99.99% Availability
• Used for frequently accessed data
• Low latency and high throughput
• Sustain 2 concurrent facility failures
• Use Cases: Big Data analytics, mobile & gaming applications, content
distribution…

Amazon S3 -Infrequent Access (IA)

• For data that is less frequently accessed, but requires rapid access when
needed
• Lower cost than S3 Standard

Amazon S3 Standard-Infrequent Access (S3 Standard-IA):

• 99.9% Availability
• Use cases: Disaster Recovery, backups

Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA):

• High durability (99.999999999%) in a single AZ; data lost when AZ is
destroyed
• 99.5% Availability
 • Use Cases: Storing secondary backup copies of on-premises data, or data you
can recreate

Amazon S3 Glacier Storage Classes

• Low-cost object storage meant for archiving / backup

• Pricing: price for storage + object retrieval cost

Amazon S3 Glacier Instant Retrieval:

• Millisecond retrieval, great for data accessed once a quarter
• Minimum storage duration of 90 days

Amazon S3 Glacier Flexible Retrieval (formerly Amazon S3 Glacier):

• we can get the data back in 3 types of times:
Expedited (1 to 5 minutes), Standard (3 to 5 hours), Bulk (5 to 12 hours) – free
• Minimum storage duration of 90 days

Amazon S3 Glacier Deep Archive – for long term storage:

 we can get the data back in two types of plans: Standard (12 hours), Bulk (48 hours)
 Minimum storage duration of 180 days

S3 Intelligent-Tiering
 Small monthly monitoring and auto-tiering fee
 Moves objects automatically between Access Tiers based on usage
 There are no retrieval charges in S3 Intelligent-Tiering

Frequent Access tier (automatic): default tier

Infrequent Access tier (automatic): objects not accessed for 30 days
Archive Instant Access tier (automatic): objects not accessed for 90 days
Archive Access tier (optional): configurable from 90 days to 700+ days
Deep Archive Access tier (optional): config. from 180 days to 700+ days

We can also move objects based on a Life Cycle rule, this rule will tell S3 to move objects
within a number of days to another tier.

S3 Encryption
Server-Side Encryption (default):

When the user uploads an object to the bucket, the bucket will encrypt the object after
receiving it.

Client-Side Encryption:

This encryption is done by the user before he uploads the object into the bucket.
IAM Access Analyzer for S3
This feature ensures that only intended people have access to the S3 bucket.
It works by analysing the bucket policy, the S3 ACLs, the S3 Access Point Polices and so on.
With this we can review permissions on our bucket.

Shared responsibility Model for S3

AWS is responsible for:
 the infra (durability, availability, global security, that it can sustain concurrent loss of
data in two facilities.)
 the configuration and vulnerability analysis.
 Compliance validation.

The user is responsible for:

• S3 Versioning
• S3 Bucket Policies
• S3 Replication Setup
• Logging and Monitoring
• S3 Storage Classes
• Data encryption at rest and in transit
AWS Snow Family
This is a highly secure, portable devices that are meant to collect and process data at the edge,
and to migrate data into and out of AWS.

The data migration is done using:

Snowcone, Snowball Edge, Snowmobile

The edge computing is done using:

Snowcon, Snowball Edge.

Data Migrations with AWS Snow Family

Transferring data over the internet takes time as the file size grows.
There are also different challenges to transfer data:
The connectivity can be limited, the bandwidth can be limited, the network cost is high, the
bandwidth is shared, the connection is not always stable.

All these reasons make a case to use Snow Family.

The AWS Snow Family are offline devices that perform data migrations.

This works by AWS sending to the client a physical device, which the client loads the data
into. Then, the user client ships the physical device back to an AWS facility. There, the data is
imported and then exported to an S3 bucket.

Snowball Edge (for data transfers)

Physical data transport solution: move TBs or PBs of data in or out of AWS
Alternative to moving data over the network (and paying network fees)
Pay per data transfer job
Provide block storage and Amazon S3-compatible object storage

• Snowball Edge Storage Optimized

• 80 TB of HDD or 210TB NVMe capacity for block volume and S3 compatible object
storage

• Snowball Edge Compute Optimized

• 42 TB of HDD or 28TB NVMe capacity for block volume and S3 compatible object storage

Use cases: large data cloud migrations, DC decommission, disaster

Recovery

AWS Snowcone & Snowcone SSD

Small, portable computing, anywhere, rugged & secure, withstands harsh environments
• Light (4.5 pounds, 2.1 kg)
Device used for edge computing, storage, and data transfer
• Snowcone – 8 TB of HDD Storage
• Snowcone SSD – 14 TB of SSD Storage
Use Snowcone where Snowball does not fit (space constrained environment)
Must provide your own battery / cables
Can be sent back to AWS offline, or connect it to internet and use AWS DataSync to send
data

AWS Snowmobile

Transfer exabytes of data (1 EB = 1,000 PB = 1,000,000 TBs)

Each Snowmobile has 100 PB of capacity (use multiple in parallel)
High security: temperature controlled, GPS, 24/7 video surveillance
Better than Snowball if you transfer more than 10 PB

Snow Family – Usage Proceess

1. Request Snowball devices from the AWS console for delivery

2. Install the snowball client / AWS OpsHub on your servers
3. Connect the snowball to your servers and copy files using the client
4. Ship back the device when you’re done (goes to the right AWS facility)
5. Data will be loaded into an S3 bucket
6. Snowball is completely wiped

What is Edge Computing

Process data while it’s being created on an edge location.

These locations may have, Limited / no internet access, or Limited / no easy access to
computing power.

We setup a Snowball Edge / Snowcone device to do edge computing

Use cases of Edge Computing:

• Preprocess data
• Machine learning at the edge
• Transcoding media streams

Eventually (if need be) we can ship back the device to AWS (for transferring data for
example)

Snow Family – Edge Computing

Snowcone & Snowcone SSD (smaller)

• 2 CPUs, 4 GB of memory, wired or wireless access
• USB-C power using a cord or the optional battery
Snowball Edge – Compute Optimized
• 104 vCPUs, 416 GiB of RAM
• Optional GPU (useful for video processing or machine learning)
• 28 TB NVMe or 42TB HDD usable storage
• Storage Clustering available (up to 16 nodes)

Snowball Edge – Storage Optimized

• Up to 40 vCPUs, 80 GiB of RAM, 80 TB storage
• Up to 104 vCPUs, 416 GiB of RAM, 210 TB NVMe storage

All: Can run EC2 Instances & AWS Lambda functions (using AWS IoT Greengrass)
Long-term deployment options: 1 and 3 years discounted pricing

AWS OpsHub

Historically, to use Snow Family devices, you needed a CLI (Command Line Interface tool)
Today, you can use AWS OpsHub (a software you install on your computer / laptop) to
manage your Snow Family Device
• Unlocking and configuring single or clustered devices
• Transferring files
• Launching and managing instances running on Snow Family Devices
• Monitor device metrics (storage capacity, active instances on your device)
• Launch compatible AWS services on your devices (ex: Amazon EC2 instances, AWS
DataSync, Network File System (NFS))

Snowball Edge Pricing

You pay for device usage and data transfer out of AWS
Data transfer IN to Amazon S3 is $0.00 per GB
On-Demand
Includes a one-time service fee per job, which includes:
• 10 days of usage for Snowball Edge Storage Optimized 80TB
• 15 days of usage for Snowball Edge Storage Optimized 210TB

Shipping days are NOT counted towards the included 10 or 15 days

Pay per day for any additional days
Committed Upfront
• Pay in advance for monthly, 1-year, and 3-years of usage (Edge Computing)
• Up to 62% discounted pricing
Storage Gateway
Hybrid Cloud for Storage

Aws is pushing for “hybrid cloud”, part of the infra is on premises, and part of the infra is on
the cloud.
This can be due to either long cloud migrations, security requirements, compliance
requirements, IT strategy.
S3 is a proprietary storage technology (unlike EFS/NFS), we can choose how to expose the
S3 data on premises.
We can do it using AWS Storage Gateway.

AWS Storage Cloud Native Optios

When we use blocks of storage it can be Amazon EBS, EC2 Instance Store.
When we use file to store data it can be Amazon EFS (as we store files)
When we use store objects, we can use Amazon S3 and S3 Glacier.

AWS Storage Gateway

When using AWS Storage Gateway, it bridges between on-prem data and cloud data in S3.
This hybrid storage service allows on-prem to use the AWS Cloud.
The use cases are:
Disaster recovery, backup and restore, tiered storage.

Summary
• Buckets vs Objects: global unique name, tied to a region
• S3 security: IAM policy, S3 Bucket Policy (public access), S3 Encryption
• S3 Websites: host a static website on Amazon S3
• S3 Versioning: multiple versions for files, prevent accidental deletes
• S3 Replication: same-region or cross-region, must enable versioning
• S3 Storage Classes: Standard, IA, 1Z-IA, Intelligent, Glacier (Instant, Flexible, Deep)
• Snow Family: import data onto S3 through a physical device, edge computing
• OpsHub: desktop application to manage Snow Family devices
• Storage Gateway: hybrid solution to extend on-premises storage to S3
Databases and Analytics
Databases Introduction
We can store data on disk (EFS, EBS, EC2 Instance Store, S3), but these can have limits.
Sometimes, we want to store the data in a DB.
In a DB we can structure the data, build indexes to query / search through the data in efficient
time, and to define relationships between datasets.
DBs are optimized for a purpose and come with different features, shapes and constrains.

Relational DB

This is like an Excel spreadsheet but with links.

We can define relation between columns and tables.
We can use SQL to perform queries.

NoSQL DB

This is a non relational DB.

These DBs are built for specific data models and have flexible schemas (the way to shape
data) to build modern apps.
Its benefits that its flexible, scalable, high-performance and highly functional.
This can be a key-value, document, graph, in-memory, search DB.

JSON NoSQL data example

Json is a JS Object Notation. And it is common form of data that fits into the NoSQL model.
The data can be nested, and the fields can change over time.
It supported types like arrays.

DB and Shared Responsibility on AWS

AWS can manage different DB for us.

The benefits of these can be:
 Quick Provisioning, High Availability, Vertical and Horizontal Scaling
 Automated Backup & Restore, Operations, Upgrades
 Operating System Patching is handled by AWS
 Monitoring, alerting

On the other hand, we can handle the DB on an EC2 instance, but we will need to handle
everything by our own.
RDS and Aurora Overview
RDS stands for Relational Database Service
It’s a managed DB service for DB use SQL as a query language.
It allows you to create databases in the cloud that are managed by AWS:
• Postgres
• MySQL
• MariaDB
• Oracle
• Microsoft SQL Server
• IBM DB2
• Aurora (AWS Proprietary database)

We should we use RDS instead of creating a DB on an EC2?

RDS is a managed service:

• Automated provisioning, OS patching
• Continuous backups and restore to specific timestamp (Point in Time Restore)!
• Monitoring dashboards
• Read replicas for improved read performance
• Multi AZ setup for DR (Disaster Recovery)
• Maintenance windows for upgrades
• Scaling capability (vertical and horizontal)
• Storage backed by EBS

BUT you can’t SSH into your instances

Amazon Aurora

Aurora is a proprietary technology from AWS (not open sourced)

PostgreSQL and MySQL are both supported as Aurora DB
Aurora is “AWS cloud optimized” and claims 5x performance improvement over MySQL on
RDS, over 3x the performance of Postgres on RDS
Aurora storage automatically grows in increments of 10GB, up to 128 TB
Aurora costs more than RDS (20% more) – but is more efficient
Not in the free tier

Amazon Aurora Serverless (not need to manage)

• Automated database instantiation and Client auto-scaling based on actual usage
• PostgreSQL and MySQL are both supported as Aurora Serverless DB
• No capacity planning needed
• Least management overhead
• Pay per second, can be more cost effective
• Use cases: good for infrequent, intermittent or unpredictable workloads…

The client connects to a Proxy Fleet that is managed by Aurora and the instances are created /
terminated depending on the usage, and they share the storage volume.
RDS Deployments Options:
Read Replicas, Multi-AZ
We can use Read Replicas to scale the read workload of the DB.
If we have a main DB that our application reads data from, we can add Read Replicas that
will distribute the reads and decrease the load on the main DB.
We can create up to 15 Read Replicas.
The data is only written to the main DB.

We can also use multi-AZ as a failover in case an AZ is in outage, this allows high
availability.
The data is only read and written to the main DB.
We can have only 1 AZ as a failover.

Multi Region

We can already create Read Replicas across different regions.

This is done to create a disaster recovery in case of a region issue.
If we have apps in different regions, they will read from the Replicas, and write cross region
to the main DB.
This allows local performance to be better since the read is from local Replica.
But the cost will increase since we need to replicate over different regions and pay for the
writing over cross regions.

ElastiCache Overview
ElastiCache used to get managed Redis or Memcached.
The caches are in-memory DB with high performance, and low latency.
This helps to reduce load off DB for read intensive workloads, since the data is written in-
memory, there is no need to read from the DB each time, which will improve performance.

AWS takes care of OS maintenance / patching, optimizations, setup, configuration,

monitoring, failure recovery and backups.

When accessing the DB, read / write operations will be slower.

When accessing the ElastiCache, read / write operations will be faster.
DynamoDB Overview
Fully Managed Highly available with replication across 3 AZ
NoSQL database - not a relational database
Scales to massive workloads, distributed “serverless2” database
Millions of requests per seconds, trillions of rows, 100s of TB of storage
Fast and consistent in performance
Single-digit millisecond latency – low latency retrieval
Integrated with IAM for security, authorization and administration
Low cost and auto scaling capabilities
Standard & Infrequent Access (IA) Table Class

When creating a DynamoDB, we create only the table, and not the DB, since its
serverless.
Also note that we cannot add tables to merge between or creation relationship.

The data that is entered into the DB is a key-value pairs.

We have primary key, which can consist of partition key and a sort-key.
The primary key has attributes that are Schemas defined per item.

DynamoDB Accelerator – DAX

• Fully Managed in-memory cache for DynamoDB

• 10x performance improvement – single digit millisecond latency to microseconds latency –
when accessing your DynamoDB tables
• Secure, highly scalable & highly available
• Difference with ElastiCache at the CCP level:
DAX is only used for and is integrated with DynamoDB, while ElastiCache can be used for
other databases

DynamoDB – Global Tables

This makes a DB table accessible with low latency in multiple regions.
If we have a table in region A, we can create a replication table in region B, and the
replication will be 2-way. This means that the data is the same at region A and B.
This is called Active-Active replication, since we write to region A, it is affected in region B,
and vice versa. If we write in region B, we can read the same data in region A.

2
This means that we do not need to provision anything, there is no server, hence it’s serverless.
Redshift Overview
Redshift is based on PostgreSQL, but its not used for OLTP (Online Transaction
Processing).
Redshift is OLAP (online analytical processing [analytics and data warehousing])
We load the data every hour and not every second.
The performance is better in 10X then other data warehouses, and it can scale up to PB.

Columnar storage of data (instead of row based)

Massively Parallel Query Execution (MPP), highly available
Pay as you go based on the instances provisioned
Has a SQL interface for performing the queries
BI tools such as AWS Quicksight or Tableau integrate with it

Redshift Serverless

Automatically provisions and scales data warehouse underlying capacity

Run analytics workloads without managing data warehouse infrastructure
Pay only for what you use (save costs)
Use cases: Reporting, dashboarding applications, real-time analytics…

This can be enabled, and then we connect Amazon Redshift Query Editor, which connects to
Amazon Redshift Serverless (this will run queries and automatically provision and scale
capacity based on workloads), then, we will pay only for the compute time and storage used.

Amazon EMR
EMR = Elastic Map Reduce
This helps creating Hadoop Clusters (for big data) to analyse and process vast amount of
data.
The clusters can be made of hundreds of EC2 instances.
EMR takes care of all the provisioning and configs, it has auto-scaling and integrated with
Spot instances.
The use case for this is to process data, the do ML, web indexing, big data...

Amazon Athena
This is a serverless query service to perform analytics against S3 objects.
It uses standard SQL language to query the files.

QuickSight Overview
Serverless ML powered BI service to create interactive dashboards.
It is a fast, automatically scalable, embeddable with per session pricing.

DocumentDB Overview
DocumentDB is the same for MongoDB (NoSQL DB).
MongoDB is used to store, query, and index JSON data
Similar “deployment concepts” as Aurora
Fully Managed, highly available with replication across 3 AZ
DocumentDB storage automatically grows in increments of 10GB
Automatically scales to workloads with millions of requests per seconds

Neptune Overview
Fully managed graph database
Highly available across 3 AZ, with up to 15 read replicas
Build and run applications working with highly connected datasets – optimized for these
complex and hard queries
Can store up to billions of relations and query the graph with milliseconds latency
Highly available with replications across multiple AZs
Great for knowledge graphs (Wikipedia), fraud detection, recommendation engines, social
networking

Timestream Overview
Fully managed, fast, scalable, serverless time series database
Automatically scales up/down to adjust capacity
Store and analyse trillions of events per day
Built-in time series analytics functions (helps you identify patterns in your data in near real-
time)

QLDB Overview
QLDB stands for” Quantum Ledger Database”
A ledger is a book recording financial transactions
Fully Managed, Serverless, High available, Replication across 3 AZ
Used to review history of all the changes made to your application data over time
Immutable system: no entry can be removed or modified, cryptographically verifiable
2-3x better performance than common ledger blockchain frameworks, manipulate data using
SQL
Difference with Amazon Managed Blockchain: no decentralization component, in accordance
with financial regulation rules
Managed Blockchain Overview
Blockchain makes it possible to build applications where multiple parties can execute
transactions without the need for a trusted, central authority.
Amazon Managed Blockchain is a managed service to:
• Join public blockchain networks
• Or create your own scalable private network
Compatible with the frameworks Hyperledger Fabric & Ethereum

Glue Overview
Managed extract, transform, and load (ETL) service
Useful to prepare and transform data for analytics
Fully serverless service

If we have data in S3 Bucket and An Amazon RDS, we can extract data from them. Then we
create a script to transform the data. And load the data into Redshift.

DMS Overview
DMS – Database Migration Service.
This service will take data from a source DB using an EC2 instance running DMS, then the
data will be migrated into a target DB.
It allows to quickly and securely migrate databases to AWS, resilient, self healing
The source database remains available during the migration.

Databases & Analytics Summary in AWS

• Relational Databases - OLTP: RDS & Aurora (SQL)
• Differences between Multi-AZ, Read Replicas, Multi-Region
• In-memory Database: ElastiCache
• Key/Value Database: DynamoDB (serverless) & DAX (cache for DynamoDB)
• Warehouse - OLAP: Redshift (SQL)
• Hadoop Cluster: EMR
• Athena: query data on Amazon S3 (serverless & SQL)
• QuickSight: dashboards on your data (serverless)
• DocumentDB: “Aurora for MongoDB” (JSON – NoSQL database)
• Amazon QLDB: Financial Transactions Ledger (immutable journal, cryptographically
verifiable)
• Amazon Managed Blockchain: managed Hyperledger Fabric & Ethereum blockchains
• Glue: Managed ETL (Extract Transform Load) and Data Catalog service
• Database Migration: DMS
• Neptune: graph database
• Timestream: time-series database
Other Compute Services: ECS, Lambda, Batch,
Lightsail
Difference between EC2 and Docker Containers
EC2 instances are virtual server that run on the AWS cloud infra. The instances are isolated
from each other at the hypervisor level. Which means that they do not share resources.
Containers are lightweight, portable and share the same OS kernel (so the resources are the
same) but run in isolated user spaces.
In EC2 we need to manage the entire instance (OS, runtime, app) and in Docker we only
focus on the app and not on the infra, so its easier to manage and deploy app on Docker.

ECS, Fargate and ECR Overview

ECS = Elastic Container Service.
This service will launch Docker container on AWS.
We need to provision and maintain the infra (create EC2 instance in advance).
AWS takes care of starting and stopping containers.
It is integrated with ALB (application load balancer).

Fargate
This service will launch Docker containers on AWS.
But we do no need to provision the infra (so no EC2 instances needed to be managed), it is
much simpler.
This is a serverless offering, since we do not need to manage any server/instances.
AWS just runs the container for us based on the CPU and RAM we need.

ECR = Elastic Container Registry (template registry)

This is a private Docker Register on AWS.
This is where we would store Docker images so they can be run by EC2 or Fargate.

Serverless Introduction
Serverless is a paradigm in which developers don’t have to manage server anymore, they just
deploy code or functions.
Initially serverless is a FAAS (Function as a service), and started by AWS Lambda but now
includes anything that is managed by AWS like: DB, Messaging, Storage.

Serverless doesn’t mean there is no servers. There are servers, but we do not manage them,
do no provision them and we don’t see them.
AWS Lambda
If we use an EC2 instance:
 It is a virtual server on the cloud.
 It is limited by RAM and CPU.
 It is running continuously.
 To scale we need to intervene and add or remove servers over time.
If we use a Lambda function:
 It is a virtual function – so there are no servers to manage.
 It is limited by time – meant to be run in short executions.
 It runs on demand.
 It scales automatically.

Benefits of Lambda:

 Easy pricing: pay per request and compute time.

 Integrated with the whole AWS services.
 Event Driven: lambda functions can get invoked by other AWS services when
needed.
 Integrated with many programming languages.
 Easy to monitor with AWS CloudWatch.
 Easy to get more resources per function.
 Increasing RAM will also improve CPU and network.

We can also run Lambda Container Image, which the image must implement the Lambda
Runtime API.

Example of use case: Serverless Thumbnail Creation:

We can create an S3 bucket which will hold images.
When we upload a new image, an AWS Lambda function will trigger and create a thumbnail
(which is a smaller image).
This thumbnail will be push into an S3 bucket, and also the Lambda function will push
metadata to DynamoDB (image name, size, create date and so on).
This is an Event Driven Architecture.

Example of use case: Serverless CRON job:

We can create a CloudWatch Events service or EventBridge, that each hour will trigger an
AWS Lambda function to perform a task.
API Gateway Overview
We can create a serverless API, the DB will be a DynamoDB and to do CRUD operations on
it we can use Lambda.
To let client access the Lambda function we need the API gateway to send requests to
the Lambda function. The API Gateway will proxy the requests to the Lambda.
This allows to easily create, public, maintain, monitor and secure APIs.
This is a serverless API and scalable.

AWS Batch
This is a fully managed batch processing at any scale service.
It runs efficiently 100K of computing batch jobs on AWS.
A “batch” job is a job that has a start and an end (opposed to continuous which continues
infinitely).

The batch will dynamically launch EC2 instances or Spot instances.

AWS batch provisions the right amount of compute and memory.
we just submit or schedule the batch job and AWS Batch will do the rest.

The batch jobs are defined as Docker Images and run on ECS.
It is helpful for cost optimizations and to us to focus less on the infra, since it provisions the
instances on its own.

Lambda VS Batch:

Lambda has time limit, it is limited it runtimes, it is limited in disk space, and it is serverless.
Batch has no time limit, can have any runtime if it’s packaged as a Docker Image. It relies on
EBS or Instance Store for the disk space. And relies on EC2 (which is managed by AWS.)

LightSail Overview
This is a stand-alone service which gives virtual servers, storage, DB, and networking.
It has low and predictable pricing, and it is simpler alternative to using EC2, RDS, ELB,
EBS, Route 53 and so on.
It is great for people with little cloud experience, and we can also setup notifications and
monitoring on the Lightsail resources.
We can create simple web apps, websites, dev/test environment and so on.
It has high availability, but it has no auto-scaling and it is limited with AWS integrations.
Deploying and Managing Infra at Scale
CloudFormation Overview
(Create infra from code)
CloudFormation is a declarative way of outlining AWS infra for any resource.
For example, in a CloudFormation template I can say that I want:
security group, 2 EC2 instances that use the security group, S3 bucket, ELB in front.
CloudFormation will create these, in the right order with the same configs that we specify.

The benefits of using AWS CloudFormation:

 Infra as code:
There are no resources that are needed to be created manually, which is excellent for
control, and can prevent human errors.
The changes we made to the infra is reviewed through code
 Cost:
We can know which resources we are going to have so we can estimate the cost.
 Productivity:
We can destroy and create infra on the go, and see diagrams as templates
 Don’t re-invent the wheel:
we can use existing templates and view documentation.
 Supports almost all AWS resources:
In case a resource is not supported we can use a custom resource.

AWS Cloud Development Kit (CDK)

Using CDK we can define cloud infra using programming language.
The code is compiled into a CloudFormation template.
We can deploy infra and app runtime code together.
This is great for lambda functions, and for docker containers in ECS / EKS.
BeanStalk Overview
(Create app using code, infra is managed)
Usually, we can create an ELB in multi-AZ mode, have EC2 instances in different AZs and
an ASG controlling the scale. We can also add an Amazon RDS so we can save data, and the
instances can read / write data, and an ElastiCache to store / retrieve session and cached data.
We can do it automatically through CloudFormation or manually.
But there is a better way.

As a developer we do not want to manage the infra manually, we want to deploy code. And in
the code, we can configure everything, instead manually. Also, scale is a concern, and since it
is hard to configure 100 EC2 instances, this can be done through code.
As most web apps have the same architecture (ALB + ASG), we want to our code to produce
all those things and possibly to run different apps and environments.

Elastic Beanstalk is a developer centric view of deploying an app on AWS. It uses the same
components as before, and we have full control over the configs.
The is a Platform as a service (PaaS).
This is a free service, but we need to pay for the infra.

This is a managed service:

 The instance configs and OS is handled by Beanstalk.
 The deployment strategy can be changed by performed by Beanstalk.
 The capacity is also managed.
 Load balancing and Auto scaling is managed.
 App health-monitoring and responsiveness is taken care.

As a developer all we must do is create the app code.

There are 3 architecture modules:

1. Single instance: good for dev.
2. LB + ASG: for production or pre-prod web apps.
3. ASG only: for non-web app in prod.
AWS CodeDeploy
This service allows to deploy app automatically.
It works with EC2 instances, but it can also work with on-prem servers, this is why it is a
hybrid service.
The server / instances must be provisioned and configured before the CodeDeploy Agent.

AWS CodeCommit
Before pushing the app code to servers, it needs to be stored.
We usually store code in a repo, using git.
This is same as GitHub.
CodeCommit allows source-control that hosts Git-based repos. It makes easy to collaborate
with others on code and changed are automatically versioned.
This is a fully managed repo, scalable and highly available, private, secure, and integrated
with AWS.

AWS CodeBuild
This is a fully managed serverless service. It is continuously scalable and highly available,
secure, and pay as you go.
It allows code building service in the cloud.
It compiles the source code, ruin tests, produces packages that are ready to be deployed.
The code can be taken from CodeCommit, and then CodeBuild will build the code and then
we have a ready-to-deploy artifact.

AWS CodePipeline
This service allows to orchestrate the different steps to have code automatically pushed to
prod.
Code -> build -> test -> provision -> deploy.
This is the basis for CICD.
It is a fully managed, compatible with many services.
Allows fast delivery and rapid updates.
CodeCommit -> CodeBuild -> CodeDeploy -> Elastic Beanstalk.
This is can orchestration layer.
AWS CodeArtifact
Software packages depend on each other to be built (code dependency), and new ones are
created.
Artifact management – storing and retrieving dependencies.
Instead of setting up our own artifact management system we can use CodeArtifcat.
This is a secure, scalable, cost-effective artifact management for software development.
It works with common dependency management tools.
Developers and CodeBuild can retrieve dependencies from CodeArtficat.

AWS CodeStar / CodeCatalyst

Unified UI to easily manage software development activities in once place.
This is a quick way to get started to correctly set up different services.
We can edit the code “in the cloud” using AWS Cloud9.
Here we cannot monitor the health of the environment.

AWS Cloud9
This is cloud IDE (Integrated Development Environment) for writing, running and debugging
code.
This once can used in the web browser; we can work on this IDE from anywhere with
internet and no setup is necessary.
It allows code collaboration in real-time.

AWS System Manager (SSM)

This is a hybrid service, which helps manage EC2 and on-prem systems at scale. We can get
operational insights about the state of our infra.
We can:
 Patch automation for enhances compliance.
 Run commands across an entire fleet of servers.
 Store params configs with the SSM Parameter Store.
We need to install the SSM agent onto the systems we want to control.
It is installed on Amazon Linux AMI.
If an instance cannot be controlled with SSM then the issue is with the SSM agent.
We can then run commands, patch and configure servers.
Systems Manager – SSM Session Manager
(access instances through secure shell with no need to open ssh)
This allows to start a secure shell on EC2 and on-prem servers.
The EC2 instance has SSM Agent, we can then connect to the Session Manager and execute
commands to the EC2.

This means that we don’t need SSH access, or bastion hosts, or SSH keys. Also, port 22 is no
needed (so we get better security).

To view instances that have SSM access, go to fleet manager.

To access instances, go to session manager.

Note – the instance has to have an IAM role for SSM access.

Systems Manager Parameter Store

This is a secure storage for configs and secrets.
We can store API keys, passwords, configs.
This is a serverless, scalable, durable and an easy SDK service.
We can control access permission using IAM.
We can also have version tracking and encryption using AWS KMS.
Homework:
 create the serverless thumbnail – failed once
 api creation
 create a batch job that will take an image from s3 process it and put it back on s3, dont
know if its complicated, but we will see.
 Cloudformation exercise – ask gpt?
 AWS Codepipeline exercise?

At the end – add the certification – add lambda to skills -