S3(Simple Storage Service), CloudFront, Elastic Beanstalk

S3(Simple Storage Service)

S3 소개

Amazon Simple Storage Service(Amazon S3)는 인터넷 스토리지 서비스로 구글 드라이브, One 드라이브와 가장 근접한 형태라고 이해하면 된다.

개발자나, IT 운영자가 웹 규모의 컴퓨팅 작업을 수행하는데 필요한 저장 공간을 제공하며 정적 웹 사이트 호스팅,온라인 백업, 데이터 아카이브, 기업 애플리케이션, Big Data 분석 등 다양한 용도로 사용되며 고가용성, 확장성, 보안성 모두 가지고 있다

 

사용 예시

• 웹 사이트 호스팅
• 멀티미디어 파일 저장 및 스트리밍
• 애플리케이션 데이터 저장
• 백업 및 복원
• 아카이브

Buckets

데이터를 저장하는 가장 상위 레벨의 폴더 형태 컨테이너로 EC2에 인스턴스라는 개념이 있다면 S3에는 버킷이 있다고 이해하면 편하다

SE에 저장되는 파일들을 객체라고 부르며 모든 객체는 키(디렉토리)로 식별 된다

prefix/delimiter/object-name
s3://my-bucket/my_folder/my_file.txt

 

S3에서 버킷은 아래와 같은 목적으로 사용된다

• 데이터를 저장하는 컨테이너 역할
• 객체에 대한 공용 및 개인적인 접근 권한을 설정하기 위한 위치
• 객체에 대해 특별한 이벤트 알림을 설정하기 위한 위치
• AWS 계정에서 버킷 및 객체 사용에 대한 비용 추적 및 모니터링을 위한 위치

버킷 네이밍 컨벤션은 아래와 같다

• 대문자, 언더스코어 금지
• 버킷 이름은 3자(최소)에서 63(최대)사이여야 하며 소문자, 숫자, 점(.), 하이픈(-)으로만 구성될 수 있다
• 문자 또는 숫자로 시작하고 끝나야 하며 두 마침표(..)를 나란히 붙여서 사용하면 안된다.
• 버킷 이름에 IP 주소 형식(192.168.0.2)을 사용하지 않는다.

S3 사용해보기

AWS 콘솔에서 S3를 검색 후 버킷 만들기를 눌러서 버킷 만들기 창으로 진입한다.

 

 

먼저 버킷 이름을 지정해주어야 하는데, 버킷 이름을 글로벌 네임스페이스에서 고유해야 하기 때문에 식별 할 수 있는 이름으로 지정해주는 것이 좋다.

일반적으로 많이사용하는 단어로 버킷 이름을 작성 후 생성하려고 하면 위의 이미지 처럼 생성이 되지 않는 것을 확인할 수 있다.

버킷 이름을 작성할 때 적용해야할 룰이 적혀있으므로 참고해서 지어주면 된다.

 

 

이후 객체의 소유권 설정, 버킷의 퍼블릿 액세스 차단 설정, 버킷 버전 관리 등을 설정할 수 있는데 지금은 예제이므로 이름만 지정해주고 버킷을 만들어 주면 생성된 버킷을 확인할 수 있다

 

 

해당 버킷을 클릭하면 업로드를 할 수 있는데 딱히 어려운 인터페이스는 아니라서 원하는 파일을 업로드 해주면 업로드한 파일이 버킷에 들어가 있는 것을 확인할 수 있다

 

 

업로드 된 이미지를 클릭해 보면 상세 정보가 나오고 객체 URL이라는 주소를 복사해서 브라우저에 복사해보면 AccessDenied라고 떠서 접근이 불가능하다

 

하지만 버킷에 업로드된 파일을 선택하고 열기버튼을 클릭하면 업로드한 이미지가 보이는데, URL 주소를 보면 차이가 존재한다.

 

https://nagul2-bucket.s3.ap-northeast-2.amazonaws.com/IMG_0254.JPG?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Credential=ASIAY7WSA2KXEVJQKAYH%2F20250508%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Date=20250508T032219Z&X-Amz-Expires=300&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMP%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDmFwLW5vcnRoZWFzdC0yIkcwRQIhAOiM0hnzUiZfABTOUXjdL3r2B%2BN64yQcYCixo7G7YFP5AiA4xRw3ncKAll4uxRNWFxy%2FK671olMS8AaI8hEy0zMZVSraAghsEAAaDDYxNzg0MjAwNDY1NCIM5P%2F1cgPy1eKIPT0WKrcC72Aao52OXh16XCJzjZlsrhkSGqSBbLiG93Rt3x0P5TW584kbgH87ZROcESgM%2BMxP6CN9flf9NRoeGa8igJNlENUuUsj20pQ8yNNRUya4MW7RyeuHh2igr7OOREyCvl5%2B9I8dNDmW2c%2BW3vlIP%2FdQFUBlFLNGOiZD0JhWyAExJlTr1JbvUecsZu8aMPw0icejhK6OBXrI%2FGViP5Ue7JcYaKXnvcqn34sXdCbXUkcA8LezFVH4XDZ38MTaHQmBLLqruzwva6Sdmp7lIESXO1z5S6gWppBPiqiRQlVWU7zTz3hIgL5W%2Fuye6USZjSN5P1ZHQRQlgm75klng9XAQiInCngIx3AJ5bCuvAa9xC3zZmUiIXwLEVJshPXUaQc2dpETpHvBend2FvHMFzKncnSW41aGmRydGiiEw7L3wwAY6rQKYRx5wUqW3PJpU5rYmBSE1Z32EDwVgw2A25qJu7u3OvlpjpahmmYKu95tjNZVH%2FlFP7jOJbKzP3WARLG9l9Nd0hKbReDi2%2FJ4RLK3YMFssnVxVAuTDYK0fLt6xtRWcMmEw8Emm7LOjjzp5dyuJoMF%2BeF3DWVQcJ6eYbopLyFqT1asUZIc5zdnXn4RVe9m3zqq7e63f8Ih8iDuXOVal4NrxTxmYk8uWpNmlAqvSk0CEklwWQDp8EgjPH8S%2BFSUkoGU0Zrj7V6hZhiWbVOlUw4TEO1L%2B7uFa%2Fk871njmnfYzQVhxfWCETzhlMbz%2FcApVaqzE8GUUebe%2FCwRCuOg%2FJP4NLAwFQcSINxLjoOPmICKfb3ofc79Fv%2BVxKZUK9nC3FbPGHk3eM0wLBEjv9UHR&X-Amz-Signature=28582737c2749ac2edc8851a6af06426c78f25593f9ffefcf812841bf8e91197&X-Amz-SignedHeaders=host&response-content-disposition=inline

 

열기버튼을 눌렀을 때의 URL 전문을 보면 객체 URL과는 다르게 뒤에 추가적으로 다양한 쿼리 파라미터가 붙게 되는데, 이것이 권한이 없을 때 임시로 접근할 수 있게 해줄 수 있도록 S3에서 만들어주는 Pre-Signed URL이다

 

 

추가로 폴더를 만들어 줄 때는 이름에 /를 포함할 수 없으므로 이부분만 주의하면 되며, 폴더를 만들게 되면 우리가 일반적으로 폴더를 사용하듯이 폴더 안에 다양한 파일을 집어 넣을 수 있다.

 

폴더 안에 업로드된 파일은 당연하게 경로에 폴더 이름이 포함 된다.

 

Bucket Policy(버킷 폴리시)

IAM과 유사한 JSON 형식의 문서로 버킷의 모든 객체와 그룹에 대한 접근을 제어할 수 있다.

예를 들면 액세스를 허용하는 IP 주소와 범위를 지정할 수 있고 액세스 할 수 있는 범위도 제한할 수 있으며 암호화된 연결을 사용하도록 강제할 수도 있다.

 

폴리시 예시

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowUserToGetBucket",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT-ID:user/USERNAME"
            },
            "Action": "s3:GetBucketLocation",
            "Resource": "arn:aws:s3:::BUCKET-NAME"
        }
    ]
}

• IAM 사용자 USERNAME이 GetBucketLocation 작업을 수생할 수 있도록 지정된 버킷 BECKET-NAME에 대한 액세스를 허용하는 정책의 예시이다
  • Resource: 버킷 혹은 오브젝트
  • Effect: Allow 혹은 Deny
  • Principal: 대상 유저

ARN

arn:partition:service:region:account-id:resource-id
arn:partition:service:region:account-id:resource-type/resource-id
arn:partition:service:region:account-id:resource-type:resource-id

//예시
arn:aws:iam::123456789012:user/johndoe
arn:aws:s3:::my_corporate_bucket/
arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0e9801d129EXAMPLE

• AWS에서 사용하는 고유한 식별자로 AWS의 모든 리소스에 대한 고유 식별자 역할을 한다.
• ANR의 형식은 아래와 같다
  • arn: AWS 리소스 이름을 가리키는 고정 문자열
  • aws: 리소스가 AWS에서 호스팅되는 것을 나타내는 고정 문자열
  • service: AWS 서비스 이름을 나타내는 문자열 (s3, lambda, ec2 등)
  • region: AWS 리전 이름을 나타내는 문자열 (us-east-1, ap-northeast-2 등)
  • account-id: AWS 계정 ID를 나타내는 숫자
  • resource-id: 해당 리소스의 고유 식별자(S3 버킷 이름, Lambda 함수 이름 등)

ACL

• Access Control List: 접근 권한을 가지는 경우들을 명시한다

Bucket Policy 설정

생성한 버킷을 클릭하면 권한 탭에 들어갈 수 있는데, 아래에 버킷 정책이라는 곳에 JSON 형태로 객체에 대한 액세스 권한을 지정할 수 있다

초기 설정으로 버킷에 대한 퍼블릭 엑세스 차단 설정이 활성화되어 있으면 버킷 정책을 작성할 수 없는 구조로 되어있으므로 버킷 폴리시를 작성하기 위해서는 퍼블릭 엑세스 차단을 비활성화 해주어야 한다.

 

 

비활성화를 해주고 버킷 정책 입력을 위해 편집 버튼을 누르면 위와같은 화면이 나오는데, 해당 버킷의 ARN이 나타나는 것을 확인할 수 있다.

직접 JSON을 입력해주어도 되지만 정책 생성기 버튼을 눌러서 간편하고 사용자 친화적으로 정책을 입력할 수 있다.

 

정책을 적용할 대상을 지정하고 원하는 상태를 입력해주면 되는데, 예제에서는 내가만든 버킷에 모든 대상에게 읽기 권한을 허용하는 S3 Bucket Polity를 생성하도록 했다.

 

 

이후 Add Statement로 상태를 추가하고 그 하단에 Generate Policy 버튼을 누르면 정책이 JSON 형태로 생성이 되는데 이 JSON을 복사해서 버킷 정책 편집창에 붙여 넣어주고 변경사항을 저장하면 버킷 정책을 지정할 수 있게 된다

 

다만 여기에서 정책 생성기로 만들어준 정책 항목 중 Resource의 값 마지막에 /*을 직접 추가해주어야 되는데, s3:GetObject의 권한은 버킷이 아니라 버킷 안의 객체 파일에 대한 작업이기 때문이다.

 

정책 생성기는 버킷 까지만 지정해주고 이러한 부분까지는 정책 생성기가 판단하지 못하기 때문에 정책 생성기로 생성을 해도 어떤 이런 부분은 사용자가 직접 챙겨주어야 한다는 점을 주의해야 한다.

 

이렇게 정책이 생성되었으므로 이제 업로드한 객체 URL로 직업 브라우저에 검색을 해봐도 이미지가 정상적으로 나타나는 것을 확인할 수 있다

 

S3를 이용해 정적 웹사이트 배포하기

웹사이트를 호스팅하기 위해 간단한 아래의 간단한 HTML을 생성을 해서 S3에 추가한다.

<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>프론트엔드</title>
  </head>
  <body>
    <h1>S3에 배포한 내 정적 사이트</h1>
    <p>
      Lorem ipsum dolor sit amet consectetur adipisicing elit. Earum culpa
      temporibus saepe sunt porro fugiat minima, voluptatem similique esse odit
      officiis possimus aut, enim necessitatibus. Et facere temporibus excepturi
      quis.
    </p>
  </body>
</html>

 

 

이후 아무 이름으로 버킷을 새로 만들어 줄 때 버킷의 퍼블릭 액세스 차단 설정을 비활성화 해서 생성하고 해당 버킷에 만들어 둔 index.html 파일을 업로드 시킨다.

 

 

 

이렇게 업로드가 완료되면 새로 만든 버킷의 최상단(Root)에 index.html 파일이 업로드 되어있는 것을 확인할 수 있다

 

 

그 다음 생성한 버킷을 선택하고 속성 탭을 클릭한 다음 아래로 스크롤을 내리면 정적 웹 사이트 호스팅이라는 옵션이 있다

 

 

편집 버튼을 누른다음 해당 옵션을 활성화 해주면 호스팅 유형과 인덱스 문서, 오류 문서, 리디렉션 규칙 등을 작성할 수 있는 창이 뜨게된다

인덱스 문서는 기본 페이지를 지정하고, 오류 문서는 오류가 발생했을 때 나타나는 페이지를 등록해주면 된다.

 

만약 S3 버킷에 업로드한 index.html 파일의 이름이 index.html이 아니거나 루트 경로에 있지 않다면 정상적으로 적용이 되지 않거나 추가적인 경로 설정을 입력해주어야 할 수 있으니 가능하면 root 경로에 index.html 파일로 해주는 것을 권장한다

 

 

 

이렇게 변경사항을 저장하면 하단에 주소가 하나 뜨는데, 여기를 접속하면 아직 접근 권한이 적용되지 않아 403 Forbidden 에러 페이지가 나타난다.

 

 

새로 생성한 버킷에 위에서 다뤄보았던 읽기 가능한 Bucket Policy를 추가해주면 접근 권한 문제가 해결이 된다.

정책 생성기로 정책을 생성해도 되지만 해당 정책은 너무 많이 사용하기 때문에 s3 static webhosting policy로 검색하면 정책 틀이 나오기 때문에 이를 복사하고 나의 bucket 이름을 수정해서 적용해도 된다.

 

 

이렇게 정책을 적용해주고 403 Forbbiden이 떴던 페이지를 새로고침 해주면 정상적으로 정적 웹 사이트 호스팅이 동작하여 html 파일이 브라우저에 출력되게 된다.

도메인 네임을 적용하기

배포된 정적 웹 사이트에 도메인을 적용하려고 할 때 주의점이 있는데, 반드시 버킷 이름과 도메인 또는 하위 도메인과 이름이 같아야 한다

도메인이 acme.example.com 이라면 버킷이름도 동일해야 한다

 

 

지금 생성해준 버킷은 이름이 다르기 때문에 새로 S3 버킷을 생성하고 index.html을 업로드하고 정적 웹사이트 호스팅과 버킷 정책을 동일하게 설정을 진행해준 다음 Route 53 레코드를 생성해주면 된다.

 

 

레코드 유형을 A로 하여 별칭으로 레코드를 생성해주면 되는데, 이때 레코드 이름이 오타가 나거나 잘못 입력하여 생성한 S3 버킷 이름과 다를 경우 제대로 S3 앤드포인트를 찾아오지 못하니 주의해야한다.

 

레코드가 추가되어 static.nagul2.store로 브라우저에 검색을 해보면 정상적으로 페이지가 출력되는 것을 알 수 있다

 

기존에 Route 53을 로드 밸런서에 적용했을 때에는 보안 그룹을 통해 HTTPS 통신이 되도록 설정할 수 있었는데 지금처럼 S3 웹사이트 엔드포인트에 Route 53이 적용되는 경우에 HTTPS를 적용해주려면 Cloudfront를 적용해 주어야 한다.

---

CloudFront

소개

 

AWS가 제공하는 CDN(Content Delivery Network) 서비스이다

예를 들어 S3가 한국에서 배포를 하고 있다고 가정했을 때 물리적으로 거리가 먼 해외에서 데이터가 매우 먼 거리로 이동해야하기 때문에 시간과 리소스가 많이 소모 된다.

 

이를 해결하기 위해서 각 지점(Edge Locations)에 한국에서 가지고 있는 S3 데이터를 캐싱을 해두어 해당 지점 근처에 있는 곳에서 요청이 들어오면 본 서버에서 데이터를 가져오는 것이 아니라 지점의 캐싱된 데이터를 보내줘서 빠르게 데이터를 받아보도록 빠르게 컨텐트를 배달해준다고 하여 CDN 기술이라고 부른다

 

넷플릭스, 유튜브 처럼 최신 데이터를 수시로 업데이트 하지 않아도 되는 정적 컨텐츠를 전세계에 제공해야하는 서비스에 매우 적합하다.

 

장점

• 지리적으로 가까운 서버에 캐싱된 데이터를 가지고 오기 때문에 무척 빠르다
• CND 서비스를 해주는 업체에서 방화벽을 제공할 뿐만 아니라 DDoS 공격이 와도 서버가 분산되어있고 캐시가 되어있기 때문에 오리진 서버(원래의 서버)의 트래픽이 늘어나지 않는다.

단점

• 캐시를 사용하기 때문에 최신 동적 컨텐츠를 제공해야하는 경우에는 적합하지 않다
• 비용이 추가로 발생하게 된다

Cloudfront 사용해보기

Cloudfront를 사용하면 Route 53의 도메인과 S3 엔드포인트 중간에 Cloudfront가 중간에 있기 때문에 버킷 이름을 도메인과 맞추지 않아도 된다.

 

이를 확인해보기 위해 다시 새로운 버킷을 nagul2-test라는 이름으로 생성했는데 이 경우에는 퍼블릭 엑세스 차단 설정도 그대로 활성화 된 채로 생성해도 된다.

 

새로 생성한 nagul2-test에 버킷에 정적 웹 사이트 호스팅 설정이나 버킷 설정을 추가로 해주지 않고 index.html 파일을 업로드만 해주면 S3는 준비가 끝난다.

 

 

AWS 에서 CloudFront를 검색하여 CloudFront 배포 생성을 누르면생성을 위한 새로운 창이 뜨는데 Origin domain을 선택해보면 생성해둔 S3 버킷들이 검색되는 것을 확인할 수 있다.

 

로드 밸런서도 검색 대상이라서 로드 밸런서가 있다면 로드 밸런서를 선택할 수도 있다.

 

 

버킷을 선택하면 자동으로 이름이 입력이 되고 S3 액세스에 대한 제어를 설정해주어야 하는데 해당 버킷은 외부 공개 접근을 막아두었기 때문에 CloudFront만 접근이 가능하도록 원본 액세스 제어 설정을 체크해야 한다.

 

그러면 Origin access control이 표시가 되고 처음이라면 Create new OAC를 눌러서 정책을 생성해주면 되고 이미 정책을 생성했다면 해당 정책을 적용해주면 된다.

 

 

HTTPS를 적용해주기 위해 뷰어 프로토콜 정책을 Redirect HTTP to HTTPS를 선택해주고 대체 도메인 이름(CNAME)을 추가로 설정해주어야 한다.

Route 53에 레코드를 추가해줄 도메인 이름을 지정해주면 되며 이미 사용할 레코드가 있다면 해당 이름을 적어주면 된다.

 

 

SSL 적용을 위해 인증서를 받아야하는데, 서울에서 받은 인증서가 아닌 글로벌로 인증서를 받아야하므로 서울에서 받은 인증서가 있다고 하더라도 글로벌에 없다면 추가로 받아서 등록해주어야 한다.

 

 

루트 도메인으로 요청이 올 때 반환할 객체인 index.html을 추가로 설정해고 나머지 설정은 상황에 따라 검색해보고 추가적으로 적용해준 다음 CloudFront를 생성해주면 된다.

 

 

다음 Route 53에서 Alias를 활용하여 cdn.nagul2.store를 CloudFront의 배포에 붙여주는 레코드를 생성해주면 외부에서 cdn.nagul2.store로 접속하면 CloudFront에 접근하게 된다.

 

 

 

추가적으로 CloudFront 생성시 S3에서 접근할 수 있는 정책을 생성만하고 S3 버킷 정책에는 적용은 안해 두었으므로 연결대상인 S3 버킷으로 이동하여 정책을 추가해주어야 한다.

 

배포된 CloudFront를 눌러서 원본으로 이동하면 배포된 CloudFront를 선택해준 다음 편집을 누르면 아까 CloudFront를 생성했을 때와 동일한 양식이 뜬다.

 

밑으로 내려서 원본 액세스를 보면 정책을 복사할 수 있는데 버튼을 눌러서 정책을 복사해주고 S3 버킷 권한으로 이동 버튼을 누르면 자동으로 연결되어있는 버킷으로 연결시켜준다

 

 

여기서 버킷 정책에 편집을 눌러서 복사한 정책을 붙여 주고 저장해주면 되는데, 기존에 S3 정책을 적용했던 점과 다른것은 모든 퍼블릭 엑세스 차단이 활성화 되어있는 상태에서 버킷 정책을 적용해준다는 점이다.

 

 

이렇게 모든 설정이 완료된 후 Route 53에 추가한 레코드의 도메인인 cdn.nagul2.store로 브라우저에 검색을 해보면 CloduFront를 통해 S3 버킷에 있는 index.html이 정상적으로 출력이 되며 SSL이 적용이 되어 https로 전송되고 있는것을 확인할 수 있다.

 

CloudFront 캐싱(Invalidation)

과거에는 지금과 같은 상태에서 index.html의 내용을 수정하고 S3에 업로드한 상태에서 바로 cdn.nagul2.store로 접속한다면 캐싱된 데이터가 출력되어 업데이트된 내역이 보이질 않았다

 

하지만 현재 CloudFront 캐싱 전략은 S3를 위해 최적화된 캐싱 알고리즘이 적용되어 S3에 업데이트가 되어도 변화가 있는걸 인식을하고 바로 적용해주는 것을 확인할 수 있다.

 

 

이렇게 수정한 index.html에 바로 업데이트가 되어 화면에 출력되는 것을 확인할 수 있다.

 

 

만약 캐싱된 데이터가 보여서 수동으로 업데이트를 해주어야 하는 경우에는 배포된 CloudFront의 무효화(Invalidation)탭에 들어가면 무효화를 생성할 수 있는데 여기에 /* 처럼 입력해주면 도메인 하위 리소스에 대한 캐싱 데이터가 사라지고 새롭게 업데이트 된다.

---

Elastic Beanstalk

소개

대부분의 웹앱은 비슷한 서버 아키텍처를 구성하고 있는데 매번 서비스를 만들 때마다 같은 인프라를 계속 만들어줘야한다면 매우 번거로울 것이다.

즉, EBS는 개발자 관점으로 AWS를 접근할 수 있도록 서버 환경을 편리하게 구축할 수 있게 해주는 도구이다.

 

이러한 서버 아키텍처를 백엔드 개발자가 알긴 알아야하지만 주 업무는 코드를 통해 서비스를 만드는 것이므로 EBS는 서비스가 유저들에게 가기 위한 수단들을 더 단순하게 구성할 수 있게 해준다.

 

배포 프로세스를 자동으로 처리하며 필요한 인프라 자원을 구축하고 로드 밸런싱과 오토스케일링 등의 기능을 제공한다.

 

EBS가 기본적인 초기 설정들을 도와주어서 개발자들이 코드에 집중할 수 있게 해주지만 세부설정은 여전히 다 직접 적용해야할 수 있기 때문에 각 서비스들을 알고있긴 해야한다.

 

개념

Application

• 애플리케이션 코드 및 구성 관련 파일을 뜻한다
• EBS는 다양한 프로그래밍 언어와 프레임워크를 지원한다

Environment

• 서버 인프라를 뜻하며 EC2 인스턴스, 데이터베이스 인스턴스, 로드 밸런서 등이 해당된다.

자세한 내용은 아래의 공식 설명을 참고해보면 된다.
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/Welcome.html