6주차 - S3/VPC

-S3: Amazon S3(Simple Storage Service)는 AWS의 객체 스토리지 서비스로, 데이터는 버킷(Bucket) 단위로 저장되고, 개별 파일은 파일 내용과 메타데이터를 합친 객체(Object) 형태로 관리된다.

S3의 내부 구조는 플랫(Flat)함

디렉토리처럼 보이는 폴더 구조를 만들 수 있지만 실제로는 계층 구조가 아니고 /doc/a/test.txt처럼 경로 전체가 객체의 이름(키)에 접두어로 붙는 방식이다. 계층 구조를 유지하는 메타데이터가 필요 없어지기 때문에 대규모 서비스에서도 효율적으로 운영 가능하다.

하나의 객체는 최대 5TB까지 저장 가능하고, 저장할 수 있는 객체 수에는 제한이 없다.  

 

 

- S3 주요 특징

S3는 서버리스(Serverless) 서비스 (서버가 없다는 게 아니라 서버 관리를 AWS가 전담한다)

항목	설명
무제한 저장 용량	페타바이트(PB) 이상 대용량도 문제없이 저장 가능
높은 내구성	99.999999999%(11 nine's) — 3개의 AZ에 중복 저장해서 달성
다양한 접근 방식	HTTP(S), CLI, SDK, API로 접근 가능
전 세계 리전 분산	글로벌 인프라 기반 데이터 저장 가능
정적 웹 호스팅 지원	HTML/CSS/JS 파일 업로드 후 버튼 하나로 정적 웹사이트 호스팅 가능 (웹 서버 설치 불필요)
자동 백업 및 복원	버전 관리 및 수명 주기 정책 지원

 

- S3 버킷 이름 규칙 

• 글자 수: 최소 3자 ~ 최대 63자
• 사용 가능 문자: 소문자, 숫자, 점(.), 하이픈(-) — 대문자·언더바 불가
• 시작과 끝: 반드시 문자 또는 숫자로 시작하고 끝나야 함
• 점 두 개(..) 연속 사용 불가
• 같은 파티션(표준·중국·US GovCloud) 내 모든 AWS 계정에서 이름이 유일해야 함

올바른 예: docexamplebucket, log-delivery-march-2020, my-hosted-content
잘못된 예: doc_example_bucket(언더바), DocExampleBucket(대문자), doc-example-bucket-(하이픈으로 끝남)  

 

 

- S3 스토리지 클래스 스토리지 클래스별로 성능과 비용이 달라진다

스토리지 클래스	주요 용도	특징
S3 Standard	자주 접근하는 데이터	고비용, 빠른 응답속도, 고가용성, 고내구성
S3 Standard-IA (Infrequent Access)	드물게 접근하는 데이터	낮은 저장 비용, 검색 시 비용 발생
S3 Intelligent-Tiering	접근 패턴 예측이 어려운 데이터	접근 빈도에 따라 Standard ↔ Standard-IA 자동 이동
S3 One Zone-IA	단일 AZ, 드물게 접근	비용 절감 가능, 내구성 낮음 — 온프레미스 백업본이 따로 있는 경우 활용
S3 Glacier	아카이빙 (장기 보관)	매우 저렴, 데이터 꺼낼 때 몇 분~몇 시간 대기
S3 Glacier Deep Archive	장기 보관 (거의 접근 없음)	최저 비용, 최소 12시간 대기

Intelligent-Tiering과 수명 주기 정책의 차이: Intelligent-Tiering은 "30일 이상 접근 없음"이라는 이벤트 기준으로 클래스를 이동시키고, 수명 주기 정책은 생성일 기준으로 일정 기간이 지나면 자동으로 클래스를 변경하거나 삭제함.  

 

 

- S3 기타 기능 수명 주기 정책
생성일 기준으로 저장 클래스를 자동 변경함. 예를 들어 생성 후 30일이 지나면 Standard → Standard-IA로, 추가 30일 후에는 Glacier로, 365일 후 삭제하는 식으로 설정 가능함.  

 

버전 관리
기본적으로 비활성화되어 있음. 활성화하면 같은 이름의 파일을 다시 업로드해도 이전 버전이 삭제되지 않고 버전 번호가 붙어서 보존됨. 실수로 파일이 덮어써지거나 삭제되는 것을 방지할 수 있음.  

 

- S3 보안 설정 S3는 버킷과 객체 수준에서 권한을 제어할 수 있음. 기본적으로 퍼블릭 접근은 차단되어 있고, 권한은 사용자·역할·리소스·정책(Policy)에 따라 설정함.

구분	설명
버킷 정책 (Bucket Policy)	버킷 전체에 적용되는 JSON 기반 권한 제어 정책 (리소스 중심 정책)
IAM 정책	사용자나 역할에 적용되는 권한 정책 (사용자 중심 정책)

버킷 정책 기본 구조 예시 (모든 사용자에게 읽기 허용):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

Principal: "*"는 누구에게나, s3:GetObject는 객체 읽기 허용을 의미함. 리소스 ARN 뒤에 /*를 붙이면 버킷 내 모든 객체가 대상이 됨.  

 

- VPC

VPC(Virtual Private Cloud)는 AWS 클라우드 안에서 사용자가 직접 정의하는 논리적 네트워크 공간

IP 주소 범위를 직접 지정할 수 있고, 퍼블릭/프라이빗 서브넷으로 나눠서 외부 인터넷 접근 여부를 제어할 수 있다.

VPC 생성 시 선택해야 할 항목: 리전, Private IP 주소 범위(CIDR 표기법), VPC 이름  

 

- CIDR (Classless Inter-Domain Routing)

VPC의 IP 주소 범위는 CIDR 블록 형태로 지정한다. 예를 들어 10.0.0.0/16이면 앞 16비트가 네트워크 주소(고정)이고 나머지 16비트가 호스트 주소(가변)임. 즉 10.0.*.* 범위의 IP를 사용할 수 있다.

RFC 1918 규격에 따른 권장 프라이빗 IP 범위:

RFC 1918 범위	CIDR 블록 예시
10.0.0.0 – 10.255.255.255	10.0.0.0/16
172.16.0.0 – 172.31.255.255	172.31.0.0/16
192.168.0.0 – 192.168.255.255	192.168.0.0/20

 

 

- 퍼블릭 서브넷 vs 프라이빗 서브넷

서브넷은 VPC 안에서 특정 가용 영역(AZ)에 속하는 IP 주소 범위의 묶음임. 라우팅 테이블 설정에 따라 퍼블릭/프라이빗으로 구분됨.

구분	특징	주요 용도
퍼블릭 서브넷	라우팅 테이블에 인터넷 게이트웨이(IGW)가 등록되어 외부 인터넷과 통신 가능	웹 서버, Bastion Host 등 외부 노출이 필요한 리소스
프라이빗 서브넷	라우팅 테이블에 IGW 없음 — VPC 내부에서만 통신 가능	데이터베이스, 내부 API 서버 등 민감한 리소스

프라이빗 서브넷에서 아웃바운드 인터넷 접근이 필요한 경우, NAT Gateway를 퍼블릭 서브넷에 두고 라우팅 테이블에 등록하면 됨. 이렇게 하면 프라이빗 서브넷 → 외부는 가능하지만 외부 → 프라이빗 서브넷 인바운드는 차단됨

 

- 기본 VPC 모든 리전에는 기본 VPC(172.31.0.0/16)가 디폴트로 하나씩 존재한다

 

- 네트워크 ACL vs 보안 그룹 VPC 내 네트워크 보안은 네트워크 ACL과 보안 그룹으로 이중 제어

항목	보안 그룹 (Security Group)	네트워크 ACL (NACL)
적용 대상	EC2 등 리소스(인스턴스) 단위	서브넷 단위
상태	Stateful — 인바운드 허용 시 아웃바운드 자동 허용	Stateless — 인바운드·아웃바운드 각각 별도 정의 필요
규칙 우선순위	전체 허용 목록 적용	Rule 번호 오름차순으로 적용 (작을수록 우선)
허용/거부	허용만 가능	허용·거부 모두 가능
일반 용도	리소스 보호	서브넷 레벨 보안 필터링 / 보조 방화벽

특정 IP에서 DDoS 공격이 오는 경우 — 보안 그룹은 Deny 규칙이 없기 때문에 NACL에서 해당 IP를 차단하는 게 적합

 

 

- 보안 그룹 설정 예시 웹 서버용 보안 그룹:

방향	프로토콜	포트	소스	설명
Inbound	TCP	80	0.0.0.0/0	HTTP 트래픽 허용
Inbound	TCP	443	0.0.0.0/0	HTTPS 트래픽 허용
Inbound	TCP	22	내 IP	SSH 접속 (관리자용) — 반드시 자신의 IP로 제한
Outbound	ALL	ALL	0.0.0.0/0	모든 트래픽 허용 (기본값)

DB 서버용 보안 그룹에서는 소스를 IP가 아닌 웹 서버 보안 그룹 ID로 지정해서, 웹 서버로부터만 MySQL(3306) 접근을 허용하는 방식으로 설정

 

- VPC 보안 권장 사항

퍼블릭 서브넷은 반드시 보안 그룹과 NACL로 접근을 제어하고, 프라이빗 서브넷은 외부 접근을 차단한 뒤 꼭 필요한 경우에만 NAT를 통해 아웃바운드만 허용

DB, 내부 서비스, 민감한 리소스는 프라이빗 서브넷에 배치하는 것이 원칙  

 

- 실습: S3 정적 웹사이트 호스팅

 

1. S3 콘솔에 접속해서 버킷을 생성함. 버킷 이름은 소문자·숫자·하이픈 조합으로 작성하고, 한글이 포함된 HTML 파일을 업로드할 경우 인코딩을 EUC-KR로 저장해야 깨지지 않는다. (그냥 영어 파일 사용했다)

정적 웹사이트 호스팅을 사용할 것이므로 버킷 이름에 . 들어가도 괜찮음

퍼블릭 액세스 허용

 

2. 버킷 생성 후 index.html 파일을 업로드

 

3. 속성 탭 → 정적 웹사이트 호스팅 활성화 → 인덱스 문서에 index.html 입력 후 저장

정적 웹사이트 호스팅 > 편집

 

4. 권한 탭 → 버킷 정책 편집 → 아래 정책 입력 후 저장. my-bucket-name은 실제 버킷 ARN으로 교체

활성화로 변경하고 index.html 기본 표시

아직 권한이 부여되지 않아 접속할 수 없다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicRead",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket-name/*"
    }
  ]
}

권한에서 권한 부여

 

속성 탭의 정적 웹사이트 호스팅 URL로 접속해서 업로드한 HTML 페이지가 정상 렌더링되는 것을 확인

이제 잘 보이는 것을 확인할 수 있다.

 

- 실습: VPC 및 서브넷 생성

목표 아키텍처: VPC 1개(10.0.0.0/16) 안에 퍼블릭 서브넷 2개, 프라이빗 서브넷 2개

 

1. 자동 생성

VPC 콘솔 → VPC 생성 → VPC 등(자동 생성 옵션) 선택
이름: my-vpc / CIDR: 10.0.0.0/16 / 가용 영역 1개 / 퍼블릭 서브넷 1개 + 프라이빗 서브넷 1개 선택
서브넷 CIDR 직접 지정: 퍼블릭 10.0.0.0/20, 프라이빗 10.0.64.0/20.

 

위와 같이 자동으로 잘 생성된 것을 확인할 수 있다.

 

2. 수동 생성

서브넷 메뉴 → 서브넷 생성 → VPC: my-vpc, AZ: 가용 영역 C, CIDR: 10.0.16.0/20

수동 생성

생성한 퍼블릭 서브넷의 라우팅 테이블 연결 편집 → 자동 생성된 퍼블릭 서브넷의 라우팅 테이블(IGW 포함) 선택 후 저장

자동생성에서 만든 라우팅 테이블을 수동생성한 public subnet에도 연결해주어야 함

 

private도 같은 방식으로 생성 및 연결하였다.