AWS Services

AWS stands for Amazon Web Services

Currently most popular cloud platform, with a huge

collection of services:
 AWS Account and Services Scope

In AWS you have 3 scopes: Global, Region and Availability Zones

Different resources will be created in one of those scopes
AWS Resources
 Create an AWS Account - 1
Register on AWS
 Create an AWS Account - 2

For first time registration, you get 1-year free of basic resources

Some services are NOT

included in the free tier!

Delete Resources that you

don't need anymore
 Identity and Access Management (IAM) - 1

With IAM service you can specify who can access which services and resources

Create and manage AWS Users and Groups

Assign policies (set of permissions)

User Group Policy

ROOT user is created by default

ROOT user has unlimited privileges

Best Practice: Create an admin user with less privileges that manages

the whole AWS account

 Identity and Access Management (IAM) - 2

Different Types of IAM Users

1. Human Users do something on

your AWS cloud

2. System Users: For example Jenkins needs permission to

deploy Docker containers on AWS

Groups

For granting access to multiple IAM users

Group Policy
 Identity and Access Management (IAM) - 3

IAM Roles

IAM role is similar to an IAM user

Instead of being uniquely associated with one person, a

role is intended to be assumable by anyone who needs it

Also Policies cannot be assigned to AWS services directly

So role is used to grant AWS services access to other

How to:
AWS services
1. Create IAM Role

2. Assign Role AWS Service

3. Attach Policies to that Role

 Regions & Availability Zones (AZ) - 1
Cloud providers have physical data centers

Data centers all over the world

Region = physical location, where data centers are clustered

You have to select, which region you want your server

 Regions & Availability Zones (AZ) - 2

Each group of logical data centers is called an Availability Zone

Availability Zones = one or more discrete data centers

 Virtual Private Cloud (VPC)

VPC is your own isolated network

in the cloud

You have a VPC for each Region

VPC spans all the AZ (Subnet) in that Region

Multiple VPCs in different Regions

VPC is like a virtual representation of network

Your resources always have to infrastructure: Server setup, network configuration

run in a VPC!
moved to cloud
 Subnet - 1
Subnet is a range of IP addresses in your VPC You have a subnet for each Availability Zone:

It's like a private network inside a network:

Private and Public Subnets

Based on firewall configuration

you can have a private and/or

public subnet:
 Subnet - 2
A subnet has a default range of

internal IP addresses

When you create a new resource

like EC2 instance then an IP

address is assigned within this

subnet's IP range

For communication inside the internal IP internal IP

address address

VPC

Internet Gateway

Using an internet gateway you can connect the VPC or its subnets to the outside internet
 Security - Controlling Access

Of course you need to secure your resources:

Control access to your VPC

Control access to your individual server instances

NACL

Configure access on subnet level

Security Group

Configure access on instance level

 CIDR Block
When you create a subnet, you specify the IPv4

CIDR block for the subnet, which is a subset of the

VPC CIDR block

Defines a range of IP addresses

CIDR = Classless Inter-Domain Routing

How to choose a CIDR Block:

 Elastic Compute Cloud (EC2)
A virtual server in AWS Cloud, providing computing capacity

Steps to deploy a web 1) Steps to launch EC2 instance

application on EC2 instance 1. Choose OS Image

1. Create an EC2 instance on AWS 2. Choose capacity

3. Network configurations
2. Connect to EC2 instance with ssh
4. Add storage
3. Install Docker on remote EC2 instance 5. Add tags

4. Run Docker container (docker login, pull, 6. Configure Security Group

run) from private repository

2) Connect to EC2 server via ssh
using downloaded private ssh key:
5. Configure EC2 Firewall to access

application externally from the browser

 Deploy to EC2 Instance from Jenkins - 1

CI Part CD Part

Steps to deploy to EC2 instance

1. Connect to EC2 instance from Jenkins server via ssh (ssh agent)

2. Execute "docker run" on EC2 instance

 Deploy to EC2 Instance from Jenkins - 2
Steps to connect to EC2 instance from Jenkins server via ssh (ssh agent)

1) Install SSH Agent Plugin: 2) Configure credential

3) Use credential in "deploy" stage in Jenkinsfile

 AWS Command Line Interface (CLI) - 1

Instead of using the UI, we can use the AWS CLI to interact with our AWS account

UI Access through password CLI Access through Access key ID and Secret Access Key

For that you need to configure your AWS CLI:

 AWS Command Line Interface (CLI) - 2

Command Structure
aws = the base call to the aws program
command = the AWS service
subcommand = specifies which operation
to perform

Launch EC2 Instance

via AWS CLI

 AWS & Terraform - Preview

Before Infrastructure as Code After Infrastructure as Code

Many commands to execute Create and manage resources

No overview with code

Imperative commands telling Terraform is a IaC tool

how to do it Declarative - describing the

desired state
 Container Services on AWS - Preview

AWS provides different services to help you deploy containerized workloads

Elastic Container Registry (ECR) =

container registry to store, share
and deploy container images
Elastic Kubernetes Service (EKS) =
Amazon's Managed Kubernetes Service

Elastic Container Service (ECS) =

AWS proprietary container orchestration
 Best Practices

IAM best practices:

https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
VPC best practices:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
EC2 best practices:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html

Keep your .pem file in the “standard” location in .ssh directory in your $HOME. I.e.
/Users/$USER/.ssh/. You should protect this directory with permission 400
You should not share these .pem files with your co-workers. Each user should generate their
own SSH keypair and their public key should be deployed to each system they need access to.
Private keys should be private to each user, generated by them.