AWS+Partner+ +Containers+on+AWS+ (Technical) + +v1.0.1 Compressed

AWS Partner: Containers on AWS
(Technical)
Prerequisites
• AWS Technical Professional accreditation

• Hands-on experience with cloud-based compute, such as
Amazon Elastic Compute Cloud (Amazon EC2)
• Experience with the Docker container runtime
• Familiarity with cloud computing concepts, including
virtualization
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. 2
Course objectives
• Discuss app modernization and DevOps, and how these practices

help partners build their businesses
• Discuss container infrastructure and platforms with customers
• Describe the benefits and use cases for AWS containers
• Analyze and design AWS container-based architectures
• Identify further education in container-based solutions
Overview
• Module 1: Cloud-Native Development

• Module 2: Why Containers
• Module 3: Containers on Amazon Web Services
• Module 4: Running Containers on Amazon Web Services
• Module 5: Next Steps
MODULE 1
Cloud-Native Development
Questions?
• Are any of your current customers

interested in or using container-based
workloads?
• What do you think are the reasons

those customers are looking at or using
containers?
Module 1 objectives
• Discuss legacy application development and its

challenges
• Explain how a cloud-native model changes the
way your customers develop and deploy
applications
• Explain how to build a practice that guides
customers to innovation and agility
Broaden the conversation
Microservices?
DevOps?
Containers?
Modern
applications?
Continuous integration
and continuous
deployment (CI/CD)?
Impact of legacy applications
Slow traditional
development processes Long release cycles
Ineffective Operational issues

communication between
development and
operations teams Recurring bugs
Best practices for rapid innovation
Enable
experimentation
Simplify
Update quickly
infrastructure
Small teams
n
Ma
tio
na
ma
Secure
ge
Standardize
to
application
ds
au
Se operations
lifecycle
erv
e
CD
cu od
rity c
ice
s
CI/
au a
u re
s
to ma c t
tio tr u
n fr as
In
Improve
Componentize performance and
applications Rapid
Microservices Observability reliability
innovation
Best practices for container-based workloads
Enable
experimentation
Simplify
Update quickly
infrastructure
Small teams
n
tio
ma
Secure
Standardize
to
Se
application
au
operations
rv
Se e
lifecycle od
CD
cu
erl
rity s c
ea
CI/
ess
au
to c tur
ma
tio s tru
r a
n
In f
Componentize Modern Improve
applications Microservices application Observability performance
development
Componentize applications with
microservices
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Monoliths versus microservices
Monolith Microservices
Orders Orders Ordering service
Payments Payments Payment service
Inventory Inventory Inventory service
Single, monolithic service Multiple, separate services

Microservices benefits
Pick the right Increase agility Improve resilience Lower costs with Experiment
tool for the job safely and security granular scaling and innovate
Microservices challenges
Increase in number and

complexity of distinct
Challenges services and APIs
Architecture, monitoring, and

security needs to evolve
Organization and culture

change is required
Update applications and
infrastructure with a CI/CD
pipeline
Four release process phases
Source Build Test Production
• Check in source • Compile code • Integrate with other • Deploy to production

code • Run unit tests, systems environments
style checkers, and • Run load, UI, and
• Review new code
code metrics penetration tests
• Create container
images
Monolith—fast as its slowest part
Build Test Release
Developers Application Delivery pipeline

Microservices—a faster release cadence
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Developers Microservices Delivery pipeline

Improve application performance
by increasing observability
Observability gets answers quickly
Observability Metrics Logs Traces
Observability challenges
Monitoring
• Work with log formats that vary across services
microservices
• Collect, route, correlate, and analyze logs
• Set up metrics and alarms
Architecting • Handle cross-service interactions that return errors

microservices • Isolate cascading errors in the application stack
• Anticipate and handle interaction issues
• Be aware of cumulative latency and user experience
Traditional debugging challenges
Local Add log

test statements
Add
breakpoints
Build a practice around modernization
The new normal: companies are increasingly global, and products are completely digital.
47% 79% 67%

CEOs challenged to CIOs believe digital Business leaders
make progress in business is making IT believe they must pick
digital business. better prepared to up the digital pace to
change. remain competitive.
Source: Gartner
Master componentizing applications
1. Master componentizing 2. Help customers create a 3. Guide customers through

applications using culture of ownership to migrations towards
microservices. foster experimentation. automation and DevSecOps.
• Guide new customers towards serverless and managed services

• Understand best practices and architectural patterns for microservice-based workloads
Create a culture of ownership

• Educate customers on the benefits of cloud-native application architecture

• Understand customers’ software development lifecycle (SDLC) practices
• Guide customers on organizational change management (OCM)
Guide customers through migrations

• Design for automation, observability, alerting, and recovery

• Understand DevSecOps patterns and methodologies
• Show customers the benefits of cloud-native capabilities
Containers as part of modernization
Foster cultural • Modernize development processes around technology,

transformation and understand business impacts and needs
Perform
• Migrate legacy workloads to containers running in AWS
migrations
Codevelopment • Perform custom development of containerized

with customers applications, from assessment through deployment
Offer managed • Secure, manage, and operate containerized

services environments at scale
MODULE 2
Why Containers
Module 2 objectives
• Describe the current evolution of compute

platforms in the context of the cloud
• Explain the basics of container technology
• Explain container security fundamentals
• Describe other technologies needed to run
container workloads at production scale
Abstraction in compute platforms
Compute spectrum
On-premises Virtual Containers Serverless

servers machines (VMs) functions
Abstraction Maturity
Compute environment considerations
Architecture Operations Integration
Ø How the CPU is exposed to Ø Maintenance requirements Ø Ecosystem of vendors and

the program Ø Monitoring and partners
Ø Efficiency and performance management options Ø Migration between
environments 37
Architecture considerations
On-premises • Highest amount of customization

servers • Built for highest peak use
Virtual • Broader adoption

machines • Virtualization overhead
• Lighter and faster than virtual

Containers
machines
• Increases dependency on network
Serverless • Infinitely scalable
functions • Event-based architecture
Operational considerations
On-premises servers Virtual machines

• Most customer responsibility • VM lifecycle management critical
• Monitor Open Systems • Mutable infrastructure
Interconnection (OSI) model
Containers Serverless functions

• Production scale requires • Unique operational model
orchestration • Traditional monitoring
• Immutable artifacts lead to difficult
automation
Integration considerations
On-premises Serverless
Virtual machines Containers
servers functions
Established Deployment Sweet spot Fewer options but

market flexibility between VMs rapidly changing
and functions
Container fundamentals
Uses underlying
operating system Isolates software
Packages application
from
artifacts
environment
Container benefits
Portability Immutability Flexibility Speed Efficiency
Portable Single, Run versions Faster Better resource

runtime immutable simultaneously development usage and
application artifact cycles efficiency
environment
Container architecture versus other technologies
On-premises servers Virtual machines Containers
Container Container Container

VM VM VM
App A App B App C App A App B App C
Libs Libs Libs Libraries Libs

Guest Guest Guest
Applications A, B, C Libraries
OS OS OS
Libraries Virtualization platform Containerization platform
Operating system Operating system Operating system
Server hardware Server hardware Server hardware
Docker platform
Released March 2013
Tools for creating, storing, managing, and

running containers
Easy to integrate with automated pipelines
Build, test, and deploy applications quickly
Docker components
Binaries
Docker client Docker host Image registry
docker build Docker daemon
docker pull Containers Images
docker run
Docker layers
• Changes are copy-on-

Top layer
write
(read-write)
• New files exist only at the
top layer
• Modified files are copied Intermediate
up to the top layer layer
• Unmodified files exist in (read-only)
their original layer
• Deleted files are hidden
Base layer
(read-only)
Dockerfile example
Thin R/W layer Container layer
FROM centos:7
RUN yum -y update && yum -y

RUN chmod -v +x /run-httpd.sh
install httpd
EXPOSE 80 ADD run-httpd.sh /run-

httpd.sh
ADD run-httpd.sh /run-httpd.sh Image
EXPOSE 80
layers
(R/O)
RUN chmod -v +x /run-httpd.sh RUN yum -y update && yum -y
install httpd
CMD ["/run-httpd.sh"]
CentOS 7
Container
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. (based on centos:7 image) 47
Docker images versus containers
Thin R/W layer Thin R/W layer Thin R/W layer Thin R/W layer
• A container is a running
instance of an image. RUN chmod -v +x /run-httpd.sh
ADD run-httpd.sh /run-

• All containers have a top- httpd.sh
level writable layer.
EXPOSE 80
RUN yum -y update && yum -y

install httpd
CentOS 7
Video
Security 101
https://www.youtube.com/watch?v=Cp4rdlsQORo
Container security summary
• Remember the shared responsibility model: Security of

the cloud versus security in the cloud.
• Always practice defense in depth: Use a multilayered
approach, starting with the most valuable data.
• Invest in end-to-end automation: Make it easy for teams
to do the right thing.
• Secure container images: Less is more secure; minimize
container footprint.
• Secure containers at runtime: Limit execution
environment and monitor for common vulnerabilities and
exposures (CVEs).
Persistent storage
Persistent Low-latency Service discovery Secrets

storage databases and service mesh management
• Containers are ephemeral.

• Transactional data stored in a database.
• Persistent data must go elsewhere.
• Object storage or shared file system.
Low-latency databases

• Transactional or latency-sensitive data.

• Not always traditional relational database: NoSQL, graph, and time series
• Caching tier using in-memory databases.
• Separation between compute tier and storage tier.
Service discovery and service mesh

• Constantly monitor the health of every resource.

• Single registry for all app resources.
• Easily export logs, metrics, and traces.
• Client-side traffic policies – circuit breaking, retries.
Secrets management

• External secrets are pulled individually by each container.

• Container authenticates or federates to centralized service.
• The service relays the request secret, encrypted, to the container.
• Container decrypts secret and authenticates to database or API.
Activity
Build a Dockerfile
Start with an image
A FROM ubuntu:latest
B FROM node:10
CC START WITH alpine:3.9

Start with an image
FROM node:10
A FROM ubuntu:latest
B FROM node:10
CC START WITH alpine:3.9

Set a working directory
FROM node:10
A WORKDIR /usr/src/app
DIRECTORY /Program
B Files(x86)/NodeJS/
CC DIRECTORY /usr/src/app
Set a working directory
FROM node:10
A WORKDIR /usr/src/app
WORKDIR /usr/src/app
DIRECTORY /Program
B Files(x86)/NodeJS/
CC DIRECTORY /usr/src/app
Copy dependencies into image
FROM node:10
A MOVE package*.json ./
B COPY package*.json ./
CC PUT package*.json ./
Copy dependencies into image
FROM node:10
A MOVE package*.json ./
COPY package*.json ./
B COPY package*.json ./
CC PUT package*.json ./
Install the application
FROM node:10
A RUN npm install
B EXEC npm install
RUN npm config --start

CC install
Install the application
FROM node:10
A RUN npm install
RUN npm install B EXEC npm install
RUN npm config --start

CC install
Set HTTP networking port
FROM node:10
A OPEN 8080
RUN npm install B PORT 8080
CC EXPOSE 8080
Set HTTP networking port
FROM node:10
A OPEN 8080
RUN npm install B PORT 8080
EXPOSE 8080
CC EXPOSE 8080
Start the application on instantiation
FROM node:10
A CMD [ "node", "server.js" ]
START [“node”,
RUN npm install B “server.js”]
EXPOSE 8080
CC EXEC [“node”, “server.js”]

Start the application on instantiation
FROM node:10
A CMD [ "node", "server.js" ]
START [“node”,
RUN npm install B “server.js”]
EXPOSE 8080
CMD [ "node", "server.js" ]

CC EXEC [“node”, “server.js”]
MODULE 3
Containers on Amazon Web

Services
Module 3 objectives
• Explain how to scale and manage containers

in production
• Describe the container services on AWS
• Describe the methods for running containers
at scale with AWS
Scale one host with multiple containers
Container Container
Application 1 Application 2
Libraries Libraries docker run myimage
Container platform
Operating system
Server
Scale hundreds of hosts, thousands of containers
Container orchestration platforms
Container Orchestration Platform

Scheduling Placement
Node 1 Node 2 Node n
Docker daemon Docker daemon

… Docker daemon
Containers Containers Containers

AWS container services landscape
Amazon Elastic Amazon Elastic

Orchestration Container Service Kubernetes
(Amazon ECS) Service (Amazon
EKS)
Amazon Elastic
Compute Compute Cloud AWS Fargate
(Amazon EC2)
Amazon Elastic
Image registry Container Registry
(Amazon ECR)
Amazon Elastic Container Service
(Amazon ECS)
Amazon ECR: Private registry as a service
Run containers
Write code
Amazon ECS
Amazon EKS
AWS Cloud
Write and Compress, Version, tag, Pull images and
package code Amazon ECR
encrypt, and and manage run containers On premises
as a Docker control access image lifecycles anywhere
image to images
Fully managed container registry
Amazon ECS
Define your Manage

application containers
Amazon EC2
Amazon ECR Select container Amazon ECS scales

Amazon ECS your application and
images and
resources needed for manages your
Build images and application AWS Fargate containers for
store using ECR or availability
any other repository
Fully managed container orchestration platform

Amazon ECS capabilities
AWS Cloud
Amazon ECS Amazon CloudWatch

ECS cluster
EC2 instance EC2 instance EC2 instance

IAM
Containers Containers Containers

Amazon EC2
Auto Scaling
Amazon ECS details
Amazon ECS example workload
Amazon EC2 instance
Task Task Amazon ECS

container
internet Elastic Load Container Container agent
Amazon ECS
Balancing
Amazon EC2 instance
• Agent
Amazon ECS
Task Task communication
container
agent service
Container Container • API
• Cluster management
Amazon EC2 instance
engine
Amazon ECS • Key and value store
Elastic Load container
Task Task
Balancing agent
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. Containers Container
84
Amazon ECS container agent
Amazon EC2 instance

• Enforces resource
allocation at a local
Docker container runtime level
Amazon
ECS
container • Exposed through the
Task Task
agent Docker container
runtime
Containers Container
Amazon ECS backplane
Amazon EC2 instance

container
Amazon ECS
Balancing
Amazon EC2 instance
• Agent
Amazon ECS
container
agent service
Amazon EC2 instance
engine
Task Task
Balancing agent
86
Amazon ECS cluster
Amazon EC2 instance

container
Amazon ECS
Balancing
Amazon EC2 instance
• Agent
Amazon ECS
container
agent service
Amazon EC2 instance
engine
Task Task
Balancing agent
87
Amazon ECS task
Amazon EC2 instance

container
Amazon ECS
Balancing
Amazon EC2 instance
• Agent
Amazon ECS
container
agent service
Amazon EC2 instance
engine
Task Task
Balancing agent
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. Containers Container 88
Amazon ECS service
Amazon EC2 instance

container
Amazon ECS
Balancing
Amazon EC2 instance
• Agent
Amazon ECS
container
agent service
Amazon EC2 instance
engine
Task Task
Balancing agent
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. Containers Container 89
Amazon ECS task definition
simple-app busybox
{ {
"containerDefinitions": [ "name": "busybox",
{ "image": "busybox",
"name": "simple-app", "cpu": 10,
"image": "httpd:2.4", "memory": 200,
"cpu": 10, "volumesFrom": [
"memory": 300, {
"portMappings": [ "sourceContainer": "simple-app"
{ }
"hostPort": 80, ],
"containerPort": 80, "command": [
"protocol": "tcp" "/bin/sh -c \"...\""
} ],
], "essential": false
"essential": true, }
"mountPoints": [ ],
{ "volumes": [
"containerPath": "/usr/local/apache2/htdocs", {
"sourceVolume": "my-vol" "name": “my-vol"
} }
] ]
}, }
Amazon ECS task definition parameters
{
"containerDefinitions": [ simple-app
{
"name": "simple-app",
"image": "httpd:2.4",
"cpu": 10,
10 CPU units (1024 is 1 full vCPU)
"memory": 300, 300 MB of memory
"portMappings": [
{
"hostPort": 80,
Expose port 80 in container to
"containerPort": 80, port 80 on host
"protocol": "tcp"
}
],
"essential": true, Essential to our task
"mountPoints": [
{
"containerPath": "/usr/local/apache2/htdocs", Create and mount volumes
"sourceVolume": "my-vol"
}
]
},
Orchestration with Amazon ECS
Anatomy of task placement
Task requirements Satisfy CPU, memory, and networking

requirements
Filter for location, instance type, AMI, or other

Custom constraints
custom attribute constraints
Identify instances that satisfies placement

Placement strategies
strategies
Apply filter Select final container instances for placement
Constraints and strategies
Task definition
Outlines technical
requirements, such as CPU,
memory, and networking
Adds instructions about

task placement outside of
the task definition
Places tasks to minimize the amount

Binpack
of CPU or memory
Strategies
Places tasks evenly based on the
Spread specified value
Places tasks based on group

Affinity membership
Constraints
Distinct Places each task on a different
instance container instance
Target instance type and zone
aws ecs run-task --cluster ecs-demo --task-definition myapp --count 5
--placement-contraints type=“memberOf”,expression=“(attribute:ecs.instance-type
== t2.small or attribute:ecs.instance-type == t2.medium) and attribute:ecs.availability-zone
!= us-east-1d”
g2.2xlarge t2.small t2.micro t2.medium t2.small
t2.medium t2.small g2.2xlarge t2.small t2.medium

us-east-1d us-east-1a
Spread across zone and binpack
aws ecs run-task --cluster ecs-demo --task-definition myapp --count 9
--placement-strategy type=“spread”,field=“attribute:ecs.availability-zone”
type=“binpack”, field=“memory”
g2.2xlarge t2.small t2.micro t2.medium g2.2xlarge t2.medium
t2.medium t2.small g2.2xlarge t2.small t2.micro t2.small

us-east-1d us-east-1a us-east-1c
Task deployment on Amazon ECS
Amazon ECS task scheduler Amazon ECS service scheduler

• On-demand workloads • Long-running applications
• Built-in health management
• Run once or at intervals
features
• Batch jobs • Scale up and down across
• Started through RunTask API or Availability Zones
StartTask (custom) • Multiple tasks
Service strategies with service scheduler
{
“cluster”: “ecs-demo”,
“serviceName”: “my-service”,
“taskDefinition”: “my-app”,
“desiredCount” : 10,
“placementConstraints”: [
{
“type”: “memberOf”,
“expression”: “attribute:ecs.instance-type matches t2.*”
}
],
“placementStrategy”: [
{
“type”: “spread”,
“field”: “attribute:ecs.availability-zone”
} ,
{
“type”: “binpack”
“field”: “MEMORY”
}
]
}
Placement: Multiple services on a cluster
aws ecs create-service --service-name srvc-binpk --cluster ecs-demo --
task-definition myapp-binpk --desired-count 5
--placement-strategy type=“binpack”,field=“memory”
aws ecs create-service --service-name srvc-spread --cluster ecs-demo --

task-definition myapp-spread --desired-count 6
--placement-strategy type=“spread”,field=“attribute:ecs.availability-
zone”
t2.medium t2.small t2.medium t2.small t2.micro t2.small
us-east-1d us-east-1a us-east-1c

Integration with Amazon ECS
Amazon ECS service discovery
AWS_INSTANCE_IPV4
Service discovery through DNS and API
AWS_INSTANCE_PORT
• Additional attributes for Amazon ECS tasks
AVAILABILITY_ZONE
• Smart routing based on locality
• Support for Amazon EC2 and AWS Fargate REGION
launch types ECS_SERVICE_NAME
ECS_CLUSTER_NAME
EC2_INSTANCE_ID
ECS_TASK_DEFINITION_FAMILY
Amazon ECS service discovery
Register
Updates task
DNS AWS Cloud Map instances
Amazon Elastic
Container Service
172.16.0.0 Server instance #1

172.16.1.0 172.16.0.0
172.16.2.0 Server instance #2
Amazon 172.16.1.0
Route 53
DNS Server instance #3
172.16.2.0
Client makes a call to Client connects

AWS Cloud Map directly to an ECS task
discovery API or DNS instance
Client
Shared Responsibility Model
Amazon ECS on EC2
Lab J
AWS ECS
AWS Fargate
Manage containers with AWS Fargate
Amazon ECS AWS Fargate
Define the
images and Launch containers and
Build a container resources AWS Fargate manages
image needed for your all the underlying Launch containers Manage containers
application container infrastructure
AWS Fargate allows containers to be run

in a serverless operational model.
AWS Fargate parameters
Create • Infrastructure isolation boundary

Cluster • IAM permissions boundary
Elastic load
balanced
Run Create
Register Service
Task
Task definition • A running instantiation of a • Maintains running copies
task definition
Defines application containers • Integrated with ELB
• Use FARGATE launch type
• Unhealthy tasks
automatically replaced
AWS Fargate task definitions
Task definition snippet
Tasks are identified {

by family "family": “scorekeep",
"containerDefinitions": [
{
"name":“scorekeep-frontend",
Contains a list of up to
10 container definitions "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe"
},
{
"name":“scorekeep-api",
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api"
} Each container definition
] has a name and image
} source uniform resource
locator (URL) 116
AWS Fargate CPU and memory specifications
{
Task definition snippet
"family": "scorekeep",
"cpu": "1 vCpu",
Task-level resources "memory": "2 gb",
aggregated between all "containerDefinitions": [
containers {
"name":“scorekeep-frontend",
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe“,
"cpu": 256,
"memoryReservation": 512
Container-level resources
},
define sharing of
{
resources
"name":“scorekeep-api",
"image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api",
"cpu": 768,
"memoryReservation": 512
}
]
}
Task CPU and memory configurations
CPU Memory
256 (.25 vCPU) 512 MB, 1 GB, 2 GB

512 (.5 vCPU) 1 GB, 2 GB, 3 GB, 4 GB
1024 (1 vCPU) 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB
2048 (2 vCPU) Between 4 GB and 16 GB in 1 GB increments
4096 (4 vCPU) Between 8 GB and 30 GB in 1 GB increments
• Over 50 different CPU and memory configurations

• All priced per second with a one-minute minimum
© 2019 Amazon Web Services, Inc. or its Affiliates. All rights reserved. As of 10/31/2019 118
AWS Fargate integrations
AWS Fargate and IAM
Cluster
AWS Fargate task

Control who can launch, stop, and
describe tasks in a cluster
Cluster
permissions
Application
permissions Allow application containers (within
tasks) to access AWS resources securely
Task
housekeeping
permissions Allow AWS to perform housekeeping
activities around a task
Cluster permissions
Tailor access control to clusters with AWS IAM policies
Example IAM Policy 1 Example IAM Policy 2
{ {
"Effect": "Allow", "Effect": "Allow",
"Action": [ "ecs:RunTask" ], "Action": [ "ecs:ListTasks“,
"Condition": { “ecs:DescribeTasks” ],
"ArnEquals": {"ecs:cluster":"<cluster-arn>"} "Condition": {
}, "ArnEquals": {"ecs:cluster":"<cluster-arn>"}
"Resource": [ “<task_def_family>:*" ] },
} "Resource": “*”
}
Allow RunTask only in a specific cluster Allow read-only access to tasks in

with a specific task definition a specific cluster
Housekeeping permissions
Amazon ECS service linked role:

• Elastic network interface management
• ELB target registration and deregistration
Task execution IAM role:

• Amazon ECR image pull
• Push to Amazon CloudWatch Logs
AWS Fargate and Amazon Elastic Block Store
Ephemeral storage backed by Amazon Elastic

Block Store (Amazon EBS)
Layer Storage Space: 10 GB per task
Volume for scratch space

• 4 GB per task
• Mount points specified in task definition
• Can be shared among containers
Amazon ECS on Fargate
Lab J
AWS Fargate
Amazon Elastic Kubernetes
Service (Amazon EKS)
Introduction to Kubernetes
Open source container

orchestration platform
Helps run Provides primitives

containers at scale (building blocks) for
building modern
applications
Amazon EKS is fully managed Kubernetes
Amazon EKS
Amazon EC2
Deploy worker
Amazon EKS makes it Provision an nodes for you Connect to EKS Run Kubernetes apps
easy to run EKS cluster EKS cluster
Kubernetes on AWS
Amazon EKS helps customer run Kubernetes.
EKS is Kubernetes certified conformant
• Customers can use existing tool and

plugins.
• Applications can run on any standard

Kubernetes environment.
• Application can be easily migrated to

Amazon EKS.
Amazon EKS features
• Creates and manages a Kubernetes control plane

• Bring your own worker nodes, exactly like Amazon ECS
Platform for enterprise Provides a native and upstream

workloads Kubernetes experience
Amazon EKS
features
Integrates with additional Actively contributes to

AWS services upstream Kubernetes project
Kubernetes components
Controller Cloud
Scheduler
manager controller
API Server
masters
etcd
kube-proxy kubelet
worker nodes Pod Pod Pod
us-east-1a
Kubectl command line interface
Controller Cloud
Scheduler
manager controller
kubectl
API Server
masters
kube-proxy kubelet
worker nodes Pod Pod Pod
$ kubectl get pods

NAME READY STATUS RESTARTS AGE
nginx-4293833666-20vr8 1/1 Running 0 2m
nginx-4293833666-3gzfw 1/1 Running 0 2m
nginx-4293833666-7nBiH 1/1 Running 0 2m
135
Kubernetes with high availability
masters masters masters
etcd etcd etcd
worker nodes worker nodes worker nodes

us-east-1a us-east-1b us-east-1c 136
Kubernetes and Amazon EKS
masters masters
Amazon EKS masters
kubectl
mycluster.eks.amazonaws.com
etcd etcd etcd

Amazon EKS architecture
VPC
API Server Auto Scaling group
master nodes master nodes master nodes
Etcd Auto Scaling group
etcd etcd etcd

Amazon EKS integration
Amazon Amazon Elastic Load Amazon AWS Cloud IAM

SQS SNS Balancing Route 53 Map Authentication
Decoupling Load balancing Service discovery and authorization
AWS CodePipeline Amazon

AWS App Mesh Amazon API Gateway
CloudWatch
App networking Exposing services CI/CD Monitoring
Pods in Kubernetes
Deployments manage ReplicaSets
Deployment
ReplicaSet
version: 1
dbapp v1 dbapp v1 dbapp v1 replicas: 3
ReplicaSet
version: 1
replicas: 3 webapp v1 webapp v1 webapp v1

us-east-1a us-east-1b us-east-1c
Pods and services communicate
webapp dbapp dbapp

Service
app: dbapp
port: 80
webapp dbapp dbapp
targetPort:
13721
webapp dbapp dbapp
Kubernetes scheduler prioritization
Volume filters Satisfy volume requirements and constraints
Resource filters Satisfy resource requirements such as CPU, memory,

and networking
Topology filters Satisfy scheduling constraints set at the node or

pod level
Prioritization Select final container instances for placement
Demo
Amazon EKS
Amazon EKS on EC2
Other Kubernetes objects
Kubernetes volumes
apiVersion: v1
kind: Pod
metadata:
name: test-pd myApp
spec:
containers:
- image: test-webserver
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
Volume
- name: cache-volume
emptyDir: {}
Kubernetes PersistentVolume (PV)
apiVersion: v1
kind: Pod
metadata: myApp
name: test-ebs
spec:
containers:
- image: test-webserver
name: test-container
volumeMounts:
- mountPath: /test-ebs
name: test-volume
volumes:
- name: test-volume Amazon Elastic
# This AWS EBS volume must already exist. Block Store (EBS)
awsElasticBlockStore:
volumeID: <volume-id>
fsType: ext4 158
Kubernetes secrets
$ cat ./templates/secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: cGFzc3dvcmQ=
$ kubectl apply -f ./templates/secret.yaml
$ kubectl get secrets

NAME TYPE DATA AGE
mysecret Opaque 2 6s
AWS Systems Parameter Store Manager
and AWS Secrets Manager
Amazon EKS Cluster

AWS CloudTrail
PodA
PodB
PodB System Manager

Parameter Store
AWS Secrets AWS Key Management

Manager Service
Prescriptive guidance for customers
Use the right tool(s) for the job.
AWS Fargate is often an ideal place to start.
Amazon ECS is a great choice for AWS customers with

workloads beyond containers.
Amazon EKS is a great choice for AWS customers who already

use Kubernetes or prefer open-source software.
MODULE 4
Running Containers on Amazon

Web Services
Module 4 objectives
• Examine common architectural patterns on AWS

provided in the AWS Well-Architected Framework
• Investigate AWS architectural best practices in
architectural patterns
• Design methods to successfully run container
workloads on AWS
AWS Build and deploy faster
Well-Architected
Framework Lower or mitigate risks
Make informed decisions
Learn AWS best practices
Mechanism for a cloud journey
Learn Measure Improve
Understand the impact Compare architectures Identify areas for

of decisions against best practices improvement
Framework structure
Identify alignment with cloud

Questions best practices
Design principles Facilitate good design
Pillars Provide foundation for stable

and efficient systems
Framework pillars
Operational Performance Cost

Security Reliability
excellence efficiency optimization
Operational excellence design principles
• Perform operations as code

• Annotate documentation
• Make frequent, small, reversible changes
• Refine operations procedures frequently
ü AWS CloudFormation
ü AWS Config and • Anticipate failure
configuration rules
ü Amazon CloudWatch • Learn from all operational failures
ü AWS CodePipeline
ü AWS CodeCommit
Security design principles
• Implement a strong identity foundation

• Enable traceability
• Apply security at all layers
• Automate security best practices
ü Amazon Virtual Private
Cloud (Amazon VPC) • Protect data in transit and at rest
ü AWS Identity and Access
Management (IAM) • Keep people away from data
ü AWS Secrets Manager
ü Defense in depth • Prepare for security events
ü AWS Resource Tagging API
Reliability design principles
• Test recovery procedures

• Recover from failure automatically
• Scale horizontally to increase
aggregate system availability
ü AWS Auto Scaling • Stop guessing capacity
ü Infrastructure as code (IaC)
ü Managed, Multi-AZ • Manage change in automation
databases
ü Amazon Elastic File System
(Amazon EFS)
ü AWS Backup
Performance efficiency design principles
• Democratize advanced technologies

• Go global in minutes
• Use serverless architectures
• Mechanical sympathy
ü Amazon Elastic Compute
Cloud (Amazon EC2) right
sizing
ü Amazon EC2 right typing
ü Amazon CloudWatch
Container Insights
ü AWS X-Ray
ü Amazon ElastiCache
Cost optimization design principles
• Adopt a consumption model

• Measure overall efficiency
• Stop spending money on data center
operations
ü Amazon EC2 Spot Instances • Analyze and attribute expenditure
ü Amazon EC2 Reserved
Instances • Use managed services to reduce cost of
ü AWS Managed Services ownership
ü AWS Cost Explorer
ü AWS Trusted Advisor
Summary
Learn Measure Improve
Questions Design principles Pillars
Beginnings of an architecture
AWS Cloud
Public subnet Private subnet Private subnet
Front-end Backend
container container
Front-end Backend
Users Elastic container Elastic container Managed
Load Load database
Balancing Balancing service
Front-end Backend
container container
Services to consider
“How do containers authenticate to the

Security AWS Secrets Manager
database?”
Reliability AWS Auto Scaling “How do we handle spiky, uneven traffic?”
“How can we test against our production

Operational excellence AWS CloudFormation
stack?”
Performance efficiency AWS X-Ray “How can we measure the impact of latency?”
Amazon EC2 Spot

Cost optimization Instances
“How much does each container cost per hour?”
182
Sample architecture: Operational excellence
AWS Cloud
Application Network
Amazon ECS Amazon ECS
Load Balancer Load Balancer Amazon DynamoDB
Continuous integration and continuous delivery (CI/CD) workflow)

Users
AWS CodePipeline
AWS CodeCommit AWS CodeBuild Amazon ECR AWS CodeDeploy
AWS CloudFormation
Sample architecture: Security
AWS Cloud
AWS Secrets Manager AWS Security Hub

AWS IAM
Users Amazon Network

AWS Fargate Amazon ECS Amazon RDS
API Gateway Load Balancer
AWS Cloud Map AWS CloudTrail AWS Key Management Amazon GuardDuty
Service
Sample architecture: Reliability
AWS Cloud
Auto Scaling group Auto Scaling group
Amazon VPC
Amazon EKS Amazon EKS Amazon RDS

Availability
Zones
Users Application Network
Load Balancer Load Balancer
Amazon EKS Amazon EKS Amazon RDS
Sample architecture: Performance efficiency
AWS Cloud
Private subnet Private subnet
Network
Amazon ECS Amazon ElastiCache Amazon Aurora
Load Balancer
Amazon CloudFront
Users
Amazon S3
Further Analysis and Visualization
AWS X-Ray Amazon CloudWatch Amazon EventBridge AWS Glue Amazon QuickSight
Sample architecture: Cost optimization
AWS Cloud
Public subnet Private subnet Spot Fleet Private subnet
Application Network
Load Balancer AWS Fargate Load Balancer Amazon ECS Amazon DynamoDB
Infrastructure management
Users
AWS Budgets
AWS License AWS Systems
Manager Manager AWS Trusted
Advisor
AWS Cost Explorer
AWS Well-Architected Tool
Summary
In this module, you learned about:
• The AWS Well-Architected Framework as a tool for designing

and evaluating cloud-based architectures
• Design principles and best practices with concise and actionable
explanations included in the framework
• Applying the framework to container-based workloads
MODULE 5
Next Steps
Module 5 objectives
• Identify further education in topic specialties
Module 1 resources
Modern, cloud- Cloud Native

native applications Infrastructure
The Cloud Native Modernization and
Computing Foundation Migration Workshop
Microservices
Initial (2014) Definition Updated (2019)
The Twelve-Factor App
of Microservices Microservices Guide
Building
Building a Microservices:
modernization Designing
practice Fine-Grained
Modern Application YouTube Playlist Systems
Development Workshop Around Modernization
Module 2 resources
Container platforms
Docker The Open Container The OCI

Documentation Initiative Runtime Spec
Container security
APN Container AWS re:Inforce 2019
AWS Security Security Partners Session Playlist
Supplementary
tools and practices
Implementing Redefining Application
Microservices on AWS
Microservices Communications
Module 3 resources
Amazon ECS
Amazon ECS AWS Training: Amazon ECS Curated

Documentation Amazon ECS Primer Resources
AWS Fargate
Amazon ECS Amazon ECS Workshop
Using Fargate for AWS Fargate AWS Fargate CLI Tool
Kubernetes
Kubernetes Amazon EKS

Amazon EKS Workshop
Documentation Documentation
Module 4 resources
AWS Well-Architected
Framework
AWS Well-Architected AWS Well-Architected Serverless Application
Program Framework Document Lens
AWS Well-Architected
Framework tooling
AWS Well-Architected AWS Well-Architected AWS Well-
Tool Framework Hands-On Lab Architected Training
195
APN Navigate for Containers
Specialize in containers on AWS
Position containers
Gain knowledge on Prepare for the
in technical and
AWS Containers AWS Containers
selling
services Competency
opportunities
https://aws.amazon.com/partners/navigate/containers/
AWS Container Competency requirements
ü Be an Advanced Tier ü Identify with one of the ü Have four container-

APN Technology
solution categories specific case studies
Partner
ü Describe AWS ü Complete a Well ü Be under an NDA with

Competency solution Architected/Baseline
on landing page Review AWS
https://aws.amazon.com/partners/competencies/
AWS training resources
https://aws.amazon.com/training/
https://aws.amazon.com/training/path-architecting/
AWS Solutions
• Vetted by AWS architects
• Designed to be reliable,
secure, and cost effective
https://aws.amazon.com/solutions/
This is My Architecture
• Cloud architectures
from AWS Partners
and customers
• Product category
filters, such as
Containers
https://aws.amazon.com/this-is-my-architecture/
Top five takeaways
Modernization is a Start with

marathon, not a sprint. AWS Fargate.
AWS is here
to help.
Containers are Design well-architected

mature yet agile. production workloads.
Thank You
© 2019 Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission
from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. Corrections or feedback on the course, please email us at: aws-course-
[email protected]. For all other questions, contact us at: https://aws.amazon.com/contact-us/aws-training/. All trademarks are the property of their owners.

AWS+Partner+ +Containers+on+AWS+ (Technical) + +v1.0.1 Compressed

Uploaded by

Copyright:

Available Formats

AWS+Partner+ +Containers+on+AWS+ (Technical) + +v1.0.1 Compressed

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AWS+Partner+ +Containers+on+AWS+ (Technical) + +v1.0.1 Compressed

Uploaded by

Copyright:

Available Formats

AWS Partner: Containers on AWS

• AWS Technical Professional accreditation

• Discuss app modernization and DevOps, and how these practices

• Module 1: Cloud-Native Development

• Are any of your current customers

• What do you think are the reasons

• Discuss legacy application development and its

Ineffective Operational issues

Orders Orders Ordering service

Payments Payments Payment service

Inventory Inventory Inventory service

Single, monolithic service Multiple, separate services

Increase in number and

Architecture, monitoring, and

Organization and culture

Source Build Test Production

• Check in source • Compile code • Integrate with other • Deploy to production

Build Test Release

Developers Application Delivery pipeline

Build Test Release

Build Test Release

Build Test Release

Build Test Release

Build Test Release

Build Test Release

Developers Microservices Delivery pipeline

Observability Metrics Logs Traces

Architecting • Handle cross-service interactions that return errors

Local Add log

47% 79% 67%

1. Master componentizing 2. Help customers create a 3. Guide customers through

• Guide new customers towards serverless and managed services

1. Master componentizing 2. Help customers create a 3. Guide customers through

• Educate customers on the benefits of cloud-native application architecture

1. Master componentizing 2. Help customers create a 3. Guide customers through

• Design for automation, observability, alerting, and recovery

Foster cultural • Modernize development processes around technology,

Codevelopment • Perform custom development of containerized

Offer managed • Secure, manage, and operate containerized

• Describe the current evolution of compute

On-premises Virtual Containers Serverless

Architecture Operations Integration

Ø How the CPU is exposed to Ø Maintenance requirements Ø Ecosystem of vendors and

On-premises • Highest amount of customization

Virtual • Broader adoption

• Lighter and faster than virtual

On-premises servers Virtual machines

Containers Serverless functions

Established Deployment Sweet spot Fewer options but

Portability Immutability Flexibility Speed Efficiency

Portable Single, Run versions Faster Better resource

On-premises servers Virtual machines Containers

Container Container Container

Libs Libs Libs Libraries Libs

Libraries Virtualization platform Containerization platform

Operating system Operating system Operating system

Server hardware Server hardware Server hardware

Released March 2013

Tools for creating, storing, managing, and