Overview
An application running on EC2 distributes software updates once in a while. Computers download the patch from us, and the patch sits on EC2.
Problem:
- When a new update is out, we get a lot of requests because many people want to update.
- The content is distributed in mass over the network and costs a lot of money.
- We do not want to change or re-architect the application.
- We only want to optimize cost and CPU.
Current State
Users ──▶ ELB ──▶ ASG (M5 instances, multi-AZ) ──▶ Amazon EFS (software updates)
A classic ELB + ASG application in multi-AZ. Assume M5 instances distribute the updates, and for simplicity the updates are stored in Amazon EFS.
Solution: Put CloudFront in Front
Users ──▶ CloudFront (edge cache) ──▶ ELB ──▶ ASG ──▶ EFS
CloudFront is the easy fix:
- No changes to the architecture.
- The software update files are static and never change, so CloudFront caches them at the edge.
- CloudFront is serverless and scales for us, even though the EC2 instances are not.
- The ASG will not scale as much.
- Big savings on EC2, network and EFS costs, plus availability gains.
See 12 - CloudFront & AWS Global Accelerator/01-CloudFront-Overview.
CloudFront in front of the existing stack
Exam Tips
- CloudFront is an easy way to make an existing application more scalable and cheaper when it serves mostly static content, using caching at edge locations around the world.
- Sometimes the best solution is the easiest one.
Q&A
Q1: How do you cut cost and CPU for mass software-update downloads without re-architecting?
Answer: Put CloudFront on top. It caches the static update files at the edge, so the ASG scales less and EC2, network and EFS costs drop.
Q2: Why does caching work here?
Answer: The update files are static and never change, not dynamic.
Q3: Does the EC2 layer need to become serverless?
Answer: No. CloudFront is serverless and scales for you, even though the instances are not.
Check yourself
Quiz
Flashcards
Click the card (or focus it), then use ← → to move and Space to flip.