AWS - S3, Cloudfront (정적 웹사이트 구축)

jsbak·2023년 4월 28일
S3cloudfrontsimple storage service
0

Cloud

목록 보기
41/59

S3(Simple Storage Service)

  • 확장성과 데이터 가용성 및 보안과 성능을 제공하는 객체 스토리지 서비스
  • 다양한 사용 사례에서 원하는 만큼의 데이터를 저장하고 보호 가능 ⭕
  • 사용하기 쉬운 관리 기능을 제공
    • 특정 비즈니스, 조직 및 규정 준수 요구 사항에 따라 데이터를 조직화하고 세부적인 액세스 제어 구성 가능 ⭕
  • 액세스 정책 지침 DOCS

용어

  • 액세스 포인트
    • GetObject 및 PutObject 같은 S3 객체 작업을 수행하는 데 사용할 수 있는 버킷에 연결된 네트워크 엔드포인트
    • 액세스 포인트는 정확히 하나의 Amazon S3 버킷과 연결된다.
  • 버킷
    • Amazon S3에 저장된 객체에 대한 컨테이너
  • 객체
    • 각 키가 존재 (키 이름), 이는 고유한 식별자이다.
    • 객체는 객체 데이터와 메타데이터로 구성
      • 메타데이터는 객체를 설명하는 이름-값 페어의 집합
    • 파일과 해당 파일을 설명하는 모든 메타데이터
  • 키
    • 객체 키(또는 키 이름)는 버킷 내 객체에 대한 고유한 식별자
    • S3를 “버킷 + 키 + 버전”과 객체 자체 사이의 기본 데이터 맵이라고 볼 수도 있다.
  • 객체 소유권
    • S3 버킷에 저장된 모든 객체에는 소유자가 있습니다. 이 소유자는 객체를 업로드한 AWS 계정입니다.
    • 객체 소유권은 객체와 연결된 액세스 제어 목록 (ACL)에 의해 결정됩니다. ACL은 권한 목록이며, 각 권한은 권한 부여자와 권한을 지정합니다.
    • 기본적으로 새 객체를 생성하면 AWS 계정이 소유자가 됩니다. 그러나 필요한 권한이 있으면 객체의 ACL을 수정하여 소유자를 변경할 수 있습니다.
  • 버킷 소유권 제어
    • 버킷 소유자가 아닌 계정이 소유한 버킷의 객체에 대한 시나리오를 해결하기 위해 도입되었습니다.
    • 버킷 소유자가 버킷 소유권 제어를 활성화하면 버킷 내의 객체의 항상 소유자가 됩니다.
  • 공개 액세스 차단
    • 아마존 S3는 버킷 및 계정 레벨 모두에서 공개 액세스를 관리하는 데 도움이 되는 공개 액세스 차단 설정을 제공합니다.
    • 이러한 설정은 공개 액세스를 허용하는 다른 S3 권한을 무시하므로 실수로 공개 노출을 방지하는 안전장치 역할을 합니다.
    • 공개 액세스 차단과 관련된 네 가지 설정
      • 새 액세스 제어 목록 (ACL)을 통해 부여된 버킷 및 객체에 대한 공개 액세스 차단
      • 모든 액세스 제어 목록 (ACL)을 통해 부여된 버킷 및 객체에 대한 공개 액세스 차단
      • 새 공개 버킷 정책을 통해 부여된 버킷 및 객체에 대한 공개 액세스 차단
      • 모든 공개 버킷 정책을 통해 부여된 버킷 및 객체에 대한 공개 액세스 차단

  • 객체 소유권과 공개 액세스 차단 간의 관계

    • 객체 소유자가 권한 (ACL을 통해)을 부여하여 객체를 공개하더라도 해당 객체가 있는 버킷에 공개 액세스 차단 설정이 활성화된 경우 객체는 공개적으로 액세스할 수 없습니다.
    • 공개 액세스 차단 설정은 객체 소유자가 지정한 모든 공개 액세스 설정을 무시합니다.
    • 이는 개별 객체 소유자가 객체를 공개하려고 해도 버킷 소유자의 선호도 (공개 액세스 차단)가 우선시 된다는 것을 보장합니다.

    결론적으로, S3의 객체 소유권은 객체에 대한 권한을 설정할 수 있는 사람을 결정하는 반면, 공개 액세스 차단 설정은 버킷 내의 모든 객체가 공개되지 않도록 하는 추가적인 보안 계층을 제공합니다.

정책

IAM 정책의 종류

  • Identity-based policies (자격 증명 기반 정책)
    • 자격증명(IAM 유저, 그룹, 역할)에 부여하는 정책
    • 해당 자격증명이 무엇을 할 수 있는지 허용
  • Resourece-based policies (리소스 기반 정책)
    • 리소스(ex: S3, SQS, VPC Endpoint, KMS 등)에 부여하는 정책
    • 해당 리소스에 누가 무엇을 할 수 있는지 허용 가능
      • 예: SQS 대기열에 Lambda Service가 접근 가능

S3 버킷 정책

  • 버킷 단위로 부여되는 리소스 기반 정책
    • 다른 AWS 계정 또는 IAM 사용자에게 액세스 권한을 부여하므로 버킷 정책에서 보안 주체 또는 액세스 권한을 부여할 사용자를 "보안 주체"로 지정해야 합니다.
  • 크기가 20KB로 제한
  • 해당 버킷의 데이터에 "언제 어디서 누가 어떻게 무엇을" 할 수 있는지 정의 가능
    • 리소스의 계층 구조에 따라 권한 조절 가능
      • 예: resource : "arn:aws:s3:::my-bucket/images/*" ➡️ my-bucket의 images/ 로 시작하는 모든 객체에 대해서...
    • 다른 계정에 엔티티에 대해 권한 설정 가능
    • 익명 사용자에 대한 권한 설정 가능
  • 기본적으로 모든 버킷은 Private (접근 불가능)

버킷 정책을 사용하는 경우

  • 사용자, 그룹 및 역할에 대한 IAM 정책에는 최대 크기 제한이 있어 이 IAM 크기 제한에 도달한 경우 버킷 정책을 이용
  • 버킷에 대한 정책만 부여하고 싶은 경우 IAM 정책 대신 버킷 정책을 이용
  • IAM 정책을 사용하지 않고 교차 계정 권한 부여하는 경우
  • S3 환경에서 액세스 제어 정책을 유지 하는 것을 선호하는 경우

IAM 사용자 정책을 사용하는 경우

  • S3 이외의 AWS 서비스에 대한 액세스를 제어해야하는 경우
    • IAM 정책을 이용하면 모든 권한을 중앙 집중식으로 쉽게 관리 가능
  • 다수의 S3 버킷 정책을 정의하는 것보다 IAM 정책을 이용하여 쉽게 관리해야되는 경우
  • IAM 환경에서 액세스 제어 정책을 유지하는 것을 선호하는 경우

S3의 계층 구조

  • AWS 콘솔에서는 S3의 디렉터리(폴더)를 생성 가능하고 확인 가능
  • S3 내부적으로는 계층 구조가 존재하지 않음.
    • 키 이름에 포함된 "/" 로 계층 구조를 표현
    • 예:
      • s3://mybucket/world/southkorea/seoul/guro/map.json
      • 버킷명: mybucket
      • 키: world/southkorea/seoul/guro/map.json (단일 스트링)

S3 버킷 관리 방법의 선택

  • Identity-based policies
    • 같은 계정의 IAM 엔티티의 S3 권한 관리할 때
    • S3 이외에 다른 AWS 서비스와 같이 권한 관리할 때
  • Resource-based policies
    • 익명 사용자 또는 다른 계정의 엔티티의 S3 이용 권한을 관리할 때
    • S3 만의 권한을 관리할 때

S3 Access Control List

  • ACL
    • 버킷 또는 객체 단위로 읽기, 쓰기 의 권한을 부여
    • S3에서 설정을 통해 ACL를 활성화 시킨 후에 적용 가능
    • 파일 업로드 시 설정 가능
    • 간단하고 단순한 권한 관리만 가능
    • 점점 사용하지 않는 추세
      • 대부분의 경우 IAM/버킷 정책으로 대체 가능
      • Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없으며, 각 객체에 대해 액세스를 개별적으로 제어하는 비정상적인 상황을 제외하고는 ACL을 사용 중지하는 것이 좋다 라고 공식 문서에 언급됨.

미리 서명된 URL

  • pre-signed URL
  • 필요한 객체에 대한 임시 액세스 권한을 부여하는 것 (최대 7일 동안 유효)
  • 객체 소유자가 AWS 자격 증명이 없는 다른 사용자와 객체를 공유해야되는 경우 미리 서명된 URL을 이용하여 시간 제한 권한을 부여할 수 있다.

pre-signed URL을 생성하는데 사용할 수 있는 자격 증명

  • IAM 인스턴스 프로필: 최대 6시간 유효
  • AWS STS: AWS 계정 루트사용자 또는 IAM 사용자의 자격 증명과 같은 영구 자격 증명으로 서명된 경우 최대 36시간 유효
  • IAM 사용자: AWS Signature 버전 4를 사용한 경우 최대 7일 유효

토큰 만료

임시 토큰을 사용하여 미리 서명된 URL을 만들면 이 토큰 만료보다 이후의 만료 시간으로 URL을 만든 경우에도 토큰이 만료되면 이 URL도 만료됩니다.

Amazon S3 객체 소유권

  • 버킷 소유자는 기본 소유권 설정을 시행하여 객체를 작성한 계정에 관계없이 버킷의 모든 객체를 버킷 소유자가 소유
    • Amazon S3 객체 소유권 기능 이전에는 하나의 AWS 계정이 다른 AWS 계정이 소유한 S3 버킷에 객체를 작성한 경우 해당 객체는 버킷 소유자가 아닌 객체를 작성한 계정의 소유했다.

Amazon S3 객체 소유권에는 두 가지 모드

  • 버킷 소유자 선호
    • 버킷 소유자가 모든 새 객체와 관련 ACL을 소유하게 됩니다. - 이 설정 및 미리 준비된 ACL이 없으면 객체가 버킷에 업로드되지만 업로드 계정의 소유로 유지
  • 객체 작성자
    • 객체를 작성하는 계정이 이를 소유

Amazon S3 데이터 일관성 모델

  • 모든 AWS 리전의 Amazon S3 버킷에 있는 객체의 PUT 및 DELETE 요청에 대해 강력한 쓰기 후 읽기(read-after-write) 일관성을 제공

Amazon S3 스토리지에 대한 퍼블릭 액세스 차단

  • Amazon S3 스토리지에 대한 퍼블릭 액세스 차단
  • S3 는 액세스 포인트, 버킷 및 계정에 대한 설정을 제공하여 Amazon S3 리소스에 대한 퍼블릭 액세스를 관리
  • 기본적으로 새 버킷, 액세스 포인트 및 객체는 퍼블릭 액세스를 허용 ❌
  • S3 퍼블릭 액세스 차단 설정 은 이러한 정책(버킷 정책, 액세스 제어 목록(ACL), 액세스 포인트 정책) 및 권한을 무시하므로 이러한 리소스에 대한 퍼블릭 액세스를 제한할 수 있습니다.
    • 버킷 정책, 액세스 제어 목록(ACL), 액세스 포인트 정책과 같은 메커니즘을 사용하여 액세스 정책을 정의하는데 이런 것 보다 더 우선 순위가 높다.
  • 버킷이나 객체에 대한 액세스 요청을 받으면 버킷이나 버킷 소유자 계정에 적용된 퍼블릭 액세스 차단 설정이 있는지 판단
  • 액세스 포인트를 통해 요청이 이루어진 경우 Amazon S3는 액세스 포인트에 대한 퍼블릭 액세스 차단 설정도 확인합니다. 요청된 액세스를 금지하는 퍼블릭 액세스 차단 설정이 있는 경우 Amazon S3가 요청을 거부

Amazon S3 퍼블릭 액세스 차단은 네 가지 설정을 제공합니다. 각각의 설정은 독립적이며 어떤 조합으로든 사용할 수 있습니다. 각 설정은 액세스 포인트, 버킷 또는 전체 AWS 계정에 적용할 수 있습니다. 액세스 포인트, 버킷 또는 계정에 대한 퍼블릭 액세스 차단 설정이 다른 경우 Amazon S3에서는 액세스 포인트, 버킷 및 계정 설정의 가장 제한적인 조합을 적용합니다.

따라서 Amazon S3가 퍼블릭 액세스 차단 설정에 의해 작업이 금지되는지 평가하는 경우, 액세스 포인트, 버킷 또는 계정 설정을 위반하는 요청을 거부합니다.

데이터 암호화

  • ❗참고: 서버 측 암호화는 객체 메타데이터가 아닌 객체 데이터만 암호화합니다.
  • SSE-SE(; Amazon S3 관리형 암호화 키)
    • 2023년 1월 5일부터 Amazon S3로의 모든 새 객체 업로드는 추가 비용 없이 성능에 영향을 미치지 않고 자동으로 암호화
    • Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 Amazon S3 내 모든 버킷 암호화의 기본 수준으로 적용
    • Amazon S3 관리형 키만 사용하여 데이터 업로드를 암호화하도록 요구하는 경우 다음 버킷 정책을 사용
      • 요청에 서버 측 암호화를 요청하는 x-amz-server-side-encryption 헤더가 포함되지 않을 경우 객체 업로드 권한을 거부하는 버킷 정책 예시
      {
  "Version": "2012-10-17",
  "Id": "PutObjectPolicy",
  "Statement": [
    {
      "Sid": "DenyIncorrectEncryptionHeader",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  ]
}

스토리지 클래스

종류특징
Standard클라우드 애플리케이션, 동적 웹사이트, 콘텐츠 배포, 모바일 및 게임 애플리케이션, 빅 데이터 분석을 위한 범용 스토리지로 간주
3AZ 이상, 제일 비쌈, 꺼내기 무료, 즉시 액세스
Intelligent-Tiering데이터 액세스 패턴을 알수 없거나 바뀌는 경우에 유용
3AZ 이상, 데이터 액세스 빈도에 따라 최적화된 스토리지 요금, 데이터 저장 티어별 다름(액세스 시간/요금)
두티어(Frequent Acceess, Infrequent Access)에 저장
Standard-IA액세스 빈도는 낮지만 필요할때 빠른 액세스가 필요한 데이터에 적합
백업, 재해 대책 파일 등, 3AZ 이상, 표준보다는 저렴, 즉시 액세스
OneZone-IA액세스 빈도가 적고 필요에 따라 즉시 검색이 필요한 중요도가 낮은 데이터
단일 AZ에 데이터를 저장하며 비용이 Standard-IA 타입 보다는 20% 적게 듭니다.
로그, 재작성 가능한 데이터 - 가용성 및 복원력이 필요없는 고객에 적합
Glacier Instant Retrieval액세스는 거의 없지만 즉시 검색이 필요한 장기 보존 데이터
3AZ 이상, 의료 이미지, 미디어 자산 등, 즉시 액세스 가능, OneZone 보다는 낮은 스토리지 금액/높은 액세스 금액
Glacier Flexible Retrieval액세스가 거의 없고, 필요에 따라서 꺼내 방법을 유연하게 선택할 수 있는 장기간 보존 데이터
곧바로 액세스 할 필요가 없는 경우, 대량 데이터의 무료 꺼내도 가능
백업, 재해 대책, 오프사이트 데이터 스토리지 등, 3AZ 이상,
Glacier Instant Retrieval보다 낮은 스토리지 요금
액세스신속(고액/1~5m), 표준(저액/3~5h), 대용량(무료/5~12h)
Glacier Deep Archvie액세스가 거의 없고 꺼내는 데 시간이 오래 걸리는 장기 저장 데이터
7~10년 이상 보관할 필요 있는 데이터, 백업이나 재해의 대책
3AZ 이상, 자기 테이프의 데이터, 가장 낮은 스토리지 금액
액세스표준(고액/12시간 이내), 대용량(저액/48시간 이내)

S3 대시보드

  • 서비스탭 - 스토리지 - S3 또는 S3 검색

S3 버킷 만들기

  • 버킷 만들기 클릭

일반 구성

객체 소유권

  • 버킷을 위한 접근 제어 리스트
  • ACL 비활성(외부 노출을 원천봉쇄)

이 버킷의 퍼블릭 액세스 차단 설정

  • 객체 소유권 ACL 비활성화 시 설정이 의미 없음. 이는 잘못된 표현 ➡️ 객체 소유자가 권한 (ACL을 통해)을 부여하여 객체를 공개하더라도 해당 객체가 있는 버킷에 공개 액세스 차단 설정이 활성화된 경우 객체는 공개적으로 액세스할 수 없습니다.
    • 퍼블릭 액세스 차단 설정이 우선시된다.
  • 버킷의 ACL 설정

버킷의 버전 관리

  • 버킷에 저장된 모든 객체의 각 버전을 보존, 검색 및 복원
  • 사본에 대한 비용 추가 ⭕

암호화

버킷 생성 결과

S3 CLI

AWS CLI 설치

CLI 를 위한 자격증명 설정

사용자 생성

  • IAM 접속
  • IAM 대시보드 - 사용자 - 사용자 추가
  • CLI 만 이용하기 때문에 웹 콘솔 권한을 주지 않음.
  • S3 관련 권한 직접 부여
  • 검토 및 생성 - 사용자 생성 클릭
  • 사용자 생성 결과

보안 자격 증명 생성

  • 사용자 세부 정보 - 보안 자격 증명 탭
  • 액세스 키 만들기 클릭
  • Command Line Interface 체크 후 다음
  • 액세스 키 만들기 클릭
  • 액세스 키 다운로드(.csv 파일 다운로드)

명령 프롬프트에 자격 증명 설정

  • aws configure 명령으로 자격 증명 설정
  • 자격증명 후 명령테스트

S3 CLI 명령

버킷 리스트 확인 (s3 ls)

  • aws s3 ls
    1번 aws, 2번 리소스, 3번 ls(list)

파일 업로드 (s3 cp)

  • 버킷 최상위 폴더 업로드
    aws s3 cp <FILE_PATH> s3://<S3_BUCKET_NAME>/
  • 버킷 내부의 원하는 경로에 업로드
    aws s3 cp <FILE_PATH> s3://<S3_BUCKET_NAME>/<원하는 디렉터리 PATH>
  • 버킷의 존재하는 파일 다운로드
    aws s3 cp s3://<S3_BUCKET_NAME>/<FILE_PATH> <DOWNLOAD_PATH>
    • Ex. aws s3 cp s3://jsb-seoul/index.html ./

버킷안 파일 확인 (s3 ls)

  • aws s3 ls s3://<S3_BUCKET_NAME>/

주기적으로 백업 (s3 sync)

  • aws s3 sync <백업폴더_PATH> s3://<S3_BUCKET_NAME>/<백업폴더_PATH 를 그대로>/
    • 백업할 폴더를 그대로 적어줘야한다.
    • cp 명령과 다르게 전혀 다른 PATH는 생성하지 ❌

버킷 객체 삭제(s3 rm)

  • 하나만 지우기
    aws s3 rm s3://<S3_BUCKET_NAME>/<FILE_PATH>
    • aws s3 rm s3://jsb-seoul/backup/food.tar
  • 디렉터리째로 지우기 (--recursive 옵션(하위 모든것))
    aws s3 rm s3://<S3_BUCKET_NAME>/<DIRECTORY_PATH> --recursive
    • aws s3 rm s3://jsb-seoul/backup/ --recursive

버킷 지우기(s3 rb); remove bucket

... ADD

명령 결과 이미지


IAM Role 통한 자격증명

  • IAM - 역할 - 역할 생성 클릭
  • 어디에 사용할 Role 인지 분류 (EC2로 분류)
  • S3FullAccess 권한 선택
  • 이름 지정, 검토 및 생성 - 역할 생성 클릭

  • 역할 생성 결과

EC2에 역할 부여

  • EC2 선택 - 작업 - 보안 - IAM 역할 수정

  • 역할 부여 확인

role을 부여받은 EC2으로 버킷에서 파일 다운로드

  • ec2에서 명령 수행
$ aws s3 ls s3://jsb-seoul
$ aws s3 cp s3://jsb-seoul/index.html ./

Amazon S3 Lifecyle(수명 주기)

Amazon S3 버킷에 업로드된 객체들의 효율적인 관리를 위해 수명 주기를 설정할 수 있습니다.

  • 수명 주기를 사용하는 경우
    • 버킷에 주기적으로 로그를 업로드할 경우 애플리케이션에서는 이것을 한 주나 한 달 동안 필요로 할 수 있습니다. 그 이후에는 사용자가 이것을 삭제하고 싶을 것 입니다.
    • 일부 문서는 제한된 기간 동안 자주 액세스 됩니다. 그 이후에는 문서가 가끔 액세스 됩니다. 어느 시점이 되면 이러한 문서에 실시간으로 액세스할 필요가 없지만, 조직 또는 규정에서 특정 기간 동안 해당 문서를 보관할 것을 요구할 수도 있습니다. 그 이후에는 사용자가 문서를 삭제할 수 있습니다.
    • 어떤 유형의 데이터는 주로 보관 목적으로 Amazon S3에 업로드 할 수도 있습니다. 예를 들어, 디지털 미디어, 금융 및 의료 기록, 가공되지 않은 유전체 염기서열 데이터, 장기 데이터베이스 백업 파일, 그리고 규제 준수를 위해 보존해야 하는 데이터 등을 보관할 것입니다.

사용자들은 수명 주기를 통해 특정 버킷이나 버킷 내의 객체가 속한 prefix 혹은 tag 로 구분하여 조금 더 저렴한 스토리지 클래스로 변경을 하거나, 객체를 만료 시켜 삭제할 수 있습니다.

수명 주기 정책은 비동기 방식(Asynchronous)에 의해 동작한다는 점 입니다. 즉, 정책에 의해 오브젝트가 다른 스토리지 클래스로 변경되거나 삭제될 때에 그 즉시 이뤄지지는 않습니다. 클라우드 환경은 내가 사용한 만큼만 지불하는 것이 장점인데, 저렴한 스토리지 클래스로 혹은 객체가 바로 삭제되지 않는 시간에 비용은 어떻게 되는지 궁금하실 것 입니다.
답은 사용자가 정의한 수명 정책이 활성화 되고, 오브젝트가 조건에 충족하는 시점에서 비용은 변경됩니다.

실습

  • S3 Standard Class 를 30일 이후 조금 더 저렴한 Standard-IA Class 로 변경하고, 60일 이후에는 더 저렴한 One Zone-IA로 변경, 90일 이후에 데이터를 삭제하는 방법에 대해 실습
  • 수명 주기를 설정하는 방법
    • "S3" → "생성한 버킷 클릭" → "관리" → "수명 주기 규칙" → "수명 주기 규칙 생성"
  • 수명 주기를 설정할 수 있는 창이 출력됩니다.
    • 규칙 이름을 입력합니다 : 수명 주기 규칙의 이름을 정의합니다.
    • 규칙 범위 선택 : 수명 주기 규칙이 적용되는 범위를 제한 합니다. 제한 방법에는 prefix(접두사) 와 Tag Key, Value 형태로 제한 할 수 있으며, 만약 아무것도 입력하지 않았을 경우 모든 객체들이 적용을 받습니다.

      Amazon S3의 Class 를 변경할 수 있게 정의

      전환 및 만료 작업 검토 를 확인하고, “규칙생성” 을 클릭하여 수명 주기 규칙 생성을 마무리합니다.

      결과

S3 & Couldfront - Static Website

CloudFront

  • .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스
  • 엣지 로케이션(; Edge Location)이라고 하는 (AWS)데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공
    • 리전이 없다고 해도 엣지로케이션은 존재할 수 있다.
  • 콘텐츠를 사용자가 요청하면 지연시간(Latency)이 가장 낮은 엣지 로케이션으로 라우팅되므로 콘텐츠 전송 성능 ⬆
  • cloudfront 검색 또는 서비스 탭 - 네트워킹 및 콘텐츠 전송 - CloudFront

  • 캐시: 클라우드 엣지 로케이션의 저장하는 일

S3 리소스 생성

  • ACL 활성화

  • 모든 퍼블릭 액세스 차단 해제

  • 버킷 만들기

  • 생성 결과

  • 상파울루 Region 에 버킷 추가 - 생성 방식은 같음.

    • 물리적 거리에 대비하여 자원을 가져오는 시간 비교 ( 지연시간)하여 Content Delivery Network 역할을 수행하는 Cloudfront의 필요성을 확인

정적 웹사이트 구축

  • 💦 seoul 과 상파울로 각각 설정
  • index.html 업로드
  • images 폴더 생성 및 이미지 업로드
  • 업로드시 권한 부분에서 ACL 퍼블릭 읽기 액세스 설정

정적 웹사이트 호스팅 편집

  • s3 버킷 세부 정보 - 버킷 속성


  • route 53 에 레코드 설정

정적 웹사이트 리소스 로딩 속도 확인

  • 평소에는 거의 1초 정도로 차이가 난다.

인증서 설정

  • ❗ 개인정보 수집하는 사이트는 무조건 HTTPS 인증서 필요 ❗ - 아니면 KISA에서 과태료

  • Certificate Manager: 인증서 설정/관리/배포

  • ACM 인증서는 무료

  • ❗ CloudFront 이용시 AWS Certificate Manager의 인증서를 연결합니다. 인증서는 반드시 미국 동부(버지니아 북부) 리전(us-east-1)에 있어야 합니다. ❗

  • Certificate Manager 검색

  • 인증서 요청 클릭 -Region 확인 ❗

  • 퍼블릭 인증서 요청 선택 다음 클릭

  • 퍼블릭 인증서 요청 설정 후 요청 클릭

  • 생성 결과

  • 인증서 세부정보 - Route53에서 레코드 생성 클릭

  • 레코드 생성 클릭

  • 생성 결과

    • Route 53에서 레코드 확인
    • 인증서 발급 결과 확인

CloudFront 생성

  • CloudFront 배포 생성 클릭

배포 생성

  • 원본
    • Origin Shield 활성화: Origin의 가용성 여부

  • 기본 캐시 동작
  • 캐시 키 및 원본 요청
  • 함수 연결
  • 설정 후 배포 생성 클릭
    • 대체 도메인 입력
    • SSL 인증서 추가 및 루트 경로 명시
    • 배포 생성 클릭

배포 결과 확인

  • 배포 중
  • 배포 완료 - 미국 동부 시간으로 표기됨.

Route 53에 레코드 등록

  • 레코드 등록
  • https 로 접속 확인

콘텐츠 업데이트 : 캐시 된 콘텐츠 고려 사항

객체 업데이트

  • 파일 버전 관리
    • Amazon CloudFront에서 객체를 업데이트하는 가장 간단한 방법은 파일 버전 관리를 사용하는 것
    • S3에서 버전 관리를 활성화 한 후 [변경 사항 저장]

객체 교체 또는 삭제

  • 파일 버전 관리가 적절한 솔루션이 아닙니다. 이러한 경우 Amazon S3에서 파일을 제거하거나 교체해도 문제가 즉시 해결되지는 않습니다.

    1. Amazon S3 및 Amazon CloudFront 에서 웹사이트를 각각 오픈합니다.
      [CloudFront URL]

      [S3 URL]

    2. S3 콘솔에서 cf_lab1.html 을 포함하는 Amazon S3 버킷을 클릭합니다.

    3. cf_lab1.html 을 선택하고 제거합니다.

    4. 브라우저에서 Amazon S3 및 Amazon CloudFront 호스팅 웹 사이트를 새로고침 합니다.
      Amazon CloudFront 에서는 이전 사이트가 계속 보여야 하며 Amazon S3 URL 에서는 XML 오류가 표시 되어야 합니다.

      이 동작은 Amazon CloudFront의 중복 및 캐싱 동작으로 인해 발생합니다.
      cf_lab1.html 은 원래 Grand Canyon 콘텐츠가 있는 Amazon CloudFront 에 캐시 되었습니다.
      캐시 시간이 만료 될 때까지 (기본적으로 24 시간) 파일의 버전을 계속 제공합니다.

무효화

cf_lab1.html 의 이미지를 다시 grand_canyon.jpg 을 업로드해 버전을 업데이트 합니다.

버킷의 버전이 업데이트 되었습니다.

이후 클라우드 프론트 도메인으로 접속합니다. 사진이 변경되지 않았음을 알 수 있으며 이 경우 클라우드 프론트 배포에서 무효화를 통해 데이터를 최신화 시켜주어야 합니다.

클라우드 프론트 배포에서 [무효화 생성] 을 클릭합니다.

무효화 할 파일 이름을 입력합니다. (cf_lab1.html)

[무효화 생성]을 클릭 합니다.

무효화 상태가 진행 중에서 완료 됨으로 변경 될 때까지 기다립니다. 몇 분 소요됩니다.

무효화가 완료되면 Amazon CloudFront 버전 cf_lab1.html 을 새로고침 합니다.

리소스 제거

S3 버킷

  • 버전 관리하는 객체까지 지우려면 비어있음 기능을 이용
  • 버킷 삭제

IAM

  • 사용자 제거
  • Role 제거

CloudFront

  • CloudFront 배포 비활성화

  • CloudFront 배포 삭제

profile
jsbak
끄적끄적 쓰는곳
이전 포스트

AWS - EFS

다음 포스트

AWS - 보안

0개의 댓글