Amazon Web Services Building Blocks

A high level review of the basic AWS building blocks

 

Its possible to explore the AWS documentation on each product. Direct access to documentation is possible via https://docs.aws.amazon.com/index.html#lang/en_us

·         AWS Global Infrastructure

Regions – geographical regions available around the globe. Separate entities and resources are not replicated by default

https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/

Availability Zone. Regions break down into two or more  DC availability zones, each physically distinct, but connected via multiple transit providers

Edge Locations. Availability zones host Content Delivery Networks – Amazon Cloudfront. Delivers content to customers. Typically located in high population zones.

·         Amazon Virtual Private Cloud

A private, virtual network in the AWS Cloud. Uses many of the services as would be deployed in a DC with capabilities abstracted for deployment.

Amazon VPCs live within regions and can span between multiple AZs. Can be private or assigned a public ip address via a gateway

lt tolerance.

Security Groups
SGs act like a built in firewall to secure instances. Separate SGs can be defined for each instance e.g. web, application and database tiers. Rules can be applied to each security group.

Compute Services
Compute services that can be run at required scale. This includes virtual servers, containers or code.

Amazon Elastic Compute Cloud (EC2)
Pay as you go HW/SW. Via AWS Console, choose region, EC2 launch wizard, select SW or AMI (Amazon Machine Image), instance type or HW selection defining resources, network, storage, key pairs (for secure SSH and http access) and then launch. SSH access can then be made via putty.

AWS Lamda
Running compute without having to provision servers. Serverless compute service i.e. can  run code only when needed. Zero server admin.  Has resource limits, and billed on number of code executions.

AWS Elastic Beanstalk
Platform as a service. Orchestrates deployment for the various amazon web services, providing a higher layer of abstraction.  Enables an application to be added, and the required environment will be created via a wizard. Required instances, network, DB etc will be created in the background.

Application Load Balancer
Provides the ability to route requests to various targets/instances, dependant on configured rule sets.  Target groups and health checks can be defined.

Elastic Load Balancer
Classic load balancer functionality e.g. distributes traffic via round robin, and weight flows, sticky sessions, health monitors. Distribute traffic across AZs.  Can point CNAMEs to ELB.

Auto Scaling
Ensures the correct number of EC2 instances are provisioned. Auto scaling will auto provision EC2 instances when required. A launch configuration is required, an autoscaling group, and an autoscaling policy. Cloud Watch alarms can be used to trigger an autoscaling launch.

Amazon Elastic Block Store (EBS)
EBS can use HDD/SSD.  Supports snapshots and restore across regions. Encryption.  Configurable via Volumes on the EC2 dashboard.

Amazon Simple Storage Service (S3)
Managed storage service. Do not have to be tied to instances. Can be access via Management Console, CLI or SDKs.

Amazon Glacier
Managed data archiving solution. Designed for storing ‘cold’ data that needs to be retained at low cost. Files stored in archives and vaults and controlled by an access policy. Various retrieval standards: Bulk, standard and expedited.

Amazon Relational Database Service
Allows DB instances to be created. MYSQL, SQL Server, Amazon Aurora,PostrgreSQL, Oracle,MariaDB. Can be Magnetic,SSD. Transactions can be replicated to to multiple AZs

Amazon Dynamo DB
NoSQL database service. Table storage. SSD drive and low latency queries.

Amazon Redshift
DataWarehouse. Query optimisation across large datasets.

AWS Trusted Advisor
Allows tracking of provisioned resources within account. Shows cost optimisation, performance, security and fault tolerance.

TLS 1.3

TLS (Transport Layer Security) 1.2 has been a mainstay of web based secure communication for more than eight years. In August 2018 TLS1.3 was published. In this post I look at the main new features that make this faster and more secure.

TLS1.2

Client sends an hello sharing support cipher suites. The server responds with its selected cipher suite

The client then sends key exchange data and the server responds.

In total there is a four way handshake to set up the connection

 

TLS1.3

Client sends an hello sharing support cipher suites AND a suggested cipher, and key.

Provided the server agrees with the suggested key, the handshake can be completed in one round trip i.e.a two way handshake only.   Hence TL1.3 session can be completed more quickly and allow encrypted data exchange to be started in a shorter timeframe.

 

Session Resumption

In TLS1.2 a two way handshake is required for session resumption. The Client sends a Session Ticket, and the server confirms. 

TLS1.2 session resumption

 

TLS1.3 session resumption

In TLS1.3 NO handshake maybe required to resume data exchange. The session ticket is sent at the same time as the HTTP data. This quick resume is ONLY possible for exchanges that are ‘read only’. For other requests such as a POST a two way handshake is still required. This is a security requirement to prevent replay attacks.

 

TLS1.3 also enhances security by implementing forward secrecy for session resumption.  Without forward secrecy and the session ticket is compromised previous sessions can be decrypted. TLS 1.2 resumption does NOT offer any forward secrecy for session resumption. TLS 1.3 implements Forward Secrecy in this instance.  TLS1.3 session resumption implements a new key share (rather than use the previous PSK – pre-shared key).

Other security enhancements in TL1.3. Removal of vulnerable encryption algorithms e.g. static RSA handshake (DROWN), CBC MTE Modes (POODLE), Fixed DHE groups (LogJam).  TLS1.3 also implements a mechanism to prevent downgrade attacks to ver 1.2 TLS.