Skip to content

Cloudfront & Global Accelerator


Cloudfront is a CDN, it improves application performance by caching content in edge locations. It consists of.

  • Cloudfront integrates with AWS Certificate Manager(ACM) to use SSL certificates
  • Cloudfront is for downloads only. It does not perform write caching. Any uploads go directly to the origin for processing

DDOS Protection

Cloudfront offers DDOS protection as it is worldwide service & is integrated with Shield, AWS WAF.


These can be the source of data/origin for cloudfront content.

S3 bucket

- Distribute files by caching them at the edge.
- Enhanced security with Cloudfront Origin Access Control (OAC)
- CloudFront can be used as in ingress (Upload data to S3)

Custom Origin

- EC2 instance
- S3 website (must enable static website on S3 bucket)
- Any HTTP backend


  • The distribution contains the configuation deployed to the edge locations
  • A distribution can have many behaviours which are configured with a path pattern. If requests match that pattern, that behaviour is used otherwise default is used.
  • Origins, Origin groups, TTL, Protocol Policies, restricted access are cofnigured via Behaviours

TTL & Cache Invalidation

  • More frequest cache HITS = lower origin load
  • Default TTL (Configured in Behaviour) = 24 hours (Validate period)
  • You can set Minimum TTL & maximum TTL values
  • Origin Header: Cache-Control max-age (seconds)
  • Origin Header: Cache-Control s-maxage (seconds)
  • Origin Header: Expires (Date & Time)
  • Headers can be set using Custom origin or S3 (via object metadata)

If the backend origin is updated, Cloudfront doesn't know about it until the TTL has expired. We can force an entire or partial cache refresh bypassing the TTL by performing a Cloudfront Invalidation.

  • Cache invalidation is performed on a distribution
  • Applies to all edge locations but, takes time
  • Invalidate all files: *
  • Invalidate special path: /images/*

  • Cache Invalidations cost the same irrespective of the number of objects in a bucket

  • Versioned file names can be used instead of Cache Invalidation Eg: cat_v1.jpg, cat_v2.jpg

AWS Certficate Manager - ACM

  • ACM lets you run a publicor private Certificate Authority (CA)
  • Private CA: Applications need to trust the private CA
  • Public CA: Browsers trust a list of providers, which can trust other providers
  • ACM can generate or import certificates.
  • If certificate is generated by ACM, it renews automatically.
  • If certificate is imported, renewal is customers responcibility
  • ACM certificates can only be deployed to supported services
  • Supported AWS Services Eg: Cloudfront & ALBs. EC2 are not supported
  • ACM is a regional service
  • Certs generated cannot leave the region they are generated or imported in


To use a cert with ALB in ap-south-1,you need a cert in ACM in ap-south-1 Global services such as CloudFront operate as though within us-east-1

CloudFront and SSL

  • SSL is supported by default with the * SSL cert
  • Custom domain names can be used (Alternate Domain Names -> CNAMES)
  • Verify Ownership (Optionally HTTPS) using a matching certificate (proves ownership)
  • Generate or import certificate in ACM in the same region as the service (Eg: Load balacner in ap-south-1 would need certificate in ap-south-1)
  • For global service eg: cloudfront, certificates need to be in us-east-1
  • In cloudfront both HTTP or HTTPS can be allowed.
  • HTTP can be redirected to HTTPS
  • Only HTTPS can be allowed

2 sets of connections are present when using CloudFront

  1. Viewer => CloudFront (Viewer Protocols)
  2. Cloudfront => Origin (Origin Protocols)

Both the above connections need valid public & intermediate certificates


Self signed certificates do not work with CloudFront

CloudFront and SNI

  • Historically SSL enabeld site needed its own IP
  • SNI is TLS extension, allowing host to be included in the initial conenctions within the TLS handshake
  • This allows many SSL Certs/Hosts to use a shared IP
  • Old browsers don't support SNI, CloudFront charges extra for dedicated IP (Dedicated IP at each CloudFront edge location)

Origin Access Identity (OAI)

  • OAI is a type of identity
  • It can be associated with CloudFront Distributions
  • OAI can be used in S3 bucket policies
  • Deny all BUT one or more OAI's for the S3 bucket

Origin Security

  • S3 Origins are secured using OAI
  • Custom Origins are secured using:
    • Custom Header
    • Unblock connections from IP ranges of CloudFront and block all other connections

Private Distributions (*behaviours)

  • Public - Open access to objects
  • Private - Requests require signed Cookie or URL


  • A CloudFront Key is created by an Account Root User
  • The account is added as the TRUSTED SIGNER


  • Trusted Key Groups are created & signers are assigned

CloudFront Signed URLs vs Cookies

  • SignedURLs provide access to one object
  • Use signed URLs if the client does'nt support cookies
  • New Object URL is generated for signed URL

  • Cookies provide access to groups of objects

  • Use for groups of files/all files of a type eg: jpg
  • Use to maintain application URLs

Lambda @ Edge

  • Run lightweight lambda at edge locations
  • Adjust data between viewer and Origin
  • Currently supports Node.js and Python
  • Run in the AWS Public Space (Cannot access VPC resources)
  • Layers are not supported

Use cases:

  • A/B testing - Viewer Request
  • Migration Between S3 Origins - Origin Request
  • Different Objects based on device - Origin Request
  • Content By Country - Origin Request

AWS Global Accelerator

AWS Global Accelerator is a service that improves the availability and performance of your applications with local or global users. It provides static IP addresses that act as a fixed entry point to your application endpoints in a single or multiple AWS Regions, and uses the AWS global network to optimize the path from your users to your applications.

  • Leverage the AWS internal network to route to your application
  • 2 Anycast IP are created for your application
  • The Anycast IP send traffic directly to edge locations
  • Edge locations send traffic to your application through private network
  • Better security: only 2 external IP need to be whitelisted
  • Provides DDoS protection through AWS Shield

Unicast IP : One server holds one IP address

Anycast IP : All servers hold the same IP address & the client is routed to the nearest server.

Traffic Flow

  1. Traffic initially uses public internet & enters a global accelerator edge location.
  2. Customer arrives at Global Accelerator edge locations, from the edge data transits globally across the AWS global backbone network.
  3. Less hops, and siginficantly better performance


  • Global Accelerator moves the AWS network closer to customer
  • Coonnections enters at edge using anycast IPs
  • Transits over AWS backbone to 1 or more locations
  • Global Accelerator is a network product. Can be used for NON HTTP/S (TCP/UDP) whreas CloudFront only caches only HTTP & HTTPS content
  • TCP/UDP: Global Accelerator, HTTP/HTTPS: CloudFront

AWS Local Zones

  • 1 Zone. So no built in resilience
  • Like an AZ, but near customer location so lower latency
  • Not all products support Local Zones. Many are opt in with limitations
  • DX to local zone is supported (Extreme performance needs)
  • Utilise parent region. Eg: EBS snapshots are sent to parent zone
  • Use local zones when you need the highest performance