Intro.
S3에 프론트 정적 파일을 업로드하고 정적 웹 사이트 호스팅을 설정만 하면 바로 정적 페이지로 사용할 수 있다.
그럼에도 CloudFront를 사용하는 이유는 성능 이슈가 가장 크다. CloudFront는 CDN(Content Delivery Network)으로 지리적으로 분산시켜 놓은 서버에서 데이터를 캐싱하여 짧은 대기 시간과 빠른 전송 속도로 콘텐츠를 전송하는 서비스다.
0. 전체 구조
- end user가 request를 cloudFront에 보내고 cloudFront는 캐싱된 데이터가 있다면 S3에 접근하지 않고 reponse를 리턴한다.
- 하지만 캐싱된 데이터가 없다면, S3에 요청을 보내 response를 받고 해당 response를 end user에게 리턴해준다.
- 이 과정에서 서버 리소스가 필요하다면 서버, 데이터베이스에 요청해 받은 response를 end user에게 응답해준다.
0.1 S3만 사용
- 화살표에서 알 수 있듯이 사용자가 콘텐츠를 요청할 때마다 요청은 퍼블릭 인터넷을 통해 원본 위치인 유럽의 S3 버킷으로 전송됩니다.
- 이때 사용자의 위치에 따라 전송 시간은 길어질 수 있습니다. 이렇게 시간이 지연되면 일부 사용자 요청이 반송되어 페이지에서 오류를 반환할 가능성도 있습니다.
0.2 S3 + CloudFront 사용
- S3만 사용하는 것보다 CloudFront를 사용하는 것이 비용도 더 싸다.
- 요청이 “지연 시간을 최소화하는”, 즉 전송 속도와 관련하여 가장 가까운 엣지 로케이션으로 라우팅됩니다. 그러면 초록색 화살표가 가리키듯이 CloudFront가 가까운 거리에서 요청한 사용자에게 캐싱된 콘텐츠를 직접 빠르게 제공합니다.
- 이때 콘텐츠가 엣지 서버에 아직 캐싱되어 있지 않으면 CloudFront가 S3 버킷 오리진에서 해당 콘텐츠를 가져옵니다.
- 그 밖에도 콘텐츠가 퍼블릭 인터넷이 아닌 AWS 프라이빗 네트워크를 통해 전송되는 동시에 CloudFront가 TCP 핸드셰이크를 최적화하기 때문에 요청 및 콘텐츠 반환 속도가 퍼블릭 인터넷을 통해 액세스하는 것보다 훨씬 빠릅니다.
1. S3
Intro. S3의 내부원리는?
S3의 내부원리를 알기 위해서는 Cloud라는 개념을 이해해야 한다. 리소스를 프로비저닝해서 사용하는 것을 의미한다. S3는 스토리지를 프로비저닝해 내가 원하는 공간을 사용하는 것을 의미한다. 그래서 내가 할당 받은 공간을 운영하는 instance(ec2)는 내가 컨트롤할 수 없지만 할당 받은 공간은 내가 컨트롤이 가능하다. S3는 글로벌 리전이지만, 버킷을 생성하려면 region을 선택해야만 한다. 왜냐하면 해당 리전에서 운영되는 instance 내부에 스토리지 공간을 프로비저닝 받아 사용자가 해당 버킷을 사용할 수 있는 구조이기 때문이다.
[1] workflow
버킷 만들기 > 버킷 클릭 > 속성 > 정적 웹 사이트 호스팅 > 활성화 > index.html > 저장
[2] 버킷 생성
- 버킷명은 route 53과 매칭시킬 도메인과 똑같은 이름을 사용해야 한다.
- 버킷의 리전을 선택한다.
- 버킷 버전관리, 암호화, 고급 설정 모두 보안에 관련된 것들이다. 그냥 디폴트로 놓아도 무방하다.
- 다만 퍼블릭 액세스는 꼭 차단하고 사용하길 바란다.
1) 버킷 버전 관리
- 형상 관리라고 생각하면 편하다.
- 전에 사용하단 버전을 삭제하지 않는다는 의미
2) 기본 암호화
(1) 암호화 방식이란
- 암호화 방식에는 서버 사이드 암호화와 클라이언트 사이드 암호화 방식이 있는데, S3는 서버 사이드 암호화 방식을 지원.
- SSE(Server Side Encryption)는 서버(aws)에서 데이터를 encryption하고 저장하고 데이터를 서버에서 가져올 때 복호화시키는 방법
- CSE(Client Side Encryption)는 클라우드 서버에 데이터를 전송하기 전에 암호화해서 데이터를 보내는 방법
(2) 서버측 암호화
- Amazon S3 관리형 키(SSE[Server Side Encryption]-S3) 선택
- KMS는 cloudfront가 지원하지 않으므로 사용하지 말 것.
[3] 정적 웹사이트 호스팅 설정(Optional)
- cloudFront에서 도메인을 제공하므로, S3로 직접 웹 호스팅을 할 계획이 아니라면 설정하지 않아도 된다.**
버킷 클릭 > 속성 > 정적 웹 사이트 호스팅 > 편집 클릭
정적 웹 사이트 호스팅을 활성화시켜야한다.
- 정적 웹 사이트 호스팅을 활성화시켜주고, 인덱스 문서 기본 페이지 html 파일을 지정해주면 된다.
- 오류가 발생했을 때나, 기타 상황에서 리디렉션 규칙도 정할 수 있다.
1) 정적 웹 사이트 호스팅
- 활성화
2) 호스팅 유형
- 정적 웹 사이트 호스팅 선택
- 객체에 대한 요청 리디렉션은 CloudFront를 사용하지 않고 해당 버킷으로만 정적 페이지로 활용하려면 선택
3) 인덱스 문서
- 해당 도메인에 접근했을 때, 랜더링되는 첫 페이지
- index.html
2. CloudFront
Intro. CloudFront
- Amazon CloudFront는 짧은 대기 시간과 빠른 전송 속도로 전 세계 고객에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 전달하는 고속 콘텐츠 전송 네트워크(CDN)[Content Delivery Network] 서비스
- S3로 정적 웹 사이트 호스팅을 설정을 했다면, CloudFront로 CDN 작업을 진행할 수 있다.
[1] workflow
배포 생성 > 원본 도메인 선택 > 예, OAI 사용 선택 > 원본 액세스 ID가 없다면, 새 OAI 생성 클릭 > 예, 버킷 정책 업데이트 클릭 > Origin Shield 클릭 > Redirect HTTP to HTTPS 클릭 > 허용된 HTTP 방법에서 GET, HEAD 클릭 > 대체 도메인 이름(CNAME) 추가 > SSL 인증서 추가
[2] CloudFront 배포 생성
- 배포 생성 클릭
1) 원본 도메인
- 정적 웹 호스팅 할 S3 버킷을 선택
- 동적 웹 호스팅을 하려면 ELB(Elastic Load Balancer)를 선택(해당 내용은 나중에 기회가 되면 다뤄보겠다.)
2) 원본 경로
- 캐싱을 하는데 하나의 스태틱 파일에서 여러 가지를 캐싱하고 싶을 때 사용.
- 데브 정적 서버, prod static server 등
- ex) /prod, /image
- 그래서 사용자가 브라우저에 example.com/index.html을 입력하면 CloudFront는 Amazon S3에 DOC-EXAMPLE-BUCKET/prod/index.html에 대한 요청을 보냅니다.
3) S3 버킷 액세스
- 예, OAI 사용 클릭
- OAI 사용 클릭 : 만약 원본 액세스 ID가 없다면 새 OAI 생성 클릭해 해당하는 S3 버킷에 맞는 OAI 생성
4) 버킷 정책
- 예, 버킷 정책 업데이트 클릭
- 그럼 자동으로 버킷 정책을 업데이트 해준다.
1) Origin Shield 활성화
- 예 클릭 후 리전 서울 선택
- 서울 리전을 Origin Shield로 하는 이유는 오리진에 대한 대기 시간이 가장 짧은 AWS 리전에서 Origin Shield를 활성화해야 향상된 네트워크 성능을 얻을 수 있음
(1) Origin Shield 사용 이유
- 향상된 캐시 적중률
- Origin Shield를 활성화하면 캐시 적중률을 개선하고 오리진의 부하를 줄이며 성능을 향상시킬 수 있다.
- Origin Shield를 활성화 하면 캐시 적중률을 거의 100%까지 늘릴 수 있다.
- 오리진 부하 감소
- 오리진으로 전송되는 동시 요청 수를 줄일 수 있음
- 향상된 네트워크 성능
2) 추가 설정
- 기본 값(최대 값)으로 설정
1) 경로 패턴
- 여러 경로 패턴을 두어서 매칭 되는 경로 패턴에 맞는 캐시 동작을 커스터마이징 할 수 있다.
- 만약에 3가지의 경로 패턴이 있다면,
(1) images/*.jpg
(2) images/*
(3) *
- 그리고 요청 url이 images/123.gif 라면 (2)번에 설정 된 캐시가 동작을 하게 된다.
2) 자동으로 객체 압축
- Yes 클릭
- CloudFront가 콘텐츠를 압축하면 파일 크기가 더 작아지므로 다운로드 속도가 빨라지고 웹 페이지는 사용자에게 더 빨리 렌더링됩니다.
3) 뷰어 프로토콜 정책
- Redirect HTTP to HTTPS 클릭
4) 허용된 HTTP 방법
- GET, HEAD 클릭
- 허용된 HTTP 방법은 GET, HEAD로 설정한다.
- 정적 리소스를 배포할 것이기 때문에 다른 HTTP Method를 허용하지 않아도 된다.
- 왜냐하면 cloudfront에서 정적 리소스를 다루므로, 객체를 create, update, delete를 하지 않을 것이기 때문이다.
1) 캐시 정책
- S3에 맞는 정책을 선택하면 된다.
2) 원본 요청 정책
- origin domain에 요청을 할 때, 참고하는 내용이다.
- 이 정책에 따라서 origin에 허용할 것과 거절할 것을 결정한다.
- 관리형 정책과 커스텀 정책이 있다.
- 관리형 정책은 aws가 미리 생성해 놓은 정책이고,
- 커스텀 정책은 유저가 직접 만드는 정책이다.
3) 응답 헤더 정책
- CORS 헤더를 추가하고 구성할 수 있다.
- 이 목록은 응답 헤더 정책에서 설정 및 유효한 값을 지정하는 방법에 중점을 둔다.
1) 스무스 스트리밍
- 비디오 스트리밍을 하지 않을 예정이므로 그냥 나둘 것.
2) 실시간 로그 활성화
- 내부적으로 Amazon Kinesis Data Streams 사용
- CloudFront 실시간 로그를 사용하여 배포에 대해 이루어진 요청에 대한 정보를 실시간으로 제공합니다(로그는 요청을 받은 후 몇 초 내에 전달됨).
- 실시간 로그를 사용하여 콘텐츠 전송 성능을 모니터링 및 분석
- 핵심은 콘텐츠 전송 성능을 모니터링하기 위함이므로 No을 선택
1) 함수 연결
- 이 캐시 동작과 연결할 엣지 함수와 함수를 호출하는 CloudFront 이벤트를 선택합니다.
- Amazon CloudFront를 사용하면 자체 코드를 작성하여 CloudFront 배포에서 HTTP 요청 및 응답을 처리하는 방법을 사용자 지정할 수 있다.
- CloudFront 배포에 작성하고 연결하는 코드를 엣지(edge) 함수
1) 가격 분류
- 모든 엣지 로케이션에서 사용 선택
2) AWS WAF 웹 ACL
- WAF가 Web Application Firewall의 약자
- 보통 DDos 공격에 대비하기 위해 설정
3) 대체 도메인 이름(CNAME)
- DNS를 추가한다면, (예시) test.com 으로의 모든 요청은 test.com.s3-website.Region.amazonaws.com으로 라우팅된다.
- SSL 인증서 선택
- 보안 정책은 권장 값
- 지원되는 HTTP 버전 최신까지 체크
1) 기본값 루트 객체
- 도메인에 접근했을 때 기본 파일 적기.
2) 표준 로깅
- 이러한 로그 파일에는 CloudFront에서 수신하는 모든 사용자 요청에 대한 세부 정보가 포함됩니다.
- 이러한 로그는 표준 로그라고 하며 액세스 로그라고도 합니다.
- 표준 로그를 활성화하면 CloudFront에서 파일을 저장할 Amazon S3 버킷도 지정할 수 있습니다.
3) IPv6
- 끄기 선택
- IPv4를 거의 대부분 사용한다.
- 한국인터넷진흥원에서 IPv4와 IPv6 사용 현황을 확인해보시길 바란다.
3. Route 53
Intro.
- example.com과 같은 도메인에 대해 호스팅 영역을 생성한 후, 트래픽을 도메인에 라우팅하는 방식을 Domain Name System(DNS)에 알려줄 레코드를 생성한다.
- 호스팅 영역을 생성했다고 가정한다.
[1] workflow
호스팅 영역 생성 > 레코드 생성 > 레코드 유형 A 선택 > 별칭 클릭 > 트래픽 라우팅 대상 cloud front 선택 > 배포 선택 > 레코드 생성 클릭
[2] 레코드 생성
1) 레코드 이름
하위 도메인 이름을 입력.
루트 도메인을 만들고 싶다면 빈 공간으로 생성
2) 레코드 유형
A - IPv4 선택
ps. 만약 IPv6 도 허용해야한다면, 동일한 레코드로 AAAA - IPv6를 선택해서 만들어줘야 한다.
3) 별칭
별칭을 클릭해주면, 선택한 AWS 리소스로 트래픽을 라우팅 할 수 있다.
4) 라우팅 정책
- 라우팅 정책의 핵심은 고가용성과 내결함성(Fault Tolerance)이다.
- Route 53이 트래픽을 리소스로 라우팅하는 방식을 선택 가능. 동일한 작업을 수행하는 리소스가 여러 개(2~10개의 ec2) 있는 경우 단순 이외의 라우팅 정책을 선택
- 라우팅 정책은 말 그대로 네트워크 단계에서 트래픽을 분산할지 말지를 결정하는 policy다. 해당 트래픽을 그대로 default vpc에 넣어주고 그 안에서 elb가 작동해 트래픽을 분산시켜주는 구조이다.
references
1) S3
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/serv-side-encryption.html
https://aws.amazon.com/ko/blogs/korea/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/
: s3 with cloudfront 작동 원리
2) CloudFront
https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html
3) Route 53
https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/ResourceRecordTypes.html
https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-policy.html
4) 국내 및 해외 IPv4와 6 사용현황 (한국인터넷진흥원 출처)
'AWS' 카테고리의 다른 글
| [SAA] AWS Solutions Architect Associate 합격 후기 (0) | 2022.08.24 |
|---|---|
| AWS CloudFront reload error (0) | 2022.08.13 |
| IAM 계정 설정 (0) | 2022.07.25 |
| [Github Action] Application Load Balancer 상태 확인이 실패하는 문제를 수정 및 해결 방법(추가 배치를 사용한 롤링) (0) | 2022.07.18 |
| .ebextensions + private S3 버킷 접근 설정 (0) | 2022.07.18 |
