Jorge Vasquez - Sr. Software Engineer Hongmin Liu
In Amazon CloudFront, a lot happens in just a few milliseconds. Join us for a dive deep into the infrastructure and architecture of the AWS edge services, including Amazon CloudFront, Amazon Route 53, AWS Shield, and AWS WAF. We break down the life of an HTTP request, and any request in general, and walk you through how each of the AWS edge services work together in just a few milliseconds to consistently deliver your application’s content with high availability, security, and performance. Learn how edge services intelligently route requests to the most ideal edge location, secure your content behind the scenes, and leverage the AWS private network for improved performance.
- Request flow in cloudfront
- POP - point of presence (aka edge servers)
- 150 pop servers
- isp dns resolver (recursive resolver. breaksdown name and requests from other resolvers)
- route 53 front every dns request -> will choose best point of presense server -> isp caches this dns result
- user tcp/tls -> cloudfront pop
resolver -> pop
- need to think of perf.
- need to think of capacity. (capacity changes)
- need to check pop health. (pops go down for maintenance)
- network capacity. (if network is congested we need to choose a better path.)
Measuring the internet in realtime: look up on youtube
- 3 way handshake:
- syn, syn + ack, ack, data1
- syn, syn + ack, ack, data2
TCP fast open
- client can tell server that it supports fast open.
- cf sends cookie to identify client
- 1 less round trip for the data
- secrecy: coffee shop privacy
- non-replayability: cannot capture a request and send it again.
- on top of security issues
- best practices: do not manually have to configure ciphers and dropdown. easy and PCI compliant.
best security is invisible
- visible security
- go to airport and show what is in your bag and get scanned
- invisible security keyfob to open car is imperceptible
client -> server
extra roundtrip to start tls session.
- 2 RTT
cloud front support sessions resumption
- 1 RTT
- many layers
router chooses a random server for each connection. round robin
- l1 server: terminate tls
- l2 server: cache keys for resources
- each has different content
- if cache content is not there it needs to fetch the content from the origin server
- l3 server:
- connect to origin server
- keep connections open to avoid additional handshakes
- connection re-use is why we have l3 servers.
cloudfront can skip layers
- L1 two components tls/tcp components
- L1 can skip the second component and go straight to layer 2
regional edge caches (REC)
- CDN for CDN’s
- from layer of cache backend. no cache. only security. security check before getting on your flight.
- signed urls
- serve private content
- policy, signature, key pair id
- key pair id is used to lookup public key to verify signature.
- field level encryption (FLE)
- cloudfront can server private data by encrypting data.
- cached content at edge locations can be encrypted.
- aws waf
- lambda @ edge