2017년 8월 8일 화요일

[AWS] Apex 시작하기

Apex 시작하기

Apex 란?

Apex는 AWS Lambda Function을 로컬PC에서 빌드하고, 배포하고, 관리하는 Tool입니다.
공식 Github Repository
https://github.com/apex/apex
본 글에서는 Apex을 설치하고 이를 이용하여 AWS Lambda에 Function을 배포하는 절차를 정리해보려 합니다.

1. Apex 설치

저는 Windows 환경에서 진행합니다. 그래서 설치가 명령어 한줄 입력하는 게 아니라,
https://github.com/apex/apex/releases 에서 운영체제에 맞는 설치파일을 다운받아야합니다.
저는 apex_windows_amd64.exe를 받았습니다.
근데, exe를 받았는데 이걸로 설치하는 형식이 아닙니다.
단순히 cmd 또는 powershell로 열어서 저 파일명 전체를 명령어로 사용하는 것입니다. 아래 처럼요.
PS C:\{파일경로}> .\apex_windows_amd64.exe version
Apex version 0.15.0
참으로 불편하지요...
다행히 Powershell에서는 명령어 Alias 설정이 가능합니다.
아래와 같이 하면 apex 만 입력해도 apex 명령어 사용이 가능합니다.
절대경로로 입력해야 어떤 디렉토리 위치에서도 apex 명령어를 사용할 수 있습니다.
Set-Alias apex {apex이 설치된 절대경로}\apex_windows_amd64.exe

2. Apex에 AWS credentials 설정

AWS CLI에 AWS credentials 정보만 잘 기입하면 됩니다.
Apex은 단지 AWS CLI를 이용할 뿐인거 같습니다. 그러니 AWS CLI에 credentials 정보를 잘 설정해줘야합니다.

3. 사용자 계정에 필수 권한 부여

AWS CLI에 입력한 사용자 계정은 아래 권한이 필수적으로 있어야 Apex 사용이 가능합니다.
Apex을 사용하기 위한 최소한의 권한입니다.
IAM에서 새로운 Policy를 생성하여 아래 JSON 문서를 넣어주고 해당 Policy를 AWS CLI에 등록한 사용자 계정에게 부여하면 좋습니다.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "iam:CreateRole",
        "iam:CreatePolicy",
        "iam:AttachRolePolicy",
        "iam:PassRole",
        "lambda:GetFunction",
        "lambda:ListFunctions",
        "lambda:CreateFunction",
        "lambda:DeleteFunction",
        "lambda:InvokeFunction",
        "lambda:GetFunctionConfiguration",
        "lambda:UpdateFunctionConfiguration",
        "lambda:UpdateFunctionCode",
        "lambda:CreateAlias",
        "lambda:UpdateAlias",
        "lambda:GetAlias",
        "lambda:ListAliases",
        "lambda:ListVersionsByFunction",
        "logs:FilterLogEvents",
        "cloudwatch:GetMetricStatistics"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

4. Apex 프로젝트 생성

Apex을 이용한 프로젝트는 아래 명령어로 시작합니다.
apex init
init 명령을 입력하면 아래와 같은 화면이 출력됩니다.
Project name과 Project description을 입력하면 apex이 자동으로 필요한 role과 policy를 aws에 생성하고, 기본 파일구조를 생성합니다.
이때 생성되는 role과 policy는 CloudWatch에 Log를 남길 수 있는 권한입니다.
PS C:\> apex init


             _    ____  _______  __
            / \  |  _ \| ____\ \/ /
           / _ \ | |_) |  _|  \  /
          / ___ \|  __/| |___ /  \
         /_/   \_\_|   |_____/_/\_\



  Enter the name of your project. It should be machine-friendly, as this
  is used to prefix your functions in Lambda.

    Project name: pcm-tutorial

  Enter an optional description of your project.

    Project description: This is test project.

  [+] creating IAM pcm-tutorial_lambda_function role
  [+] creating IAM pcm-tutorial_lambda_logs policy
  [+] attaching policy to lambda_function role.
  [+] creating ./project.json
  [+] creating ./functions

  Setup complete, deploy those functions!

    $ apex deploy

프로젝트를 생성하면 기본 예제가 함께 생성되는데,
위 출력문의 제일 마지막에 있는 apex deploy를 실행하면, 이 기본 예제가 AWS Lambda에 배포됩니다.
PS C:\> apex deploy
   • creating function         env= function=hello
   • created alias current     env= function=hello version=1
   • function created          env= function=hello name=pcm-tutorial_hello version=1
Apex을 이용하면 AWS Lambda를 호출하는 것도가능합니다. 방금 배포한 예제를 호출해 볼 수 있습니다.
apex invoke hello
아래 결과를 응답 받습니다.
{"hello":"world"}

5. Apex 프로젝트 기본 파일 구조

Apex 프로젝트의 기본 구조는 다음과 같습니다.
project.json
functions
├── bar
│   ├── function.json
│   └── index.js
└── foo
    ├── function.json
    └── index.js
project.json파일에는 프로젝트의 이름과 설명, 그리고 프로젝트 레벨의 설정들이 있습니다.
functions폴더 하위에 여러 Lambda 함수들이 위치합니다.
위 예제 구조에서는 bar 함수와 foo 함수가 있습니다.
각 Lambda 함수에는 함수를 수행하는 index.js파일과 함수의 설정 파일인 function.json이 있습니다.

마무리

Apex에서 기본 예제를 제공해주고, Apex 공식 홈페이지(http://apex.run)을 보면 Apex 설정부터 사용까지 자세하게 잘 나와 있어서 잘 알아두면 Lambda를 편리하게 사용할 수 있을 것 같습니다.

참고 링크

2017년 8월 7일 월요일

[AWS] AWS CLI(Command Line Interface) 시작하기

AWS CLI(Command Line Interface) 시작하기

AWS CLI란?

AWS 명령줄 인터페이스(CLI)는 AWS 서비스를 관리하는 통합 도구입니다. 도구 하나만 다운로드하여 구성하면 여러 AWS 서비스를 명령줄에서 제어하고 스크립트를 통해 자동화할 수 있습니다.
https://aws.amazon.com/ko/cli/ )

1. AWS CLI 설치

Windows 64bit 는 msi 설치파일로 설치합니다.
위 링크에서 다운로드 가능합니다.
설치과정에서는 특별한 설정이 필요 없습니다. 그냥 동의함 잘 누르고 Next 잘 누르고 Install 잘 누르면 설치가 간단히 끝납니다.
설치 확인은 cmd 또는 powershell을 열고, 아래 명령어로 확인합니다.
aws --version

2. AWS CLI에 AWS 계정 정보 설정하기

aws-cli에 AWS 계정을 연결해야합니다.
configure 명령으로 정보를 기입하면 되는데, 필요한 정보를 먼저 준비합니다.

2-1. IAM User 생성

AWS Console에서 IAM에 접속합니다.
왼쪽 Users 메뉴를 누릅니다.
기존에 생성된 User가 CLI를 사용하게 하려면 해당 User의 Access Key와 Secret Key를 준비하면 됩니다.
기존에 생성된 User가 없거나 새로 생성해서 CLI를 사용하게 하려면 Add user를 눌러서 새로운 사용자를 만드는 절차에 들어갑니다.



User name에 추가할 사용자의 이름(ID)를 입력합니다.
아래 Access type에서는 Programmatic access를 반드시 선택합니다. 설명에도 나와있듯이 이 항목을 선택해야 지금 생성하는 사용자가 CLI를 이용할 수 있습니다.
만일 사용자가 AWS Console에서도 AWS 서비스를 이용하게 하려면 AWS Management Console access항목도 선택해주면 됩니다.
Next: Permissions를 눌러서 다음 단계로 갑니다.



다음 단계는 지금 생성하는 사용자에게 AWS 자원에 접근할 수 있는 권한을 주는 것입니다.
권한을 주는 방식이 3가지가 있습니다.
첫번째는 지금 생성하는 사용자를 이전에 만들어 놓은 그룹에 추가시키는 것입니다.
그렇게 하면 해당 그룹이 가지고 있는 권한이 자동으로 사용자에게도 적용됩니다.
두번째는 이전에 만들어 놓은 사용자에게 부여한 권한을 복사해서 지금 생성하는 사용자에게 부여하는 것입니다.
세번째는 지금 생성하는 사용자에게 바로 Policy(권한 정책)을 부여하는 것입니다.
저는 3번째 방법으로 진행하였습니다.
Next: Review를 선택하여 다음 단계로 갑니다.



다음 단계는 그냥 입력한 내용들을 Review 하는 것입니다.
확인하고 이상없으면 Create user 버튼을 누릅니다.



성공적으로 사용자를 새로 생성하면 해당 사용자의 Access key ID와 Secret access key를 확인 할 수 있고, csv 파일로 다운로드 할 수 있습니다.
주의할 점은 현재 페이지에서만 Secret access key를 확인할 수 있고, 다운로드 할 수 있다는 것입니다.
보안상 Secret access key는 최초에 한번만 알려주며, 나중에 잊어버리면 새로 Access key ID와 Secret access key를 발급받아야합니다.



2-2. AWS CLI에 사용자 정보 설정하기

aws-cli를 이용하기 위해서는 당연히 어떤 사용자 계정의 리소스에 접근할지 aws-cli가 알아야합니다.
그 설정을 아래 명령어로 진행합니다.
aws configure
명령어를 입력하면 아래 항목들을 하나씩 묻습니다.
위에서 생성한 Access Key ID, Secret Access Key를 입력하고, Default region name은 주로 사용하는 리전 이름을 입력합니다. region 이름은 Seoul 같이 지역명을 입력하는게 아니고 ap-northeast-2와 같은 이름을 입력합니다. ap-northeast-2 는 서울리전입니다.
Default output format은 비워두셔도 좋습니다.
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: ap-northeast-2
Default output format [None]:

3. AWS CLI를 이용한 S3 버킷 리스트 확인하기

AWS CLI를 설치하고 필요한 정보를 설정했으니, AWS CLI를 이용하여 AWS 서비스에 접근할 수 있습니다.
다만 위에서 사용자 계정이 권한을 할당 받은 서비스만 이용할 수 있습니다.
저는 S3 접근 권한을 줬습니다. 그래서 S3 버킷 리스트를 확인해보겠습니다.
aws-cli에서 S3를 제어 할 수 있는 명령어 목록은 다음 링크에서 확인 할 수 있습니다.
http://docs.aws.amazon.com/cli/latest/reference/s3/#available-commands
버킷 리스트를 확인하는 것은 엄청 간단합니다.
aws s3 ls
위 명령어 하나면 버킷 리스트가 출력됩니다.

마무리

저도 AWS CLI를 그간 외면아닌 외면을 하다가 이제 써보려고 하는데,
Console에서 하나씩 서비스 사용법 알아간거 처럼 CLI도 하나씩 파고 나가면 재밌을 거 같습니다 ㅎㅎ

참고링크

2017년 6월 13일 화요일

[AWS] AWS S3를 Origin으로 설정한 CloudFront의 컨텐츠 갱신

AWS S3를 Origin으로 설정한 CloudFront의 컨텐츠 갱신

이전 포스팅에서 AWS S3를 Origin으로 설정해서 CloudFront의 distribution을 생성하는 방법을 정리해보았습니다.
(링크 : https://walkinpcm.blogspot.kr/2017/06/aws-aws-s3-static-website-hosting.html)
그런데 해당 포스팅을 공유했던 페이스북 게시글을 통해서 S3의 파일을 갱신했을 때 CloudFront에는 어떻게 갱신(재배포)하는지 질문을 주셨습니다.
해당 질문에 관해서 감사하게도 여러 분들께서 좋은 답변을 주셔서 저도 도움이 많이 되었습니다.
그래서 이번 포스팅에서 그 S3의 파일이 갱신되었을 때, CloudFront에 어떻게 갱신하는지 정리해보려합니다.

1. CloudFront의 기본 캐싱 기간

CloudFront에 배포된 컨텐츠는 기본적으로 24시간 동안 캐싱된다고 합니다.
그래서 S3의 원본 파일을 갱신하면 24시간 후에는 갱신한 파일로 변경됩니다.

2. 즉시 CloudFront 배포의 캐시를 지우기

이 방법은 CloudFront의 배포(distribution)에 저장되어 있는 캐시를 즉시 지워버려서 클라이언트의 요청이 들어왔을 때, 새롭게 Origin에서 컨텐츠를 가져오도록 하는 방법입니다.
배포된 캐시를 지우려면 Invalidations 기능을 이용합니다.
배포의 Invalidations 탭에서 Create Invalidation을 클릭합니다.
Object Paths에 친절하게 입력 예시가 나오는데, 예시처럼 특정 파일을 입력하거나 와일드카드(*)를 이용하여 경로를 입력하고 Invalidate를 클릭하면 입력한 파일들이 바로 배포에서 지워집니다.

입력 예시는 공식 문서에 자세하게 나와있습니다.
(링크('무효화 경로'를 찾으세요) : http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html#invalidation-specifying-objects )
Invalidate를 하자마자는 Status가 'In Progress'라고 표시되는데, 모든 엣지에서 지워지면 'Completed'로 변경됩니다.

3. 배포된 전체 컨텐츠 캐싱 시간 변경

CloudFront 배포(distribution)의 설정에서 전체 컨텐츠에 대한 갱신 주기를 설정할 수 있습니다.
해당 배포의 Behaviors 탭으로 갑니다.
배포를 생성할 때 설정된 항목이 하나 있습니다. 체크박스를 선택하고 Edit을 클릭합니다.

그러면 설정 변경화면이 나오는데, 여기서 Object Caching항목을 Customize로 선택합니다.
Customize를 선택하면 아래 3개 칸(Minimum TTL, Maximum TTL, Default TTL)이 활성화됩니다.
(각각에 대한 자세한 설명 : http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesObjectCaching)

Default TTL은 특정 객체에 HTTP Header를 지정하지 않은 오리진 객체에만 적용되는 값이고, Maximum TTL은 HTTP Header를 지정한 오리진 객체에만 적용되는 값입니다.
그래서 전체 컨텐츠에 대한 캐싱 시간을 변경하려면 Default TTL을 수정합니다. 초단위로 수정하시면 됩니다.
수정 완료하시면 배포의 상태가 In Progress가 되고 배포가 완료되면 Deployed로 변경됩니다.

4. S3에 저장된 특정 객체의 캐싱 시간 변경

S3의 특정 객체의 갱신주기만 따로 설정하려면 해당 객체에 metadata를 설정하면 됩니다.
S3에서 갱신주기를 설정할 객체를 선택합니다. 객체의 이름 부분을 선택하면 해당 객체에 대한 Overview가 나타나는데,
바로 옆에 Properties 탭을 선택합니다.

Properties 중에 Metadata를 클릭합니다.
그러면 Add Metadata 버튼이 있는데 여기를 클릭합니다.
Key 목록에서 Cache-Control 또는 Expires를 선택합니다.
Cache-Control로 선택하면 CloudFront 캐시에 머무르는 시간을 초단위(형식 : max-age=초)로 입력해주시면 되고,
Expires를 선택하면 캐시에 머무를 특정 날짜를 입력하시면 됩니다.(형식 : Sat, 27 Jun 2015 23:59:59 GMT)
(날짜 포맷 : https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1)



지금까지 S3를 Origin으로 한 CloudFront의 배포 즉시갱신/갱신 주기 설정 방법을 정리해보았습니다.
4가지 방법을 다 해보니.. 캐싱 시간을 변경하는 방법은 조금 부정확한 감이 있습니다. 캐싱 주기 시간이 지나고 최신 파일을 읽어왔다가 새로고침하면 다시 예전 파일을 읽어오더라구요.. 아마 모든 엣지마다 다시 배포되는 시간이 달라서 그런가 싶습니다..
혹시 본문 내용중 틀린 부분을 댓글로 남겨주시면 감사히 바로 수정하도록 하겠습니다.
감사합니다.

참고링크

2017년 6월 12일 월요일

[AWS] AWS S3를 이용한 static website hosting에서 Custom Domain과 HTTPS(SSL) 사용하기

AWS S3를 이용한 static website hosting에서 Custom Domain과 HTTPS(SSL) 사용하기


지금은 많은 사람들이 알고 있듯이, AWS S3를 이용하면 단순 파일 저장뿐 아니라 정적 웹호스팅(static website hosting)이 가능합니다.
그런데, 한가지 아쉬운 점은 S3에 업로드한 객체들 각각의 endpoint는 https가 기본지원되는 반면에, web hosting의 endpoint는 http만 지원하고 있습니다.
하지만 AWS CloudFront를 이용하면 S3의 web hosting에도 https를 사용하게 할 수 있습니다.
이번 포스팅에서는 S3를 이용한 static website hosting에서 Custom Domain과 HTTPS(SSL) 사용하는 방법을 정리해보겠습니다.

0. 사용하는 AWS 서비스

이번 포스팅에서는 4가지 AWS 서비스를 사용합니다.
  • Certificate Manager
    • SSL 인증서 생성.
  • S3
    • 웹호스팅 Origin.
  • CloudFront
    • 웹호스팅 파일들을 CDN에 올리고 SSL을 적용. 그리고 Custom Domain 설정.
  • Route53
    • CloudFront에 배포한 웹호스팅 도메인과 Custom Domain을 연결.

1. SSL 인증서 준비

본 포스팅에서는 HTTPS를 위한 SSL 인증서를 AWS Certificate Manager 서비스에서 만듭니다.
절차는 쉽지만 알아둬야할 사항이 있어서 글로 정리합니다.
(참고로, AWS Certificate Manager에서 만드는 SSL인증서는 무료입니다!)
우선, Certificate Manager 서비스에 들어갑니다.
가장 먼저 해줘야할 작업은 리전을 US East (N. Virginia)로 변경하는 것입니다.
왜냐하면, CloudFront에서 Custom SSL Certificate를 사용하려면 반드시 Virginia 리전에서 생성된 인증서만 허용되기 때문입니다.


리전을 바꿨으면 시작하기를 선택합니다.



도메인 이름은 인증서를 발급 받고 싶은 도메인 주소를 입력합니다.
ssltest.example.com 처럼 서브도메인을 포함한 주소를 입력해도 되고, *.example.com 처럼 서브도메인을 와일드카드로 입력해도 됩니다.
입력하고나면 검토 및 요청을 클릭합니다.



다음화면에서는 도메인 관리자에게 인증서 승인을 위한 메일을 보낸다는 안내가 됩니다.
확인 및 요청을 클릭합니다.



다음화면에서는 어떤 메일로 승인 요청을 보냈는지 나타납니다.(도메인 부분을 클릭하면 펼쳐집니다.)



계속 버튼까지 눌러줍니다.
(생성한 인증서 목록이 보일텐데 방금 만든 인증서의 상태가 '검증 보류'라고 나타날 겁니다.)
사실 승인 요청을 메일로 보내기 전에 위의 메일 주소들 중에 하나라도 생성되어 있어야하는게 맞는데...
제 경우에는 도메인을 Route53에서 만들었었더니, whoisprivacyservice.org 계정 3개로 보내진 인증서 승인 메일이 제 개인 메일로 전달(forwarding)되어져 왔습니다.
아래 그림 처럼 메일이 왔습니다.
가운데 쯤의 Amazon Certificate Approvals 링크를 누릅니다.



그러면 새창이 또 뜹니다. 여기서 I Approve 버튼을 누르면 인증서 승인이 완료됩니다.



승인이 완료되고 다시 Certificate Manager로 돌아와서 새로고침을 한번 해주면 상태가 '발급 완료'로 변경됩니다.
인증서 준비는 끝났습니다~!

2. S3 준비

S3에 버킷을 생성하고 파일들을 업로드 하고 버킷의 Properties에서 Static website hosting 기능을 활성화합니다.


버킷을 생성할 때 주의할 점이 하나 있습니다.
HTTPS 지원없이 Custom Domain만 사용하려면 Route53에서 S3를 바로 연결시키면 되는데, 이때는 버킷 이름이 Custom Domain이름과 같아야합니다. (ex. ssltest.example.com 으로 버킷 이름도 설정하고 도메인도 똑같은 이름으로 만들어야합니다.)
그런데 CloudFront를 S3와 Route53 사이에 껴넣을때는 버킷이름이 도메인 이름이랑 같으면 오히려 HTTPS 지원이 정상적으로 안됩니다. 제가 이 문제 때문에 하루를 버렸네요..ㅠㅠ
다시 본론으로.. 버킷의 Properties에서 Permissions에 가셔서 Bucket Policy에 아래 내용을 입력하고 Save합니다. Resource의 값 부분에 있는 [YOUR_BUCKET_NAME]을 본인의 버킷 이름으로 대체하시면 됩니다.
아래 Bucket Policy는 버킷으로 웹호스팅 할 때 전체 파일에 대해서 모든 사용자한테 Get을 허용하는 유용한 Policy입니다.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::[YOUR_BUCKET_NAME]/*"
        }
    ]
}

3. CloudFront 준비

CloudFront는 AWS의 CDN 서비스입니다.
AWS CloudFront 서비스에 들어가서 Create Distribution을 선택합니다.



다음 화면(Select delivery method)에서는 배포할 컨텐츠의 타입이 무엇인지 선택합니다.
여기서는 Web부분의 Get Started를 클릭합니다.



다음 화면(Create distribution)에서는 갖가지 설정들을 하게되는데, 필수적인 사항만 정리하겠습니다. 다른 설정들은 상황에 따라 알맞게 손 보시면 됩니다.
Origin Settings에서 Origin Domain Name을 선택합니다.
마우스로 선택하면 S3 버킷 목록이 나오는데, 위에서 만든 버킷을 선택하시면 됩니다.



Distribution Setting에서 Alternate Domain Names에 사용할 Custom Domain을 입력합니다. 이 이름은 나중에 Route53에 생성할 도메인과 동일해야합니다.
SSL Certificate는 Custom SSL Certificate를 선택합니다.
Default로 선택해도 동작에는 문제가 없지만 아래 그림처럼 경고가 뜹니다. 도메인 이름과 인증서 이름이 같지 않아서 발생하는 경고입니다.
노력해서 HTTPS를 쓰려고하는데 이런게 보이면 영 꺼림직 하지요..
그래서 Custom SSL Certificate를 선택하고 1번 단계에서 생성한 인증서를 선택해줍니다.

!!주의!! 1번 단계에서 생성한 인증서가 목록에 보임에도 불구하고 Custom SSL Certificate가 선택이 불가능하게 비활성화 되어 있을 수 있습니다.
찾아보니 이게 활성화 되는데는 인증서 생성 이후에 하루 정도가 걸릴 수 있다고 하네요... 저도 자고 일어나니 선택이 가능했습니다.

그리고 Default Root Object에는 도메인만 입력했을 때 바로 보여줄 파일이 무엇인지 설정하는 것입니다. 다들 아시는 index.html 로 입력하게 되실 것 같네요 ㅎㅎ



딱 4가지만 설정했습니다. 이렇게 설정하고 완료하면 생성한 Distribution의 General 속성에서 Distribution Status가 InProgress가 됩니다. 이 때가 각 엣지로 배포되는 중이라고 하네요.(조금 오래 걸립니다..)
배포가 완료되면 Deployed가 됩니다. 자동으로 되는게 아니니깐 새로고침 간간히 해서 확인해주세요~



Deployed를 기다리는 동안 Route53을 준비합니다.

4. Route53 준비

본 포스팅을 참고하시는 분들은 아마 자체 도메인을 이미 가지고 계실 것 같습니다.
그래서 Route53에 이미 기존에 사용하는 Hosted Zone이 있다는 가정하에 정리하겠습니다.


Route53의 Hosted zones에 가셔서 사용하실 도메인에서 Create Record Set을 선택합니다.
우측에 나타나는 입력창의 Name 입력칸에 CloudFront에서 Alternate Domain Names에 입력했던 서브도메인을 입력합니다.
(ex. Alternate Domain Names에 ssltest.example.com 이라고 입력했따면 Name 입력칸에 ssltest를 입력합니다.)
Type은 A - IPv4 address를 선택합니다.
그리고 Alias를 Yes로 선택합니다. 왜냐하면 CloudFront와 Route53을 연결할 때 별칭 리소스 레코드 세트를 사용하면 DNS 쿼리에 대한 요금이 지불되지 않는다고 합니다~!
Alias Target 입력칸을 클릭하면 CloudFront distribution에 위에서 생성한 distribution이 알아서 나타나있을 것입니다. 그걸 선택합니다. (Name을 입력해야 나타납니다.)
Create를 누르면 끝납니다.

5. 확인

이제 모든 절차가 끝났습니다. DNS에 도메인이 등록되는 시간을 잠시 기다리고나면 아래처럼 S3로 웹호스팅한 웹페이지가 HTTPS가 지원되는 걸 보실 수 있습니다!
수고하셨습니다~



* 내용 추가!
> S3에 업로드한 파일을 수정해서 다시 올렸을 때 어떻게 CloudFront에 갱신시키는지에 대한 내용을 아래 링크에 정리했습니다. 함께 보시면 좋을 것 같습니다~!
(링크 : https://walkinpcm.blogspot.kr/2017/06/aws-aws-s3-origin-cloudfront.html)

참고링크