API Gateway 앞에 CloudFront가 있으며 애플리케이션 로직 앞에 EC2나 Lambda가 있을 수 있음 애플리케이션은 데이터베이스에서 데이터를 저장하고 쓰며 Redis, Memcached 혹은 DAX 등의 내부 캐시를 쓸 수 있음 그럴 경우 동적 콘텐츠와 동적 라우팅이 실행되게 되며 CloudFront로 가는 클라이언트나 CloudFront가 S3에서 데이터를 소싱하는 경우 정적 콘텐츠 라우팅도 할 수 있음
CloudFront는 두 개가 있으며, 하나는 엣지에서 캐싱을 하므로 사용자와 최대한 가까이에서 캐싱을 함 CloudFront에서 캐싱을 허용하면 캐시를 히트하는 모든 사용자들이 즉시 응답을 빠르게 얻을 수 있음 하지만 엣지에 있기 때문에 백엔드에서 변화가 일어날 수도 있으며 몇몇은 오래됐을 수도 있으므로 캐시가 최신인지 확인하려면 TTL을 사용하여 또한 백엔드에서 새로운 것들을 가져올 수도 있음 그리고 엣지에 캐시를 얼마나 더 할 것인지와 앱 로직에 얼마나 캐시를 더 할지 균형을 재게 됨
API Gateway도 캐싱이 가능해서 CloudFront와 함께 사용할 필요가 없음 API Gateway는 리전 서비스라서 API Gateway에서 캐시를 사용할 경우 캐시도 리전에 묶이게 됨 그러므로 클라이언트와 API Gateway 사이에 네트워크 라인이 형성되어 캐시가 여기서 히트하게 됨
앱 로직의 경우 보통 캐싱을 하지 않는데 DynamoDB가 있을 경우 Redis, Memcached, DAX 등을 사용할 수 있는 캐시를 할 때 사용되며 데이터베이스는 캐싱을 못하므로 데이터베이스를 반복적으로 히트하길 원치 않으므로 자주 발생하는 쿼리나 복잡한 쿼리가 공유 캐시에 결과가 저장되어 앱 로직에 쉽게 액세스할 수 있게 하므로 캐싱을 통해 절약을 한다고 할 수 있음 즉 데이터베이스에 가해지는 압력을 중리고 읽기 용량을 늘리는 것
S3의 데이터베이스에는 캐싱 기능이 없음
캐싱의 경로를 따라가보면 뒤쪽으로 갈수록 비용과 지연 시간이 늘어나므로 어떤 작업이냐에 따라 어는 것이든 가능 예) 작업을 위해 애플리케이션을 어떻게 설정할지, 콘텐츠를 어디로 캐시할지, 어떻게 얼마나 캐시할지에 따라 어디서 캐싱할지
