CDN - CloudFront

  • Content Delivery Network (CDN)
  • Improves read performance, content is cached at the edge locations (+136 point of presence globally)
  • πŸ“ Popular with S3 but works with EC2, Load balancing
  • Can help protect against network attacks
  • You use domain name that CloudFront assigns to your distribution, e.g. cannot attach Elastic IP.
  • Security
    • Can provide SSL encryption (HTTPS) at the edge using ACM (AWS Certificate Manager)
      • Supports: Perfect Forward Secrecy (new SSL key for each session)
    • Can protect against DDoS attacks.
  • Geo Restriction allows you to specify a list of whitelisted or blacklisted countries in your CloudFront distribution.
  • A distribution is a CloudFront instance (collection of edge locations) that can be:
    • Web distributions -> Web pages
    • πŸ“ RTMP -> a video/media (streaming) protocol over SSL
      • For RTMP CloudFront distributions files must be stored in an S3 bucket
  • You set up origin (domain name & path)
    • Origin can be S3, EC2, ELB, or Route53.
    • Origin Failover: Set-up primary + secondary origins on selection of 500, 502, 503, 504, 404, or 403.
      • πŸ’‘ Enables high availability.
  • Cache Behavior settings
    • Can set-up viewer Protocol Policy: HTTP & HTTPS, Redirect HTTP to HTTPS, HTTPS only
    • Can allow HTTP Methods: GET & HEAD & PUT & OPTIONS & PATCH & DELETE.
    • Set minimum maximum & default TTL
    • Forward cookies and/or query strings
    • And more: e.g. Path Pattern, Compress objects
  • Distribution Settings are β€’ Price Class β€’ AWS WAF Web ACL β€’ Alternate Domain Names (CNAMEs), SQL certificate β€’ Supported HTTP versions, logging (with log prefix & option to include cookies) β€’ Enable IPv6
  • πŸ“You can clear cache objects by creating an invalidation but you will be charged.
    • πŸ’‘ AWS recommends versioned file names instead of invalidating if files are updated frequently.
    • Integrates with AWS Shield for DDoS protection.
    • Integrates with AWS WAF for application layer security.
  • Regional Edge Cache: If data is infrequently accessed, instead of CloudFront sends request back to your origin, it caches your data in a regional edge caches and gets from there (faster).
  • πŸ’‘ Use cases
    • Accelerate uploads -> Users can upload to edge locations
    • Can stream videos from edge locations
    • Used in general to accelerate other services e.g. S3 for e.g. faster upload.
    • Allows Lambda with [email protected] to run in edge locations.
    • Integrates with API gateway to run on edge locations.
    • Use with any text, blob (e.g. .pdf)
  • Cache-Control and Expires headers control how long objects stay in the cache.
    • Cache-Control max-age lets you specify how long (in seconds) you want an object to remain in the cache before CloudFront gets the object again from the origin server.
      • Minimum 0, Max 3600

S3 & CloudFront

  • Allows to directly upload to and read from edge locations.
  • Transfer acceleration
    • In S3 enables faster transfers through routing from CloudFront’s edge locations.
    • πŸ’‘ Costs extra but not always fastest, test it.
    • Supports multipart uploads.
  • CloudFront vs S3 Cross Region Replication

    Attribute CloudFront S3 Cross Region Replication
    Cache location Global edge network Each unique region you set up for replication
    Cache duration TTL Updated in near real time
    Can write? Yes, can put object Read-only
    Use case Static content that must be available everywhere Dynamic content that needs to available at low-latency in few regions
  • πŸ“You can enable Restrict Bucket Access
    • Requires users to always access S3 content using CloudFront URLs, not S3 URLs
    • Grants permissions to Origin Access Identity for GetObject.
      • Origin Access Identity is Identity for CloudFront distribution
  • Origin Access Identity
    • More secure: Clients must go through CloudFront, cannot go directly to S3
    • Serving static content, globally
      • Client <– CloudFront –> Amazon S3
    • Serving static content, globally, securely
      • Client <– CloudFront (OAI: Origin Access Identity) <–> Amazon S3 (bucket policy + only authorize from OAI)
  • πŸ“CloudFront Signed URL / Signed Cookies
    • It’s commonly use to give access to paid content
      • E.g. you want to distribute paid shared content to premium users over the world & content lives in S3.
      • ❗ If S3 can only be accessed through CloudFront, self-signed S3 URLs cannot be used.
        • πŸ’‘ We can use CloudFront Signed URL.
    • Security: e.g. IP restriction
    • ❗ Can only be created using the AWS SDK
    • Flow:
      • Attach a policy with
        • URL expiration
          • πŸ’‘ URL invalidation best practices
            • Shared content (movie, music): make it short e.g. a few minutes
            • Private content (private to the user): make it last for years.
        • IP ranges to access the data from
        • Trusted signers (which AWS accounts can create signed URLs)
      • You need to write an application:
        • Client gets signed URL from application where application talks to Amazon CloudFront using SDK to generate a signed URL
    • Example architecture: API Gateway –> Lambda (Creates signed URL & verifies if user is premium with DynamoDB) –> CloudFront (issues signed URL) <β€” OAI: Origin Access Identity –> S3 (serves videos + authorizes only from OAI with a bucket policy)

API Gateway & CloudFront

  • CloudFront in front is generally not a good idea.
    • Most of the functionality in CloudFront can be found API gateway.
      • You can use edge-optimized endpoints in API Gateway.
        • CF usage is already included on API GW pricing.
  • Deploy it if you want to fully control CloudFront distribution
    • E.g. manage WAF, add custom behaviors (static files on S3, some paths going to an ALB or other API), host API on multiple regions, set-up CF access logs etc.

Licenses and Attributions


Speak Your Mind