<Cloud Front 개요>
> CDN (Content Delivery Network) 의 일종 > 넷플릭스 같은거가 사용하는 것
> 읽기 성능이 우수하며, Edge 에 컨텐츠가 캐싱된다 (지연이 낮아서 UX 가 좋음)
> 전세계적으로 216 개 이상의 Point (edge location )이 있음 > 전세계에 퍼져있는 캐시 서버임
> DDos 보호가 지원된다
<Origin>
> 다양한 오리진을 둘 수 있다 - 같이 연동할 수 있는 지점
> S3 Bucket
>> 파일들 분할, edge caching 을 위함?
>> CloudFront Origin Access Control (OAC) 로 강화된 보안을 제공
>> CloudFront 는 S3 로 업로딩을 지원할 수 있는 [인그레스] 라는 목적으로 사용될 수 있다
> Custom Origin (HTTP)
>> App Load Balancer, Ec2 인스턴스, S3 웹사이트, Any HTTP 백엔드
> Client 가 내 오리진을 접근하고 싶음. CloudFront 로 먼저 들어가게 됨. 이 때 캐싱된게 있는지 확인하고, 없으면 Origin 으로 요청을 전달한다. 그 결과를 캐시해서, 다른 고객들에게 제공한다 (동일한 요청일 경우)
> Origin 과 Edge Location 들과의 통신은 Private 망으로 보호될 수 있고, S3 자체 역시 OAC 로 보호되며, Bucket policy 도 보호를 지원한다
< CloudFront vs S3 Cross Region Replication >
> Cloud Front
> 전세계적인 Edge Network 를 사용하는 것이다
> Files are cached for a TTL (하루 정도)
> 전세계적인 서비스에 static content (정적 콘텐츠) 를 제공해야 하는 Use Case 에 정말 너무너무 적합하다고 함 (캐싱되기 때문에 동적인 자원은 아닌듯?)
> 후자
> 너가 replication 을 원하는 지역에 SU 이 되어야 함.
> 파일들이 실시간으로 update 되며, read-only 를 위함
> 특정 지역에만 제공되어야 하며, 저지연으로 dynamic content 를 제공해야 할 때 적합
<사실 이건 캐시 자체에 대해서 더 잘 이해해야함, CDN과 캐시>
--------------------------------------------------------------------------------
156 강 <Cloud Front 실습>
> S3 버킷을 기본 설정대로 만들고, 파일 몇개를 업로드 한다 (index.html 포함)
> CloudFront 리소스로 이동, [배포 생성] 클릭
> Origin 도메인 선택 가능 > S3, ELB 등등 선택 가능 (아니면 스스로의 오리진을 입력해도 됨)
> Origin Access 를 OAC 로 세팅 (CloudFront 로만 버킷이 접근 가능하게끔 하는 거인듯) > 버킷에 CloudFront 가 가능하게끔 Policy 를 수정해야 한다고 뜸
> WAF 는 끈다
> Default root - index.html 로
> 생성하면 Copy Policy , 이거를 아까 그 버킷에 세팅하면 완성이된다. (설정 화면에서도 Copy Policy 확인할 수 있다)
{
// "Version", "Id" 등등 ..
"Statement" : [
{
"Sid" : "AllowCloudFrontServicePrincipal",
"Effect" : "Allow",
"Principal" : {
"Service" : "cloudfront.amazonaws.com"
},
"Action" : "s3:GetObject",
"Resource" : "arn:aws:s3:::S3버킷명이 명시/*",
"Condition" : {
"StringEquals" : {
"AWS:SourceArn" : "CloudFront의ARN이 명시"
}
}
}
]
}
> Deploy 될 때까지 기다려야함. Deploy 되면 distribution Domain Name 을 제공받을 수 있음, distrbution Key 도 제공됨
> 여기에 그냥 들어가면 아까 설정한 root 경로로 가서 index.html 이 뷰되는걸 확인할 수 있음
> 이 cloudFront 를 활용해서 S3 에 접근할 수 있게 되는 거임.
> 아까 올렸던 jpg 이미지들을 https://distribution-domain-origin/hello.jpg 를 해도 조회가 가능하고, 이 이후로 또 요청하게 되면 이 요청은 사실 CloudFront 에 캐싱되어 CloudFront 에서 제공되고 있는 것을 알 수 있다 (로딩이 훨씬 빠르다는 것을 느껴보려면 다른 지역 서버에 만들어보면 될 듯)
--------------------------------------------------------------------------------
157 강 <CloudFront Caching 및 캐싱 정책>
> 캐시는 각 CloudFront Edge Location 에서 캐싱되어 있다
> Cloud Front 는 요청된 객체가 있는지 Cache Key 를 통해 확인한다. 그리고 없으면 Origin 으로 forward 해서 가져오고, 이를 TTL 기반으로 캐싱한다
> Cache Hit ratio 를 조절해서 origin 에게로의 요청을 최소화 할 수 있고, 캐싱 삭제할 수도 있음
<CloudFront Cache Key>
> unique id for every object in the cache. "hostname + resource portion of the URL" 로 구성된다
> hostname : hello.com // resource portion : /content/storeies/example.html 이거를 말한다
> 이거를 토대로 cache miss 가 나면 실제 오리진에 요청하고, cache hit 이라면 해당 캐싱 객체를 호출해준다
> 가끔은 user, device, language 에 따라 다를 수도 있어서, 캐시 키를 조금 고도화하고 싶으면 그렇게도 가능하다
> ClouFront Cache Policy 를 사용해서 캐시키에 다른 정보를 추가시킬 수도 있다 (PK 를 더 고도화하는거임, unique 한 기준을 변경하는 행위)
< Cache Policy >
> Cache based on
>> Http Headers : None 혹은 Whitelist (내가 원하는 대상)
>> Cookies : None 혹은 Whitelist (+ Include-All-Except : 이거 각각 뭣들인지는 아래 예시에서 파악 가능)
>> Query String : 위와 동일
> TTL 까지 조절 가능 (0 sec to 1 year), Cache-Control Header, Expires Header 를 통해서 조절할 수 있다 (Cloudfront 에게 보내줄 때? 이거 S3 오리진 활용 같은걸 넘어선듯 이런건?)
> 스스로 캐싱 정책을 만들거나 , AWS 에서 만들어준 Predefined Managed Policy 를 활용해도 됨
> 중요한 건, 모든 HTTP 헤더, 쿠키, query strings 포함 시키는 것들은 자동으로 origin 에게 요청을 보낼 때 포함시키게 된다.
<Example : Cache Policy Using Http Headers & Query String>
> Header 정책
>> None 으로 명시 : 캐시 키에 아무 헤더를 사용하지 않는다는 뜻, 헤더가 Origin 요청시 forward 되지 않는다. (주기가 긴 access token 같은걸 활용해서 캐싱해도 되는건가..) , Best Caching Performance 를 보여줌
>> Whitelist : 내가 원하는 헤더들을 명시해주면 이걸 캐시 키에 포함시켜 준다. 이 헤더들은 origin 요청시 포함시켜준다
> Query String 정책 (?,& 를 활용한 query param)
>> None 으로 명시 : 아무 것도 전달되지 않음. Unique 기준에 포함되지 않음
>> whitelist : 내가 원하는 query string 을 명시
>> Include All-Except : 내가 원하지 않는 query string 을 명시 (여기에 명시된 애들 빼고 다 캐시키에 포함시켜달라)
>> All : 그냥 다 포함시키는 것 : 제일 낮은 성능을 보여줌
> 사실 성능이 중요하다기보단, 그 용도에 맞춰서 활용하는 것이 중요함.
<Origin Request Policy>
> 캐시 키에 포함시키진 않지만, origin request 에 항상 보내고 싶은 것들도 명시할 수 있다 (이건 그니까 unique 하진 않은 거임, 모두 공통되게 origin request 에 들어가는 것)
> extra Http header / Cookie / Query String 모두 추가 가능
> Use Case : 서버에서 어떤 요청인지 구분할 수 있게, cloud front 에서 Header 로 cloudfront : true 이런걸 같이 보내게 하는거임.
> 이것도 캐시 정책처럼 스스로 만들 수 있고, AWS 에서 제공하는 Predefined Managed Policy 를 사용할 수도 있다
< 두 Policy 차이..>
> 나는 이해 됐음 ㅋㅋ
> 근데 ORP 에 예시에 Cookies : session_id 가 있는건 이해 안간다. 이거 CloudFront 를 말하는걸까..?
--------------------------------------------------------------------------------
158 강 <캐시 무효화 Cache Invalidation> - 필요한 상황이 존재. 비기능 요구사항에 따름
> 백엔드에 어떤 수정사항이 생겨도 , CloudFront 는 모른다. TTL 이후에야 그 정보를 다시 캐싱할 것이기 때문 (수용 불가한 상황일 수도 있음)
> Entire / Partial Cache Refresh 를 진행할 수 있다. CloudFront Invalidation 을 사용
> * 로 모든 file 을 invalidate 할 수도 있고, /images/* 과 같은 방식으로 부분만 invalidate 할 수도 있다.
> 하루정도 TTL 이 있다고 해보자.
> S3 버킷을 내가 수정해서 업데이트가 진행되었다고 가정해보자. 그리고 이 상황을 유저들이 바로 반영했으면 좋겠다.
> 그 때 CloudFront 에게 Invalidate 을 요청하는데, /index.html 그리고 /images/* 의 invalidate 을 요청한다
> 그럼 Edge Location 들은 모두 캐싱을 제거하게 된다.
> 그 다음에 고객이 GET /index.html 을 하면, CloudFront 는 다시 오리진에게 요청하고 (update 정보를 제공받을 수 있다), 이걸 다시 캐싱해서 즉각적인 반영을 제공할 수 있다
--------------------------------------------------------------------------------
159 강 <캐시 동작 : Cache Behavior>
> 특정 URL Path Pattern 에 대해 다른 setting 을 주고 싶을 때
> ex) images/*.jpg 파일에 대해 한가지 캐시 동작만 주고 싶다 (위에거랑 반대되는 말 아님..?)
> content type, path pattern 에 따라서 서로 다른 origin / origin group 으로 라우팅 하고 싶을 떄 (캐싱에 대한 세부 설정 느낌?)
ex : /images/* -> S3 로 가라
/api/* -> 오리진으로 가라
/* -> default cache behavior 로 고정
위 예제 그림 -
> /api/* 은 Application Load Balancer 로 이동
> /* 즉 기본적인 캐싱 동작은 S3 버킷으로 이동
> 캐시 동작을 추가할 때 유의점은, Default Cache Behavior (/*) 은 항상 마지막에 processing 된다 (구체적인 matching 이 있는지 먼저 확인 후 없으면 default cache behavior 수행)
> URL 패턴에 따라 캐싱을 다르게 지정할 수 있는것, 사실상 LB 같은 느낌을 수행해 주는 건데, 이 위치가 다르고, 제어하는 느낌이 다른 것을 좀 더 이해해봤으면 좋겠음. 나중에 이런 형태의 리소스들을 다 비교해보고 싶음.
> /login 으로 들어오는 것은 EC2 인스턴스로 이동한다 (Signed cookies 를 전달해서 Users 에게 전달한다)
> Signed Cookies 가 있으면 default S3 로 접근을 허용해준다
또다른 예제는 <Maximize cache hits by separating static and dynamic distributions>
> 정적인 요청은 어떤 부가적인 캐싱 규칙 없이 제공하여, cache hit 를 최대화 시킨다 -> S3 의 정적인 처리를 지정
> 동적인 요청은 ALB + EC2 로 이동 -> 동적인 요청들은 적절한 헤더와 쿠키가 매칭해야 전달해주는 캐싱 Policy 를 추가적으로 지정한다
> 이런식으로 캐시 동작을 나눠서 미세한 조정을 할 수 있음 (Policy 와는 또 다른 점임을 이해)
> 각 강의내 캐싱 성질들의 차이를 이해해보는게 중요할 듯.
--------------------------------------------------------------------------------
160강 <캐싱 및 캐시 무효화 - 실습>
1. 캐싱 behavior 내 정책들 (CP, ORP)
> Distribution 의 Edit Behavior ㄹ르 확인하면 Default Pattern 이 하나 등록되어 있음
> 아래로 내려보면 방금 공부한 Cache Policy 와 ORP 를 설정할 수 있다
> 캐시 정책 생성을 누르면 생성하는 곳으로 이동하는데, 여기서 TTL 세팅과 캐시 키 세팅을 할 수 있다
>여기서 설정한 캐시키 포함 내용들은 origin request 에 전달하게 된다
> Unique 에 진행하지 않고 origin 에 전달하고 싶으면 ORP 에 등재하면 된다. (ORP 생성 들어가면 위에 창이랑 똑같은 창 뜸)
2. 캐싱 Behavior 추가 설정 가능
> 위에 것들은 behavior 안에서 제어하는 것이고 더욱이 default behavior 말고 더 behavior 을 생성할 수도 있다.
> Path Pattern : /images/* 에 대해서는 다른 origin 으로 가라고 할 수 있는 것이고, 여기서도 Policy 들을 다 생성할 수 있다
3. 캐싱 Invalidation 설정 가능
> index.html 이 기존 S3 버킷에 올라가 있음. 이거 Text 를 조금 수정해서 S3 버킷에 다시 올려놓음 (버저닝 활성화)
> 그 후에 S3 에 직접 접근해보면 당연히 바뀐 index.html 을 확인할 수 있으나, 기존에 CloudFront 를 통해서 index.html 에 접근하면 캐싱된 것을 반환하므로 이 업데이트 상황이 반영되지 않은 index.html 을 볼 수 있음
>> 참고로 이 때 S3 는 presigned url 로 접근하는 거고 (보호되고 있으므로), CloudFront origin 으로 index.html 을 요청하면 origin 이 S3 이므로 접근을 하는거는 이제 이해했지?
> CloudFront 는 기본적으로 하루동안 첫 index.html 요청을 캐싱하고 있다. 이걸 없애려면 invalidation 을 활용해야함
> Create Invalidatino 으로 가서, Add Object Paths 를 /* 로 하면, 모든 캐싱을 다 삭제하라는 것이다. 그리고 위에것을 다시 refresh 하면 업데이트된 index.html 을 반환되는 것을 확인할 수 있다.
------------------------------------------
161강 <오리진으로서의 ALB>
> CloudFront 에 오리진에는 ALB / EC2 도 설정이 가능하다. 개인 백엔드를 활용 가능
> EC2 인스턴스는 Public 이여야 Edge Location 들이 접근할 수 있다 - EdgeLocation 들의 public IP 를 인바운드 규칙에 넣어야 함 (AWS에서 확인 가능) - (CloudFront 에는 Private VPC 연결이 없음)
> ALB 활용할 수도 있는데, 이 ALB 역시 공개된 네트워크를 EdgeLocation 들의 IP 에 대해 가지고 있어야 한다. 그러면 백엔드 EC2 인스턴스는 비공개 설정이 가능함
-------------------------------------------
162강 <지리적 제한: Geo Restriction>
> 너의 CloudFront distribution 에 접근을 제한하고 싶은 지리적인 위치를 둘 수 있다.
> Allow-list > 너의 content 를 접근하려면 해당 list 에 명시된 국가 중 하나여야 함 (반대로 Blocklist 도 설정 가능)
> AWS는 3rd 파티 Geo-IP 데이터베이스를 사용해 국가가 어딘지 판별한다고 한다
> Use Case : 저작권법에 따라 콘텐츠의 액세스가 제한되는 경우
> Distribution 설정에서 [Edit Geographic Restriction] 설정에서 설정 가능
-------------------------------------------
163강 <CloudFront 서명 URL/ 쿠키 : CloudFront Signed URL / Signed Cookies >
> CloudFront 배포를 비공개로 설정해서 전 세계에 구독자들에게만 유료 공유 콘텐츠 액세스를 제공하고 싶음
> 단, CloudFront 배포에서 누가 어떤 콘텐츠에 접근 권한이 있는지는 인지/관리하고 싶을 때 사용
> URL 쿠키를 생성하면 attach a policy 해야 하는데, 이 policy 에는 다음과 같은 항목들을 포함시킬 수 있다.
>>> 다음: 만료기간, 데이터를 가져갈 수 있는 IP 범위(Client 측의 IP 를 안다면 활용) , 사용자들을 위해 Sgined URL 을 생성할 수 있는 AWS 계정 리스트
> 유효기간은 영화나 음악 같이 짧은 컨텐츠를 제공하는 것이면 (??) 짧게 만들어도 된다
> 단, 만약 유저가 접근하려는 컨텐츠가 개인의 것이며 오랫동안 계속 사용할 것이라면, 길게 유효기간을 잡아도 된다
(참고) Signed URL vs Signed Cookie (위에서는 URL/쿠키 둘 다를 말한거임!!) - 상황에 따라 다르게 사용하면 됨
> URL : 개별 파일에 대해 액세스를 제공하므로 파일 하나에 URL 하나임 (100 개 파일에 대해 관리하려면 100개 URL)
> 쿠키 : 재사용 가능하여 많은 파일에 대한 액세스를 제공할 수 있다.
> S3 버킷 객체는 오직 CloudFront 로만 접근 가능한 상황이다.
> 우리가 하고 싶은것은, CloudFront 를 활용해서 S3 버킷 객체에 접근 가능한 URL/쿠키를 만들어서 제공해주고도 싶은것! (Application 은 AWS 로 하여금 Signed URL 을 생성하라고 명령할 수 있는 User 여야 한다)
> 좌측 그림을 보면, Client 가 App 에 접근하면 App 은 인증/인가를 알아서 진행하게 된다. 그 두 SDK 를 활용해서 CloudFront 로부터 바로 Signed URL /Cookie 를 생성할 수 잇고, Client 에게 이를 반환하면 이 URL/ 쿠키를 활용해서 데이터/파일을 가져올 수 있는 것이다.
> 내가보기엔 Signed URL 을 줘서 s3 로부터 직접 가져오는 건 절대 아닌 것 같고
> CloudFront 에게 요청하기 전에 App 단에서 인증 인가를 해서, CloudFront 에게 접근할 수 있는 URL /쿠키를 제공하는 2차 보안 장치 같은 것인듯. 그리고 이를 유효기간만큼 계속 사용할 수 있도록 한다. 만료된다면 다시 인증/인가를 해서 가져오는 것 일듯?
> 위에서 설명한 Use Case 와 같이 사용할 때를 위해서인듯. (단순히 백엔드에서 ㅣ렇게 돌아가야 한다고 말하기에는, 백엔드에서 페이지를 로딩해줄 때 URL 이 포함되어 있다면 Cliend 에서 직접 요청한다고 보기는 어려운거 아닌가 ㅣㅍ음..) 아닌가...
<CloudFront Signed URL vs S3 Pre-Signed URL>
> 전자는 Origin 이 어떤한 것이든 무관하게 연결을 지원해준다
> Root 계정만이 관리할 수 있음
> IP / 경로/ 날짜 / 만료일을 기준으로 동작시킬 수 ㅣㅆ음
> CloudFront 의 모든 ㅣ능 이용가능
> 후자는 미리 서명한 사람의 권한으로 발급되는 URL 이다
> 클라이언트가 직접적으로 S3 에 접근하는 것이 목적.
-------------------------------------------
164강 <CloudFront 서명 URL/ 쿠키 : 키그룹과 실습>
<클라우드 프론트로 URL 에 서명하기 위한 키 생성 방법..?>
> 서명자는 두 뷴류
>> Trusted Key Group (Recommended)
>>> 키를 생성하고 순환하기 위해서 API 를 사용함
>>> 이 Key Group Management API의 보안을 위해 IAM 을 사용함
>> CloudFront Key Pair 를 보유한 AWS Account 사용하는 것 (최초부터 사용되었던 방법)
>>> 이 방법을 통한 키 관리에는 ROOT 계정 자격 증명 (Root Account Credential) 이 필요
>>> r권장되지 않음, Root Account 를 이걸 위해 사용하기엔 과하다고 함
>>> 또한 키 페어를 관리할 API 가 없기 때문에 자동화도 어려움
> 단일 CloudFront Distribution 에 1개 이상의 Trusted Key Group 생성 가능 (권장 방법이니 이쪽으로 강의가 나아감)
> 공용키 / 개인 키 생성 가능
> 개인키 같은 경우는 EC2 인스턴스 따위가 URL에 서명하려는 경우 따위에 사용된다
> 클라우드 프론트가 사용하는 (업로드하는?) 공용키는 URL 을 verify 하는데 사용된다
<실습>
> CloudFront 로 들어와서, 좌측 Key Management 안으로 들어옴
> Public Keys 에서는 RSA 키를 생성하는 것이 목적 (RSA 키란?)
> 공개키는 CloudFront 에서 사용된다. 개인 키는 EC2 인스턴스 따위에서 사용된다.
> 이렇게 함으로써 EC2 같은 것들이 CloudFront API 를 활용해서 CloudFront Signed URL 을 생성할 수 있다.
> 알아서 rsa key 를 만들었다고 하자 (구글에 그냥 generate rsa key 침 (이거 openssl 로도 가능함))
> 2048 bit 의 사이즈의 키를 생성했다. 이렇게 하면 private key, public key 가 같이 생성된다.
> Private Key 같은 경우에 보안화가 중요한 키이다. Public 같은 경우는 Private Key 를 사용해 얼마든지 재생성 할 수 있음
> 다시 Cloud 로 돌아와서 Create Public Key 를 하고, Key 내용은 아까 만든 Public Key 를 복붙하면 된다
> Key Group 형성으로 간다. 그러면 Key Group 을 만들고, Public Key 를 등록할 수 있다 (5개까지)
> 그럼 이 Key Group 은 CloudFront 가 사용자 (Ec2 인스턴스 따위)가 서명된 URL 을 생성할 수 있도록 허용해주기 위해 사용된다.
> 이 때 root account 를 많이 사용해서 만들겠지만, 권한이 있다면 키 그룹 생성은 IAM 계정도 가능하다
> Root 계정으로 접근해 IAM 에 [보안자격증명] 으로 이동한다
> 내려보면 CloudFront Key Pair 섹션이 있는데, 이게 아까 말한것중 두번째 방법 (권장X) 에 해당한다
> 그러면 어찌어찌 키 페어를 만들 수 있다. 이렇게 개인키를 생성한 뒤 EC2 인스턴스에 직접 전달해야 한다. 안전하지도 않고, 루트 계정을 사용해야 함 ->> 시험 입장에선 무조건 CloudFront 서비스 안에서 Trusted Key Group (키 그룹)을 만드는걸 권장한다.
165강 - <CloudFront 고급기능>
<Pricing : 요금과 가격등급>
>Edge Location 에 따른 데이터 전송 비용도 다 다르다. (인도가 ㅈㄴ 비싸다는 듯? 대용량일 수록 data 단위당 요금이 싸다)
<Price Classes>
> CloudFront 에서 사용할 엣지 로케이션을 줄여서 요금을 절약할 수 있음
>> ALL CLASS : 제일 좋은 성능을 보이지만, 비용이 다소 높음 (인도쪽 요금을 사용하면 비싸진다) (
>> 200 CLASS : 가장 비싼 TOP 지역들을 제외한 200가지 지역을 포함한다 (아시아도 여기에 포함됨)
>> 100 CLASS : 가장 싼 100 개의 지역을 포함시켜준다(-유럽, 미국지역을 포함)
<Multiple Origin & Origin Group>
> 예를 들어, Content-type 혹은 path 에 따라 다른 오리진으로 보내고 싶을 수 있다고 했음
> /images/*, /api* 등등 >> 이거 Cache Behavior 설정으로 분리할 수 있다고 이전 수업에서 배웠음
> 이렇게 Multi Origin 을 지원했던 것, 이와 유사한게 Origin Group (이하 설명)
> 딱봐도 AA 에서 배웠던 Hot,warm,cold Spare Redundancy Tactic 과 유사할 듯
> one origin 이 장애 날 경우 장애 조치를 지원해서 Availability 를 높이는 것이다
> Origin Group 은 한개의 주된 origin 과 한 개의 secondary origin 이 존재한다
> 주 오리진이 장애가 난다면, 보조 오리진이 동작하기 시작한다
> 주된 오리진으로 부터 err 가 발생할 경우, 동일한 요청을 보조 오리진에 시도하게 된다
> S3 로도 활용할 수 있음. 주된 S3 와 보조 S3 의 Origin Group 이 있다고 해보자. (둘이 다른 지역에 있다고 하면, 이 버킷들 사이에 복제 관계를 등록해볼 수 있다. 그러면 A에 모든 것들이 B에도 등록되게 된다)
> A 오리진으로 요청을 보냈는데 어떤 이유로 오류를 회신했다면, 동일한 요청을 보조에게 보내게 된다 (Replication 으로 등록되어 있어서 동일한 객체들을 모두 가지고 있다)
> 배우는 내용들.. 너가 이렇게 하라는게 아니고 ㅋㅋ 자격증 준비하잖아. S3 버킷에 대한 지역 단위 재해에 대해 복구가 가능한 훌륭한 구조를 구축할 수 있는 것임 (CloudFront 를 활용해서 클라이언트 단에는 인지할 수 없도록 함)
> 근데 내가 궁금한건 이런걸 ALB 로 하느냐 뭐 어떤걸로 하느냐랑 뭐가 그렇게 다르냐는 거임. (이거는 언제나 생기는 의문, 언젠가 한번에 다같이 정리해볼 필요가 있을 듯)
<Field Level Encryption : 필드 수준까지의 추가 보안>
> Application Stack 을 통해 유저의 Sensitive 한 정보를 보호한다.
> HTTPS 와 더불어 부가적인 보안을 강화해준다 (Using Asymmetric Encryption : 비대칭키 사용)
> Client 가 민감한 정보를 요청할 때 CloudFront 가 이를 감지하고, 개인 키에 대한 권한을 가진 사용자만이 이 정보를 해독할 수 있도록 암호화하는 개념
> 예시로, 만약 POST 요청을 보낼때 CloudFront 가 수신하게 되는 구조라면, 이 때 encrypt 되길 원하는 필드를 최대 10개까지 지정할 수 있다. 이 때 암호화하기 위한 public Key 도 같이 전달한다 (수신단에서 비공개키를 활용하는 구조)
> 위 예시를 보면, HTTPS 로 통신을 하고, 각각 보안화된 친구들에게 통신하기 위해 프록싱처럼 진행하게 된다. 이처럼 보안화를 ㅣㄴ행하긴 하지만, 우린 여기서 필드 수준의 암호화를 하고 싶은 거임 (신용카드 정보, 부가 암호 정보 등)
> 우리가 EdgeLocation 에게 암호화 원하는 필드와 공개키를 같이 전달하는 것임. 그럼 EdgeLocation 이 이를 암호화해서 추후 통신으로 전달한다.
> 이는 쭉 전달되어 Web Server 가 Private Key 로 Decrypt 하여 사용할 수 있다.
> 중간 CloudFront, ALB 모두 이 정보에 대해 알 수가 없음.
166강 - <Real Time Logs>
> CloudFront 에서 수신하는 모든 요청은 Kinesis Data Stream(?) 이란 곳으로 실시간 전달되도록 할 수 있다
> 콘텐츠 전송 성능을 모니터링 / 분석 / 필요시 조치 취하기 위함
> 람다 함수에서 이 Kinesis Data Stream 에 대한 것들을 처리하도록 할 수 있다
> Near-Real-Time 으로도 가능한데, 마지막에 람다 처리가 아닌 Kinesis Data Firehose 를 사용하여 records 들을 배치 처리 할 수 있고, S3, OpenSearch 등 원하는 곳으로 보낼 수 있도록 할 수 있다
> Sampling Rate 를 제어할 수 있고 (모두 다하면 너무 과한 서비스일 수 있음), Specific Field, and specific Cache Behavior 에 대해서만 하도록 지정할 수도 있다.
<퀴즈>
1. S3 에 저장된 유료 콘텐츠가 있음. 이를 전역으로 배포하고 싶으므로, CloudFront Distribution 과 데이터만 교환하도록 S3 버킷을 구성함. 앞단에 인가처리가 필요하므로, CloudFront Signed URL 을 사용해서 처리할 수 있다
2. CloudFront 에서 미국 사용자만 허용, 다른 국가 차단하려면? > Edge Location 차단이 아닌, 국가 자체를 차단하는거니 Geo Location 을 이용해야 함.
3. 사용자가 CloudFront 를 통해서만 웹 사이트에 액세스 하려고함 > CloudFront 배포 구성시 버킷 정책을 활용해야 함 (CloudFront Distribution OAI 사용자의 요청만 수락)
4. ALB 와 연결된 CloudFront 가 있다. CLoudFront 배포에서 Origin 측의 수백개의 비공개 파일에 대한 액세스를 제공하려면? Signed URL 도 맞지만, 개별보단 하나로 제어가 나으니 Cookie 가 답일듯 (앞단에서의 인증인가를 진행해서 URL/쿠키를 발급후, 이를 사용해서 CloudFront 에게 요청하라고 함) -> 근데 그럼 결국 자신이 수신 아님? ㅋㅋ, 인증 인가 앱은 다른건가? 아니면 서비스 계층 별로 구분한건가
5. CloudFront 가 S3 버킷을 사용할 수 있는 Policy 원문임. 강의 중 초반 설정에 나옴.
6. 새 업데이트가 즉시 전파되려면 Invalidation 을 사용
7. A 리전의 S3 버킷에 매우 동적인 콘텐츠를 호스팅중. 이 데이터를 다른 지역의 AC 리전에서 짧은 지연 시간으로 사용 가능하게 하고 싶음. 어떻게 가능? CLoudFront 라고 했다가 틀림. 정답: S3 Cross Region 복제. 이게 왜 여기 나오는진 모르겠음. 아까 Origin Group 할 때 Region Replication 잠깐 나와서 그럼?
8. CLoudFront 는 HTTP 메소드를 기반으로는 캐시할 수 없다..
9. CloudFront 키 쌍 구성할 때는 새로 생긴 Trusted Key Group 을 사용하는게 나음. (보안 자격 관리 탭의 CloudFront Key Pair 는 안전하지 않고 예전에 사용하던 것)
섹션 15 종료
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 19 - AWS 통합 및 메시징: SQS, SNS (0) | 2024.07.21 |
|---|---|
| [CDA] 섹션 18 - AWS CloudFormation (0) | 2024.07.17 |
| [CDA] 섹션 17 - AWS Elastic Beanstalk (0) | 2024.07.15 |
| [CDA] 섹션 16 - ECS, ECR 및 Fargate - AWS 의 도커 (0) | 2024.07.10 |
| [CDA] 섹션 14 - Amazon S3 보안 (0) | 2024.07.08 |
