Cloud Computing Session 2:

Basics of Amazon Web Services

Kyndryl Internal 1
Several Historical Trends

• Shared Utility Computing

• 1960s – MULTICS – Concept of a Shared Computing Utility
• 1970s – IBM Mainframes – rent by the CPU-hour. (Fast/slow switch.)
• Data Center Co-location
• 1990s-2000s – Rent machines for months/years, keep them close to the network
access point and pay a flat rate. Avoid running your own building with utilities!
• Pay as You Go
• Early 2000s - Submit jobs to a remote service provider where they run on the raw
hardware. Sun Cloud ($1/CPU-hour, Solaris +SGE) IBM Deep Capacity Computing
on Demand (50 cents/hour)
• Virtualization
• 1960s – OS-VM, VM-360 – Used to split mainframes into logical partitions.
• 1998 – VMWare – First practical implementation on X86, but at significant
performance hit.
• 2003 – Xen paravirtualization provides much perf, but kernel must assist.
• Late 2000s – Intel and AMD add hardware support for virtualization.

Kyndryl Internal 2
Amazon Web Services is born!!

• Grew out of Amazon’s need to rapidly provision and configure

machines of standard configurations for its own business.
• Early 2000s – Both private and shared data centers began using
virtualization to perform “server consolidation”
• 2003 – Internal memo by Chris Pinkham describing an
“infrastructure service for the world.”
• 2006 – S3 first deployed in the spring, EC2 in the fall
• 2008 – Elastic Block Store available.
• 2009 – Relational Database Service
• 2012 – DynamoDB
• Does it turn a profit?

Kyndryl Internal 3
 AWS – Economy of Scale
!"# $%&'%$ ('%& ) *+,,+(- )./+'% .0$/(*%&$ +- *(&% /1)- 234 .(0-/&+%$ )-5 /%&&+/(&+%$6 "% )&% $/%)5+,78
%9:)-5+-;8;,(<),8+-=&)$/&0./0&%8/(81%,:8(0&8.0$/(*%&$8).1+%'%8,(>%&8,)/%-.78)-581+;1%&8/1&(0;1:0/?8
)-5 /( %-$0&% /1)/ /1%+& 5)/) &%$+5%$8(-,7 +- /1% !"# @%;+(- /1%7 $:%.+=76 !$ (0& .0$/(*%&$ ;&(> /1%+&8
<0$+-%$$%$? !"# >+,, .(-/+-0% /( :&('+5% +-=&)$/&0./0&% /1)/ *%%/$ /1%+& ;,(<), &%A0+&%*%-/$6
B1%8!"#8C,(058+-=&)$/&0./0&%8+$8<0+,/8)&(0-58!"#8@%;+(-$8)-58!')+,)<+,+/78D(-%$68!-8!"#8@%;+(-8+$8)8
:17$+.),8,(.)/+(-8+-8/1%8>(&,58>1%&%8>%81)'%8*0,/+:,%8!')+,)<+,+/78D(-%$68!')+,)<+,+/78D(-%$8.(-$+$/8(=8
(-%8(&8*(&%85+$.&%/%85)/)8.%-/%&$?8%).18>+/18&%50-5)-/8:(>%&?8-%/>(&E+-;?8)-58.(--%./+'+/7?81(0$%58
+-8$%:)&)/%8=).+,+/+%$68B1%$%8!')+,)<+,+/78D(-%$8(F%&87(08/1%8)<+,+/78/(8(:%&)/%8:&(50./+(-8)::,+.)/+(-$8
)-5 5)/)<)$%$ /1)/ )&%8*(&% 1+;1,7 )')+,)<,%? =)0,/ /(,%&)-/? )-5 $.),)<,% /1)- >(0,5 <% :($$+<,% =&(*8 )
$+-;,% 5)/) .%-/%&6 B1% !"# C,(05 (:%&)/%$ +- G4 !')+,)<+,+/7 D(-%$ >+/1+- 2H ;%(;&):1+. @%;+(-$
)&(0-5 /1% >(&,5? >+/1 )--(0-.%5 :,)-$ =(& *(&% !')+,)<+,+/7 D(-%$ )-5 @%;+(-$6
I).18!*)J(-8@%;+(-8+$85%$+;-%58/(8<%8.(*:,%/%,78+$(,)/%58=&(*8/1%8(/1%&8!*)J(-8@%;+(-$68B1+$8
).1+%'%$8/1%8;&%)/%$/8:($$+<,%8=)0,/8/(,%&)-.%8)-58$/)<+,+/768I).18!')+,)<+,+/78D(-%8+$8+$(,)/%5?8<0/8/1%8
!')+,)<+,+/78D(-%$8+-8)8@%;+(-8)&%8.(--%./%58/1&(0;18,(>K,)/%-.78,+-E$68!"#8:&('+5%$87(08>+/18/1%8
L%9+<+,+/7 /( :,).% +-$/)-.%$8)-5 $/(&% 5)/) >+/1+- *0,/+:,% ;%(;&):1+. &%;+(-$ )$ >%,, )$ ).&($$ *0,/+:,%8
!')+,)<+,+/7 D(-%$ >+/1+- %).1 !"# @%;+(-6 I).1 !')+,)<+,+/7 D(-% +$ 5%$+;-%5 )$ )- +-5%:%-5%-/ =)+,0&%8
J(-%68B1+$8*%)-$8/1)/8!')+,)<+,+/78D(-%$8)&%8:17$+.),,78$%:)&)/%58>+/1+-8)8/7:+.),8*%/&(:(,+/)-8&%;+(-8
)-58)&%8,(.)/%58+-8,(>%&8&+$E8L((58:,)+-$8M$:%.+N.8L((58J(-%8.)/%;(&+J)/+(-8')&+%$8<78!"#8@%;+(-O68P-8
)55+/+(-8/(85+$.&%/%80-+-/%&&0:/+<,%8:(>%&8$0::,78MQR#O8)-58(-$+/%8<).E0:8;%-%&)/+(-8=).+,+/+%$?85)/)8
.%-/%&$ ,(.)/%5 +- 5+F%&%-/ !')+,)<+,+/78D(-%$ )&% 5%$+;-%5 /( <% $0::,+%5 <7 +-5%:%-5%-/8$0<$/)/+(-$8
/(8&%50.%8/1%8&+$E8(=8)-8%'%-/8(-8/1%8:(>%&8;&+58+*:)./+-;8*(&%8/1)-8(-%8!')+,)<+,+/78D(-%68!')+,)<+,+/78
D(-%$8)&% ),, &%50-5)-/,7 .(--%./%5 /( *0,/+:,% /+%&KS /&)-$+/ :&('+5%&$6
Kyndryl Internal 4
AWS – Economy of Scale

Kyndryl Internal 5
AWS – Global Infrastructure

Kyndryl Internal 6
 AWS – Regions

AWS has the concept of a Region, which is a physical location around the
world where we cluster data centers. We call each group of logical data
centers an Availability Zone. Each AWS Region consists of multiple, isolated,
and physically separate AZs within a geographic area. Unlike other cloud
providers, who often define a region as a single data center, the multiple AZ
design of every AWS Region offers advantages for customers. Each AZ has
independent power, cooling, and physical security and is connected via
redundant, ultra-low-latency networks. AWS customers focused on high
availability can design their applications to run in multiple AZs to achieve even
greater fault-tolerance. AWS infrastructure Regions meet the highest levels of
security, compliance, and data protection.
AWS provides a more extensive global footprint than any other cloud provider,
and to support its global footprint and ensure customers are served across the
world, AWS opens new Regions rapidly. AWS maintains multiple geographic
Regions, including Regions in North America, South America, Europe, China,
Asia Pacific, South Africa, and the Middle East.
Kyndryl Internal 7
 AWS – Regions

Latency – Regions can be selected to be close to the targeted user base to

reduce data latency
Cost – AWS provides the same set of services across all regions, usually,
however, the cost would differ from region to region depending upon the cost
(due to land, electricity, bandwidth, etc) incurred by Amazon and hence can be
cheaper in one region compared to the other
Legal Compliance – A lot of the countries enforce compliance and regulatory
requirements for data to reside within the region itself
Features – As not all the regions provide all the AWS features and services, the
region selection can depend on the Services supported by the region

Kyndryl Internal 8
 AWS – Availability Zones

An Availability Zone (AZ) is one or more discrete data centers with redundant
power, networking, and connectivity in an AWS Region. AZs give customers the
ability to operate production applications and databases that are more highly
available, fault tolerant, and scalable than would be possible from a single
data center. All AZs in an AWS Region are interconnected with high-bandwidth,
low-latency networking, over fully redundant, dedicated metro fiber providing
high-throughput, low-latency networking between AZs. All traffic between AZs
is encrypted. The network performance is sufficient to accomplish
synchronous replication between AZs. AZs make partitioning applications for
high availability easy. If an application is partitioned across AZs, companies are
better isolated and protected from issues such as power outages, lightning
strikes, tornadoes, earthquakes, and more. AZs are physically separated by a
meaningful distance, many kilometers, from any other AZ, although all are
within 100 km (60 miles) of each other.

Kyndryl Internal 9
Architected for Enterprise Security Requirements

Certifications and accreditations AWS CloudTrail - AWS API call logging

for workloads that matter for governance & compliance

Log and review user

activity
Stores data in Amazon
S3, or archive to
Amazon Glacier

Kyndryl Internal 10
Magic Quadrant for Cloud Infrastructure as a Service,
Worldwide (2021)

Kyndryl Internal 11
AWS Bouquet of Services

Kyndryl Internal 12
Terminology

q Instance = One running virtual machine.

q Instance Type = hardware configuration: cores, memory, disk.
q Instance Store Volume = Temporary disk associated with
instance.
q Image (AMI) = Stored bits which can be turned into instances.
q Key Pair = Credentials used to access VM from command line.
q Region = Geographic location, price, laws, network locality.
q Availability Zone = Subdivision of region the is fault-
independent.

Kyndryl Internal 13
EC2 Pricing Model

• Free Usage Tier

• On-Demand Instances
• Start and stop instances whenever you like, costs are
rounded up to the nearest hour. (Worst price)
• Reserved Instances
• Pay up front for one/three years in advance. (Best price)
• Unused instances can be sold on a secondary market.
• Spot Instances
• Specify the price you are willing to pay, and instances get
started and stopped without any warning as the marked
changes.
http://aws.amazon.com/ec2/pricing/
Kyndryl Internal 14
Free Usage Tier
• 750 hours of EC2 running Linux, RHEL, or SLES t2.micro
instance usage
• 750 hours of EC2 running Microsoft Windows Server t2.micro
instance usage
• 750 hours of Elastic Load Balancing plus 15 GB data processing
• 5 GB of Amazon Elastic Block Storage in any combination of
General Purpose (SSD) or Magnetic, plus 2 million I/Os (with
Magnetic) and 1 GB of snapshot storage
• 15 GB of bandwidth out aggregated across all AWS services
• 1 GB of Regional Data Transfer
https://aws.amazon.com/free/?all-free-tier.sort-
by=item.additionalFields.SortRank&all-free-tier.sort-
order=asc&awsf.Free%20Tier%20Types=*all&awsf.Free%20Tier%2
0Categories=*all Kyndryl Internal 15
Simple Storage Service (S3)
• A bucket is a container for objects and describes location,
logging, accounting, and access control. A bucket can hold any
number of objects, which are files of up to 5TB. A bucket has a
name that must be globally unique.
• Fundamental operations corresponding to HTTP actions:
• http://bucket.s3.amazonaws.com/object
• POST a new object or update an existing object.
• GET an existing object from a bucket.
• DELETE an object from the bucket
• LIST keys present in a bucket, with a filter.
• A bucket has a flat directory structure (despite the appearance
given by the interactive web interface.)

Kyndryl Internal 16
S3 Bucket Properties
• Versioning – If enabled, POST/DELETE result in the creation of
new versions without destroying the old.
• Lifecycle – Delete or archive objects in a bucket a certain time
after creation or last access or number of versions.
• Access Policy – Control when and where objects can be
accessed.
• Access Control – Control who may access objects in this
bucket.
• Logging – Keep track of how objects are accessed.
• Notification – Be notified when failures occur.

Kyndryl Internal 17
Elastic Block Store – EBS
• An EBS volume is a virtual disk of a fixed size with a block
read/write interface. It can be mounted as a filesystem on a
running EC2 instance where it can be updated incrementally.
Unlike an instance store, an EBS volume is persistent.
• (Compared to an S3 object, which is essentially a file that must
be accessed in its entirety.)
• Fundamental operations:
• CREATE a new volume (1GB-1TB)
• COPY a volume from an existing EBS volume or S3 object.
• MOUNT on one instance at a time.
• SNAPSHOT current state to an S3 object.

Kyndryl Internal 18
EBS is approx. 3x more expensive by volume and 10x
more expensive by IOPS than S3.

Kyndryl Internal 19
Glacier for Cold Data
• Glacier is structured like S3: a vault is a container for an arbitrary
number of archives. Policies, accounting, and access control are
associated with vaults, while an archive is a single object.
• However:
• All operations are asynchronous and notified via SNS.
• Vault listings are updated once per day.
• Archive downloads may take up to four hours.
• Only 5% of total data can be accessed in a given month.
• Pricing:
• Storage: $0.01 per GB-month
• Operations: $0.05 per 1000 requests
• Data Transfer: Like S3, free within AWS.
• S3 Policies can be set up to automatically move data into Glacier.

Kyndryl Internal 20
Durability
• Amazon claims about S3:
• Amazon S3 is designed to sustain the concurrent loss of data in two
facilities, e.g., 3+ copies across multiple available domains.
• 99.999999999% durability of objects over a given year.
• Amazon claims about EBS:
• Amazon EBS volume data is replicated across multiple servers in an
Availability Zone to prevent the loss of data from the failure of any single
component.
• Volumes <20GB modified data since last snapshot have an annual failure
rate of 0.1% - 0.5%, resulting in complete loss of the volume.
• Commodity hard disks have an AFR of about 4%.
• Amazon claims about Glacier is the same as S3:
• Amazon S3 is designed to sustain the concurrent loss of data in two
facilities, e.g., 3+ copies across multiple available domains PLUS periodic
internal integrity checks.
• 99.999999999% durability of objects over a given year.

• Beware of oversimplified arguments about

Kyndryl Internal low-probability events! 21
Strategies for Migrating Applications to the Cloud

Kyndryl Internal 22
 6 Application Migration Strategies: “The 6 R’s”

• The 6 most common application migration strategies we see are:

1. Rehosting — Otherwise known as “lift-and-shift.
• Most rehosting can be automated with tools (e.g. CloudEndure Migration,
AWS VM Import/Export), although some customers prefer to do this manually
as they learn how to apply their legacy systems to the new cloud platform.

2. Replatforming — I sometimes call this “lift-tinker-and-shift.”

• You aren’t otherwise changing the core architecture of the application. You
may be looking to reduce the amount of time you spend managing database
instances by migrating to a database-as-a-service platform like Amazon
Relational Database Service (Amazon RDS), or migrating your application to a
fully managed platform like Amazon Elastic Beanstalk.

3. Repurchasing — Moving to a different product.

• I most commonly see repurchasing as a move to a SaaS platform. Moving a
CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, and so on.
Kyndryl Internal 23
 6 Application Migration Strategies: “The 6 R’s”

4. Refactoring / Re-architecting — Re-imagining how the application is

architected and developed, typically using cloud-native features.
• This is typically driven by a strong business need to add features, scale, or
performance that would otherwise be difficult to achieve in the application’s
existing environment.

5. Retire — Get rid of.

6. Retain — Usually this means “revisit” or do nothing (for now)..

Kyndryl Internal 24
Thank you!

Kyndryl Internal 25