AWS Solutions architect 7 - Hybrid and Scaling

In

Load balancing and auto-scaling

Fundamentals

  • Load balancing: distribute incoming connections across a group of servers or services
  • ELB: load of balancing is a service which provides a set of highly available and scalable load balancers
    • Classic
    • Application (ALB)
    • Network (NLB)
  • Structure

    • a node is placed in each AZ the Load Balancer is active in

    • each node gets 1/N of the traffic (N represents the number of nodes)

    • historically each node only balances instances in the AZ

    • cross-zone load balancing allows each node to distribute traffic to all instances

    • an ELB facing

      • public: accept traffic from Internet
      • internal: only accessible inside a VPC and is often used between tiers

    • ELB accepts traffic via listeners using protocols and ports

      • it can strip HTTPS at this point -> handle encryption/decryption, reduing CPU usage on instances
          graph TD

A[Client]
B[Node]
C[Node]

A --> B
A --> C

Types

  • Classic Load Balancers (CLB)

    • oldest type, nowdays it should be avoided

      • support Layer 3 and 4 (TCP, SSL) and some HTTP/S features
      • it is not a layer 7 device, so no real HTTP/S
      • 1 SSL certificate per CLB - can get expensive for complex projects
      • can offload SSL connections - HTTPS to the load balancer and HTTP to the instance (lower CPU and admin overhead on instances)
      • can be associated with autoscaling groups
      • DNS a record is used to connect to the CLB

    • health check

      • configured to check the health of any attached services
      • if a problem is detected, incoming connections won’t be routed to instances until it returns to health
      • CLB health checks can be TCP, HTTP, HTTPS and SSL based on ports 1-65635
        • with HTTP/S checks, a HTTP/S path can be tested
          graph LR

A[Route53]
B[ELB]

subgraph zoneA
  C[instance]
  D[instance]
end

subgraph zoneB
  E[instance]
  F[instance]
end

A --> B;
B --> C;
B --> D;
B --> E;
B --> F;

  • Application Load Balancers (ALB)

    • operates at layer 7 of the OSI model

    • recommended nowdays as default LB for VPCs (better performance, usually cheaper)

    • content rules can direct certain traffic to specific target groups

      • host-based rules: route traffic based on the host used
      • path-based rules: route traffic based on URL path

    • ALB support EC2, ECS, EKS, Lambda, HTTP, HTTP/2 and websockets -> this targets can be integrated with firewall (WAF)

    • use an ALB if you need to use containers or microservices

    • targets -> target groups -> content rules (targets can be in multiple target groups)

    • an ALB can host multiple SSL certificates using SNI

          graph LR

A(Internet)
B[ALB]
C[listener and rule]
D[listener and rule]

subgraph zoneA
  E[instance]
  F[instance]
end

G[instance]

subgraph zoneB
  H[instance]
  I[instance]
end

A --> B;
B --> C;
B --> D;
C --> E;
C --> F;
C --> G;
D --> G;
D --> H;
D --> I;

  • Network Load Balancers (NLB)

    • newest type of balancers, operate at layer 4

    • benefits vs ALB

      • support other protocols
      • support groups
      • less latency (no processing above Layer 4 is required)
      • IP addressable - static address
      • bets load performance balancingwithin AWS
      • source IP address preservation - packets unchanged
      • targets can be addressed using IP address
          graph LR

A[NLB]
B[TCP 8080 - listener and rule]
C[TCP 80 - listener and rule]

subgraph TGroup1
  D[IP-1]
  E[IP-2]
end

subgraph TGroup2
  F[IP-3]
  G[IP-4]
end

A --> B;
A --> C;
B --> D;
B --> E;
C --> F;
C --> G;

Templates and configurations

  • Configure attributes on EC2 instances via launch templates and launch configuration
  • Configurations (what should be provisioned)
    • AMI to use for EC2 launch
    • instance type
    • storage
    • key pair
    • IAM role
    • user data
    • purchase options
    • network configuration
    • security groups
  • Templates: address some weaknesses of legacy launch configurations and add the following features
    • versioning and inheritance
    • tagging
    • more davanced purchasing options
    • new instance features, including:
      • elastic graphics
      • T2/T3 ulimited settings
      • placement groups
      • capacity reservations
      • tenancy options
  • Launch templates should be used over launch configurations where possible
  • Neither can be edited after creation: anew version of the template or a new launch configuration should be created

Auto scaling groups

  • Autoscaling groups use lanch configurations or launch templates and allow automatic scale-out or scale-in based on configurable metrics(usually paired with ELBs)

  • Define ‘minimum size’, ‘desired capacity’ and ‘maximum capacity’

    • can be configured to use multiple AZs to improve high availability
    • unhealty instances are terminated and recreated
    • ELB checks or EC2 status can be used

  • metrics such as CPU utilization to network transfer can be used either to scale out or scale in using scaling policies

    • scaling type
      • manual
      • scheduled
      • dynamic
    • cooldowns can be defined to ensure rapid in/out events don’t occur
    • scaling policies
      • simple
      • step scaling
      • target tracking

  • stress tests extras required

    1
    2
    3
    sudo amazon-linux-extras install epel -y
    sudo yum install stress -y
    stress --cpu 2 --timeout 30000

VPN and Direct Connect

VPC VPN (IPsec)

  • VPC Virtual Private Networks provide a software-based secure connection between a VPC and on-premises networks
  • Components
    • Virtual Private Cloud (VPC)
    • Virtual Private Gateway (VPG) attached to a VPC
    • Customer Gateway (CGW) - configuration for on-premises router
    • VPN connection (using 1 or 2 IPsec tunnels)
  • Best practices

    • use dynamic VPNs (uses BPG) where possible

    • connect both tunnels to your CGW - VPC VPN is HA by design

    • where possible, use 2 VPN connections and 2 CGWs

    • speed (without Direct Connect Partner): 1 or 10 Gbps

          graph LR

subgraph VPC
  A((VPC router))
  B((VPG))
  C((Tunnel endpoint A))
  D((Tunnel endpoint B))
end

subgraph datacenter
  H((CGW-1))
  I((CGW-2))
end

E(VPN-1);
F(VPN-2);

A --> B;
B --> C;
B --> D;
C --> E;
C --> F;
D --> E;
D --> F;
E --> H;
F --> I;

Direct Connect architecture

  • Direct Connect (DX): physical connection between your network and AWS either directly via a cross-connect and a customer router at a DX location or via DX partner
  • Dedicated Connections are via AWS and a use single-mode fiber, running either 1Gbps using 1000base-LX or 10GBASE-LR
  • Virtual Interfaces (VIF) run on top of a DX

    • public VIFs can access AWs public services such as S3 only

    • private VIFs are used to connect into VPCs. DX is not highly available or encrypted

          graph LR

subgraph AWS cloud
  A((VGW on VPC))
  B[S3]
  C[DynamoDB]
end

subgraph DX location
  D[AWS direct connect]
  E((Customer or partner router))
end

subgraph Customer
  F((Customer on-premises router))
end

A --> D;
B --> C;
C --> D;
D --> E;
E -- private VIF --> F;
E -- public VIF --> F;

Direct Connect vs. VPN

  • VPN
    • urgent need - can be deployed in minutes
    • cost constrained - cheap and economical
    • low end or consumer hardware - DX requires BGP
    • encryption required
    • flexibility to change locations
    • highly available options available
    • short-term connectivity (DX generally has a physical minimum due to the physical transit connections required) - not applicable if you are in a DX location because then it’s almost on demand
  • Direct Connect
    • higher throughput
    • consistent performance (throughput)
    • consitent low latency
    • large ammounts of data - cheaper than VPN for higher volume
    • no contention with existing Internet connection
  • Both
    • VPN as a cheaper HA option for DX
    • VPN as an additional layer HA (in addition to 2 DX)
    • if some form of connectivity is needed immediatly, VPN provides it before the DX connection is live
    • can be used to add encryption over the top of a DX (public VIF/VPN)

Snow*

  • Methods for moving large ammounts of data quicky out of AWS

  • Don’t need to worry about writing code or the speed or data allocation of your Internet, VPN or DX connection

  • You can log a job and receive an empty device or one full of data requested -> perform copy with your usual tooling and ship the device back

  • Types

    • Snowball
      • for in or out jobs
      • log a job and an mepty device or device with data is shipped
      • ideal for TB or PB data transfers - 5p TB or 80 TB capacity per snowball
      • 1 Gbps (RJ45 1 Gbase-TX) or 10 Gbps (LR/LS) using a SFP
      • data encryption using KMS
      • generally used from 10 TB -> 10 PB (the enconomical range)
      • larger jobs or multiple locations can use multiple snowballs
      • end-to-end process time is low for the ammount ofa data week(s)
    • Snowball Edge
      • includes both storage and compute
      • larger capacity
      • 10 Gbps (RJ45), 10/25 Gbps (SFP), 45/50/100 Gbps (QSFP+)
      • compute can be used for local instances or lambda functionality
      • 3 versions
        • edge storage optimized: 80 TB, 24vCPU and 32 GiB RAM
        • edge compute optimized: 100 TB + 7.68 TB NVMe, 52vCPUs, and 208 GiB RAM
        • edge compute opttimized with GPU: as above with GPU equivalent to P3 EC2 instance
    • Snowmobile
      • poratble storage data center within a shipping container on a semi track
      • available inc ertain areas via special order AWS
      • used when a single location 10 PB+ is required
      • each snowmobile can transfer up to 100 PB
      • not economical ofr sub 10 PB and where multiple locations are required
      • situated on side and connected to your data center for the duration of the transfer

Data and DB migration

Storage Gateway

  • Hybrid storage service that allows you to migrate data into AWS, extending your on premises storage capacity using AWS
  • Types
    • File gateway (can be accessed directly from S3, volumens can use an AWS-deployed Storage Gateway)
    • Volumen gateway (Volume -> provide block storage in S3 with point-in -time backups as EBS snapshots)
    • Tape gateway (VTL)

AWS DMS

  • AWS Database Migration Service: service to migrate relational databases, it can migrate to and from any locations with network connectivity to AWS

    • compatible with broad range of DB sources, ibcluding Oracle, MsSQL, MySQL, MariaDB, PostgresSQL, MongoCD, Aurora and SAP

    • data can be synced to most of the above engines, as well as REdshift, S3 and DynamoDB

    • you can also use the Schema Conversion Tool (AWS SCT) to trasnform between different database engines as part of a migration

          graph LR

A((soure))

subgraph AWS DMS
  B(Source Endpoint)
  C[Replication task on replication instance]
  D(Destination Endpoint)
end

E((Target))

A --> B;
B --> C;
C --> D;
D --> E;

  • with DMS at a high level, you can providion a replication instance, define source and destination endpoints that popint at asource and target databases, and create a replication task. DMS handles the rest, and you can continue using your database while the process runs. DMS is useful ina number of uncommon scenarios:

    • scaling database resources up or donw without downtime
    • migrating databases from on-premises to AWS, from AWS to on-premises, or from/to other cloud platforms
    • moving data between different DB engines, including schema conversion
    • partial/subset data migration
    • migration with little to no admin overhead, as a service

Identity Federation and SSO

IDF

  • Identity Federation (IDF) is an architecture where identities of an external identity provider (IDP)a re recognized. Single sign-on (SSO) is wether the credentials of an external identity are used to allow access to local systems (e.g. AWS)

  • Types

    • Cross-account roles: a remote account (IDP) is allowed to assume a role and access your account’s resources
    • SAML 2.0 IDF: an on-premises or AWS-hosted directory service instance is configured to allow Active Directory users to log in to the AWS console
    • Web Identity Federation: IDPs such as Google, Amazon and FAcebook are allowed to assume roles and access resources in your account

  • Cognito and the Secure Token Service (STS) are used for IDF

  • A federated identity is verified using an external IDP and by proving the identity (using token or assertion of some kind) is allowed to swap that ID for temporary AWS credentials by assuming a role

  • SAML 2.0 structure

        graph LR

  subgraph AWS cloud
    D[AWS SSO endpoint]
    E[STS]
    F[Role]
    G[AWS console]
  end

  subgraph enterprise identity provider
    A[enterprise desktop]
    B[IDP -ADSF]
    C(Identity Store)
  end

  A -- login ADFS portal --> B;
  B -- authenticate store --> C;
  C -- authenticated store --> B;
  B -- token asertion SAML --> A;
  A -- login AWS console --> G;
  A -- post SAML assertion--> D;
  D -- redirect AWS temp credentials --> A;
  D --> E;
  D --> F;

  • Web identity structure

        graph LR

  A[application Web or mobile]
  B(user)
  C((Google ID provider))

  subgraph AWS cloud
    D[STS temp credentials]
    E[Amazon Cognito]
    F[Amazon DynamoDB]
  end

  A -- anonymous usage --> B;
  A -- redirect for login --> C;
  C -- token --> A;

  C --> D;
  C -- token exchange Google/Cognito --> E;
  C -- resource access Temp Credentials --> F;

When to use Identity Federation

  • How to use IDF + when to use IDF
    • Enterprise access to AWS resources
      • users/staff have existing pool of identities
      • you need those identities to be used across all enterprise systems, including AWS
      • access to AWS resources using SSO
      • potentially 10.000+ users, more than IAM can handle
      • you might have an ID team within your business
    • Mobile and web apps
      • mobile/webapp requires access to AWS resources
      • you need a certain level of guest acccess (and extra once logged in)
      • customers have other identities (Google, Twitter, Facebook…) and you need to use those
      • tou do not want credentials stored on your application
      • could be millions or more users - beyond capabilities of IAM
      • customers might have multiple 3rd party logins, but they represent 1 real person
    • Centralized Identity Management (AWs accounts)
      • <1000 AWS ccounts in an organization
      • need central sore of IDs -either IAM or external provider
      • role switching used from and ID account into member accounts