Cloudfront and Global Accelerator

  • Cloudfront speeds up distribution of static and dynamic content through edge location.
  • If content is not available in CF Point of presence and regional cache it is retrieved from origin - which can be S3 or Web Server (EC2) or ELB or API gateway.  When using EC2 custom origin having redundant server helps.
  • Content in S3 can be private and be accessed with signed URLs or signed cookies.  If they are public they can be accessed directly. 
  • When S3 
  • The default domain of cloudfront distribution can be modified to custom domains.
  • Min expiry time for cache is 0 secs and no max limit.
  • When caching is enabled CF can retrieve objects whose max size < 30 GB. When Caching is disable it can retrieve the object from origin. Range Gets can be used to retrieve large objects.
  • We can define geo-restrictions to prevent users from certain countries .
  • Use cases
    • Accelerate static content delivery
    • Video live streaming
    • Serve private content using Lambda@Edge - Basically its public content and we want to restrict access to certain users (for example paid service). 
      • Users can access your private content using CF signed URLs. 
      • Access to origin can be restricted.
    • Using a public key @ cloudfront we can even do field level encryption of sensitive data upto 10 fields per Post request. Origin can use the private key to access the encrypted data.
    • Running serverless code@edge - Function running on edge are called edge functions - they can be Cloudfront or Lambda functions. 
      • CF functions are based on Javascript. 
      • CF functions can handle only viewer request/response and they cant connect with FS, Network and they are submillisecond duration and free.
      • CF functions are ideal for short running functions like 
        • cache key normalization
        • header manipulation
        • URL redirects
        • Validate JWTs
      • Lambda functions are based on Node/Python. 
      • Lambda functions can access Network, FS and which can run upto 5 secs(response to viewer) and 30 secs (response to origin). 
      • Lambda functions are ideal for
        • functions that require adjustable CPU/Memory
        • functions that require network or fs access or access http body
  • Origin failover - We can specify a secondary origin when the primary fails for CF to switch to. Upto 25 origins per distribution can be supported. 10 origin groups per distribution.
  • Policies
    • Cache Policy - You can specify the http headers, cookies and query strings that can be used in Cache keys.
    • Origin request policy - You can specify the http headers, cookies and query strings that can be used in origin requests. By default host, useragent and x-amz-cf-id header tags will be sent.
    • Response header policy - You can specify the headers which get added to response before being sent to clients. 
  • Use CF to secure and restrict content access
    • Config https connections
    • Prevent users in certain Geos
    • WAF for access control
    • Field level encryption
    • CF signed urls for restricting to select customers
  • Improving Cache Hit ratio 
    • CF Origin Shield - To optimize CF from using cache instead of origin servers and hence reduce load on origin servers.
    • Origin Shield - Amazon CloudFront announces Origin Shield, a centralized caching layer that helps increase your cache hit ratio to reduce the load on your origin. Origin Shield also decreases your origin operating costs by collapsing requests across regions so as few as one request goes to your origin per object. You can also use Lambda@Edge with Origin Shield to enable advanced serverless logic like dynamic origin load balancing.  Once enabled, CloudFront will route all origin fetches through Origin Shield, and only make a request to your origin if the content is not already stored in Origin Shield's cache.
    • When using query strings - use less parameters, parameters in same order, using same case
  • If origin does not respond or times out, CF continues to serve cached content.
  • CF service activity is logged to Cloudtrail logs.
  • The CF requests are logged to Cloudwatch logs.
  • The logs can be standard or real time. The real time can be delivered to Kinesis data streams.
  • Connecting with WAF
    • The cloudfront access logs are written to S3.
    • Connect a Lambda function to read the S3 logs for anomalies or suspicious behavior.
    • In such case Lambda automatically updates WAF to block subsequent requests from the IP for defined time
    • Even rate based block-listing can be applied use pre-built CF templates for WAF. 
  • Cloudfront Price class - You can have a price class for all global regions. For a cost advantage you can have it for specific regions, but there could be some increased latency in such case.
  • CloudFront does not support client authentication with client-side SSL certificates. If an origin requests a client-side certificate, CloudFront drops the request.
  •  If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation and isn’t dedicated to your distribution.
  • You can use CloudFront with the on-premises website as the origin. CloudFront is a highly available, scalable service that can cache frequently accessed files on the website and can significantly make the load times faster.
  • CloudFront caches content at edge locations for a period of time that you specify. If a visitor requests content that has been cached for longer than the expiration date, CloudFront checks the origin server to see if a newer version of the content is available. If a newer version is available, CloudFront copies the new version to the edge location. 
  • Amazon CloudFront signed URLs and signed cookies provide the same basic functionality: they allow you to control who can access your content.
  • Use signed URLs for 
    1. When your users are using a client that doesn’t support cookies.
    2. You want to restrict access to individual files
    3. You want to use an RTMP distribution.
  • Use signed cookies for
    1. You want to provide access to multiple restricted files.
    2. (Does not support RTMP distribution)
  • Used in combination with signed URLs and signed cookies to restrict direct access to an S3 bucket (prevents bypassing the CloudFront controls). An origin access identity (OAI) is a special CloudFront user that is associated with the distribution. Permissions must then be changed on the Amazon S3 bucket to restrict access to the OAI. The origin access identity has permission to access files in your Amazon S3 bucket, but users don’t.
  • To require that users access content through CloudFront, change the following settings in your CloudFront distributions:
    1. Origin Custom Headers – Configure CloudFront to forward custom headers to your origin.
    2. Viewer Protocol Policy – Configure your distribution to require viewers to use HTTPS to access CloudFront.
    3. Origin Protocol Policy – Configure your distribution to require CloudFront to use the same protocol as viewers to forward requests to the origin.
    4. The Match Viewer is an Origin Protocol Policy which configures CloudFront to communicate with your origin using HTTP or HTTPS, depending on the protocol of the viewer request. 
  • If you configure CloudFront to serve HTTPS requests using SNI, CloudFront associates your alternate domain name with an IP address for each edge location. The IP address to your domain name is determined during the SSL/TLS handshake negotiation. 

  • To serve a static website hosted on Amazon S3, you can deploy a CloudFront distribution using one of these configurations:

    – Using a REST API endpoint as the origin, with access restricted by an origin access identity (OAI)

    – Using a website endpoint as the origin, with anonymous (public) access allowed. Helpful when creating public FTP websites to allow public users to download files.

    – Using a website endpoint as the origin, with access restricted by a Referer header

    – Using AWS CloudFormation to deploy a REST API endpoint as the origin, with access restricted by an OAI and a custom domain pointing to CloudFront

  • For each query string parameter that your web application forwards to CloudFront, CloudFront forwards requests to your origin for every parameter value and caches a separate version of the object for every parameter value.
  • For multiple parameters, the number of requests and the number of objects multiply. For example, if requests for an object include two parameters that each have three different values, CloudFront caches six versions of that object. 
  • If you’re using the domain name that CloudFront assigned to your distribution you can change the Viewer Protocol Policy setting for one or more cache behaviors to require HTTPS communication by setting it as either Redirect HTTP to HTTPS or HTTPS Only. In that configuration, CloudFront provides its default SSL/TLS certificate.
  • If your origin is an Elastic Load Balancing load balancer, you can use a certificate provided by AWS Certificate Manager (ACM). You can also use a certificate that is signed by a trusted third-party certificate authority and imported into ACM. Note that you can’t use a self-signed certificate for HTTPS communication between CloudFront and your origin. However if the origin is EC2 it has to be from a trusted authority.
  • There is no default SSL certificate in ELB, unlike what we have in CloudFront.
  • RTMP is primarily used for video streaming.
  • AWS recommends not to configure caching based on values in the Date and User-Agent headers, because these headers have numerous possible values and caching based on their values could cause CloudFront to forward significantly more requests to your origin. However, this rule should not be applied to the Host HTTP headers as well as these do not have numerous distinct values.

Global Accelerator

AWS Global Accelerator is a Global networking service that helps you improve the availability and performance of the applications that you offer to your global users. 
AWS Global Accelerator provisions two static IP addresses. Associate the static IP addresses provided by AWS Global Accelerator to regional AWS resources or endpoints, such as Network Load Balancers, Application Load Balancers, EC2 Instances, and Elastic IP addresses.
  • Easily move endpoints between Availability Zones or AWS Regions without needing to update your DNS configuration or change client-facing applications.
  • AWS Global Accelerator utilizes the Amazon global network.
  • AWS Global Accelerator relies on ELB to provide the traditional load balancing features such as support for internal and non-AWS endpoints, pre-warming, and Layer 7 routing. However, while ELB provides load balancing within one Region, AWS Global Accelerator provides traffic management across multiple Regions.
  • Global Accelerator is a good fit for non-HTTP use cases, such as gaming (UDP), IoT (MQTT), or Voice over IP, as well as for HTTP use cases that specifically require static IP addresses.
  • S3 Multi-Region Access Points use Global Accelerator transparently to provide a single global endpoint to access a data set that spans multiple S3 buckets in different AWS Regions. 
  • AWS Global Accelerator automatically checks the health of your applications and routes user traffic only to healthy application endpoints.
  • Global Accelerator’s IP addresses can be associated with one or more endpoints - Application Load Balancers, Network Load Balancers or EC2 instances, in any number of AWS Regions. This allows you to easily scale out your applications to multiple AZ’s or AWS Regions. Elastic IPs on the other hand are tied to a single AWS resource, such as a load balancer or an EC2 instance, in a single AWS Region.
  • AWS Global Accelerator supports both TCP and UDP protocols. And Ip4 addresses. 
  • AWS Global Accelerator is a network layer service that directs traffic to optimal endpoints over the AWS global network, this improves the availability and performance of your internet applications. It provides two static anycast IP addresses that act as a fixed entry point to your application endpoints in a single or multiple AWS Regions, such as your Application Load Balancers, Network Load Balancers, Elastic IP addresses or Amazon EC2 instances, in a single or in multiple AWS regions.
  • AWS Global Accelerator uses endpoint weights to determine the proportion of traffic that is directed to endpoints in an endpoint group.
  • Some client devices and internet resolvers cache DNS answers for long periods; this DNS feature improves the efficiency of the DNS service as it reduces the DNS traffic across the Internet, and serves as a resiliency technique by preventing authoritative name-server overloads. The downside of this in blue/green deployments is that you don’t know how long it will take before all of your users receive updated IP addresses when you update a record, change your routing preference or when there is an application failure. With AWS Global Accelerator, you can shift traffic gradually or all at once between the blue and the green environment and vice-versa without being subject to DNS caching on client devices and internet resolvers, traffic dials and endpoint weights changes are effective within seconds.

Comments

Post a Comment

Popular posts from this blog

Artificial Computation Intelligence

  Components of Problem Formulation Initial State - Is the starting configuration of system. Actions - The permissible moves or operations that can be performed in the problem space. Transition Model - Describes the result of applying specific action in a given state. Goal State - Desired configuration that indicates problem has been solved. Cost function - numerical cost for each action. Task is to setup an automated traffic monitoring system that should be equipped with 10 cameras at each intersection to detect traffic violoations and detect license plates to cross verify with stolen vehicle database. What is the problem formulation for this, provide PEAS description, which agent architecture will fit this ? PEAS Description: Performance Measure: The system's performance is measured by its accuracy in detecting traffic violations, identifying license plates, and cross-verifying them with the stolen vehicle database. Additionally, the efficiency of the system in processing and ana...
Read more

Serverless - Lambda functions

 Lambda All operational activities of applying patch, capacity provisioning, monitoring fleet health, code deployment etc is taken care by Lamda. Best suited for use cases which are event based, such as changes to S3 buckets,  serverless processing of streaming data, updates to Dynamo DB table or custom event generated by apps/devices. All code uploaded to Lambda is encrypted. Each Lambda has built-in ephemeral storage of 512 MB. In-bound network connections are blocked by Lambda. Total Metrics, Account and Function level concurrency usage, latency and throttled requests are metrics shared by Lambda through Cloud Watch. Each Lambda function has a log group which can be traced in Cloudwatch logs. We can define the memory to be set for the function. Lambda function max execution time is 15 mins. Lambda can do polling of resources that do not publish events. Or it can be triggered basis events. S3 Integration - The S3 Bucket notifications can be sent to Lambda functions. Lambda c...
Read more

System Design

 System Design Designing for scale Designing for availability Designing for performance Content delivery network Caching Designing for resilience Secure by design Perimeter Security Intrusion detection and Prevention Zscaler Network security Network Isolation Zero trust architecture Server security Application security Data at rest - Encryption using keys Data in transit Encryption Key management  Code Security OWASP guidelines Web security Authentication OAuth Single Signon LDAP Authorization Google Zanzibar OPA Mobile Security Wireless transmission security Penetration testing Architecture principles in system design 12 factor DRY SOLID Programming types Functional Reactive Architecture tools Abacus Modular design Do we need microservices? When to go for Microservices ? Building microservice architecture Breaking down into Microservices Domain driven design Inter service communication Direct Connectivity Circuit breakers Service Registry Distributed transaction management Sa...
Read more