[AWS] 6. S3 및 VPC 기초 이해하기

S3는 AWS의 객체 스토리지, VPC는 가상 네트워크.
이번 주차는 이 두 서비스의 개념을 잡고, 콘솔에서 직접 생성해보자.

1. S3 서비스 개요

Amazon S3(Simple Storage Service)는 AWS의 확장 가능한 객체 스토리지 서비스다.

데이터는 버킷(Bucket) 단위로 저장되고, 개별 파일은 객체(Object) 형태로 관리된다.
하나의 객체 최대 크기는 5TB, 저장할 수 있는 객체 수에 제한은 없다.

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

S3 버킷 이름 규칙

3자(최소) ~ 63자(최대)
소문자, 숫자, 점(.), 하이픈(-)만 사용 가능
문자 또는 숫자로 시작하고 끝나야 함
두 마침표를 나란히 붙여 사용하면 안 됨
파티션 내 모든 AWS 리전의 모든 AWS 계정에서 고유해야 함

올바른 예: docexamplebucket, log-delivery-march-2020, my-hosted-content

유효하지 않은 예:

doc_example_bucket — 밑줄 포함
DocExampleBucket — 대문자 포함
doc-example-bucket- — 하이픈으로 끝남

S3 사용 사례

정적 웹 콘텐츠와 미디어 저장 및 배포
백업 도구
전체 정적 웹 사이트 호스팅 (HTML, 이미지, 동영상, 클라이언트 측 스크립트)
연산 및 대규모 분석용 데이터 스토어

2. S3 스토리지 클래스

접근 빈도와 비용에 따라 여러 스토리지 클래스를 선택할 수 있다.

스토리지 클래스	주요 용도	특징
S3 Standard	자주 접근	고비용, 빠른 응답속도, 고가용성, 고내구성
S3 Standard-IA	드물게 접근	낮은 저장 비용, 높은 검색 비용
S3 Intelligent-Tiering	접근 패턴 예측 어려운 데이터	자동으로 비용 효율적 계층 이동
S3 One Zone-IA	단일 AZ, 드물게 접근	비용 절감, 내구성 낮음
S3 Glacier	아카이빙	몇 분~몇 시간 대기 후 접근
S3 Glacier Deep Archive	장기 보관	최소 12시간 대기, 최저 비용

기타 기능

수명 주기 정책 — 생성일 기준으로 저장 스토리지를 자동 변경한다.
예: 30일 후 Standard → Standard-IA, 90일 후 → Glacier로 자동 전환.

버전 관리 — 디폴트로는 비활성화 상태다. 활성화하면 실수로 삭제되는 것을 방지할 수 있다. 같은 키에 대해 여러 버전을 보관하므로 이전 상태로 롤백 가능.

3. S3 버킷 보안

S3는 버킷과 객체 수준에서 정교한 권한 제어와 보안 기능을 제공한다.
퍼블릭 접근 차단이 기본 보안 원칙이다.

S3 버킷 정책 (Bucket Policy)

S3 버킷 전체에 적용되는 JSON 기반 권한 제어 정책이다 (리소스 중심 정책).

기본 구조:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "정책설명용식별자",
      "Effect": "Allow" | "Deny",
      "Principal": "*",
      "Action": "s3:동작",
      "Resource": "arn:aws:s3:::버킷이름/경로"
    }
  ]
}

모든 사용자에게 읽기 허용하는 예시:

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

IAM 정책

사용자나 역할에 적용되는 권한 정책이다 (사용자 중심 정책).
Bucket Policy는 "이 버킷에 누가 접근 가능한가"를 정의하고, IAM 정책은 "이 사용자가 어떤 리소스에 접근 가능한가"를 정의한다.

4. S3 실습 — 버킷 생성, 업로드, 정적 웹 호스팅

데모 절차

S3 콘솔 접속
버킷 생성
객체 업로드 (index.html)
정적 웹사이트 호스팅 활성화
권한 설정 시연
결과 확인

📸 [스크린샷: S3 콘솔에서 버킷 생성 — 버킷 이름, 리전 선택 화면]

버킷 생성 시 리전을 선택하고, 버킷 이름은 글로벌 고유해야 한다.

📸 [스크린샷: 퍼블릭 액세스 차단 설정 해제 화면]

정적 웹 호스팅을 위해 "모든 퍼블릭 액세스 차단" 체크를 해제한다.

📸 [스크린샷: index.html 파일 업로드 화면]

📸 [스크린샷: 속성 탭에서 정적 웹사이트 호스팅 활성화 화면]

정적 웹사이트 호스팅을 활성화하면 엔드포인트 URL이 생성된다.

📸 [스크린샷: 버킷 정책에 PublicRead 정책 JSON 입력 화면]

퍼블릭 액세스 차단을 해제한 것만으로는 외부 접근이 안 된다.
버킷 정책에서 s3:GetObject 를 Allow로 설정해야 실제로 접근 가능하다.

📸 [스크린샷: 엔드포인트 URL로 접속한 결과 — index.html 렌더링 화면]

💡 실습 중 느낀 점

퍼블릭 액세스 차단 해제 ≠ 누구나 접근 가능. "퍼블릭 권한을 부여받을 수 있는 상태"로 만드는 것이고, 실제 접근 허용은 버킷 정책에서 별도로 설정해야 한다. 이전 글(2주차)에서도 겪은 부분인데, 두 단계를 혼동하기 쉽다.
정적 웹 호스팅 URL 형식은 http://버킷이름.s3-website-리전.amazonaws.com이다. 객체 URL(https://s3.amazonaws.com/버킷이름/키)과 다르다. 정적 호스팅용 URL은 index document 자동 서빙, 에러 페이지 설정 등을 지원한다.
버킷 이름에 점(.)을 넣으면 SSL 인증서 매칭에 문제가 생길 수 있다. 정적 호스팅에만 사용하는 버킷이 아니면 점 없이 하이픈으로 구분하는 게 안전하다.

5. VPC 기본 개념과 구성요소

VPC (Virtual Private Cloud)란?

AWS 클라우드에서 사용자가 정의한 논리적 네트워크 공간이다.

사용자 정의 IP 범위 설정 가능
퍼블릭/프라이빗 서브넷 분리 가능 (외부 인터넷 접근 여부에 따라 보안 설계)
보안 그룹과 NACL을 통한 접근 제어 (인스턴스 단위와 서브넷 단위의 방화벽 역할)

VPC 생성 시 선택해야 할 항목

리전 선택
Private IP 주소 범위 선택 (CIDR 표기법)
VPC 이름 결정 (관리 편의를 위해 의미 있는 이름 지정)

CIDR (Classless Inter-Domain Routing)

VPC를 생성할 때 IPv4 주소 범위를 CIDR 블록 형태로 지정한다.

예: 10.0.0.0/16 → 앞 16비트가 네트워크 주소(고정), 뒤 16비트가 호스트 주소(가변) → 10.0.*.* 범위 = 65,536개 IP

RFC 1918 프라이빗 주소 범위를 사용하는 것이 권장된다:

RFC 1918 범위	CIDR 블록 예
10.0.0.0 - 10.255.255.255 (10/8 접두사)	10.0.0.0/16
172.16.0.0 - 172.31.255.255 (172.16/12 접두사)	172.31.0.0/16
192.168.0.0 - 192.168.255.255 (192.168/16 접두사)	192.168.0.0/20

기본 VPC

모든 리전에는 기본 VPC(172.31.0.0/16)가 디폴트로 하나씩 존재한다.
기본 VPC 안에는 모든 가용영역에 하나씩 디폴트 퍼블릭 서브넷이 있다.

📸 [스크린샷: VPC 콘솔에서 기본 VPC와 디폴트 서브넷 목록]

6. 퍼블릭 서브넷과 프라이빗 서브넷

서브넷 생성 시 선택 항목

VPC 및 가용 영역(AZ) 선택 — 어떤 VPC와 어떤 AZ 안에 할당할 것인지
IP 주소 범위 지정 (CIDR 형식) — 예: 10.0.1.0/24 → 해당 범위 내에서 EC2 등의 리소스가 Private IP 할당 받음
서브넷 이름 지정 — 예: public-subnet-a

퍼블릭 서브넷 (Public Subnet)

인터넷 게이트웨이(IGW)를 통해 외부 인터넷과 통신 가능한 서브넷이다.
주로 웹 서버, Bastion Host 등 외부 노출이 필요한 리소스를 배치한다.

핵심: 라우트 테이블에 인터넷 게이트웨이(IGW)가 등록되어 있어야 퍼블릭 서브넷이다.

Destination	Target
10.10.0.0/16	local
0.0.0.0/0	igw-id

프라이빗 서브넷 (Private Subnet)

외부 인터넷과 직접 통신할 수 없고, VPC 내부에서만 통신 가능한 서브넷이다.
주로 데이터베이스, 내부 API 서버 등 민감한 리소스를 배치한다.

Destination	Target
10.10.0.0/16	local

프라이빗 서브넷에서도 NAT Gateway를 라우트 테이블에 등록하면 아웃바운드 트래픽을 인터넷으로 전송 가능하다. 단, 인터넷이 인스턴스에 대한 연결(인바운드)을 설정하는 것은 방지된다.

Destination	Target
10.10.0.0/16	local
0.0.0.0/0	nat-gw-id

💡 실습 중 느낀 점

퍼블릭 서브넷과 프라이빗 서브넷의 차이는 서브넷 자체의 속성이 아니라 라우트 테이블에 IGW가 있느냐 없느냐로 결정된다. 서브넷 설정에 "퍼블릭/프라이빗" 토글 같은 게 있는 줄 알았는데, 전적으로 라우팅 설정에 의존하는 구조였다.
NAT Gateway는 퍼블릭 서브넷에 배치하고, 프라이빗 서브넷의 라우트 테이블에서 0.0.0.0/0 → nat-gw-id로 설정한다. NAT Gateway 자체에 Elastic IP가 할당되어 있어서 프라이빗 인스턴스의 아웃바운드 트래픽이 이 IP로 나간다.
실무에서는 AZ별로 퍼블릭/프라이빗 서브넷 쌍을 만드는 것이 일반적이다. AZ 하나가 장애나도 다른 AZ에서 서비스 지속이 가능한 구조.

7. 네트워크 ACL과 보안 그룹

비교

항목	보안 그룹 (Security Group)	NACL (Network ACL)
적용 대상	EC2 등 리소스 단위	서브넷 단위
상태	상태 저장 (Stateful)	상태 비저장 (Stateless)
규칙 방향	인바운드/아웃바운드 구분	인바운드/아웃바운드 모두 별도 정의
규칙 우선순위	전체 허용 목록 적용	Rule 번호 순으로 적용
허용/거부	허용만 가능	허용/거부 모두 가능
일반 용도	리소스 보호	서브넷 레벨 보안 필터링 또는 보조 방화벽

네트워크 ACL (Access Control List)

VPC의 서브넷 수준에서 트래픽을 제어하는 방화벽이다.

인바운드 트래픽 제어 예시:

Rule #	Type	Protocol	Port Range	Source	Allow/Deny
100	HTTP	TCP	80	0.0.0.0/0	ALLOW
110	SSH	TCP	22	203.0.113.0/24	ALLOW
120	ALL	ALL	ALL	0.0.0.0/0	DENY

→ 80번, 22번 포트 허용, 그 외는 명시적 거부.

Stateless이기 때문에 응답 트래픽도 따로 허용 규칙을 추가해야 한다. 실수로 Deny 규칙을 잘못 설정하면 연결이 완전히 차단될 수 있으므로 순서와 조건을 반드시 확인해야 한다.

보안 그룹 (Security Group)

EC2 등 리소스 (인스턴스) 레벨의 가상 방화벽이다.
허용만 가능하고, 상태 저장(Stateful)이다.

웹 서버용 보안 그룹 예시:

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

⚠️ 포트 22(SSH)는 반드시 자신의 IP로 제한하여 보안을 강화해야 한다.

DB 서버용 보안 그룹 예시:

방향	프로토콜	포트	소스	설명
Inbound	TCP	3306	웹 서버 보안 그룹 ID	MySQL 접근 허용 (같은 VPC 내)
Outbound	ALL	ALL	0.0.0.0/0	모든 아웃바운드 허용

실무에서는 SG를 역할에 따라 나누고, 보안 그룹 간 참조 방식을 적극 활용한다.
웹 서버 / DB / 관리용 별도 SG 설정이 기본이다.

VPC 보안 권장 사항

퍼블릭 서브넷: 반드시 보안 그룹과 NACL로 접근 제어
프라이빗 서브넷: 외부 접근 차단, 필요한 경우 NAT로만 아웃바운드 허용
DB, 내부 서비스, 민감한 리소스는 프라이빗 서브넷에 배치

💡 실습 중 느낀 점

보안 그룹은 Stateful이라 인바운드 허용만 하면 응답이 자동으로 나간다. NACL은 Stateless라 인바운드, 아웃바운드 규칙을 모두 별도 설정해야 한다. 이 차이 때문에 NACL만 설정하고 아웃바운드를 빼먹으면 응답이 안 가는 상황이 발생할 수 있다.
DB 보안 그룹의 소스에 IP 대신 웹 서버 보안 그룹 ID를 지정하는 방식이 인상적이었다. IP가 바뀌어도 SG 참조가 유지되니 유지보수에 훨씬 유리한 구조다.
NACL의 Rule 번호 순서가 중요하다. 100번에서 ALLOW하고 120번에서 DENY하면 100번이 먼저 매칭되어 허용된다. 순서를 잘못 배치하면 의도치 않게 트래픽이 차단될 수 있다.

8. VPC 실습 — VPC와 서브넷 생성

데모 목적

VPC와 서브넷의 개념을 이해하고, 직접 생성해봄으로써 AWS 네트워크 구성의 기본 구조와 구성 요소를 체득한다.

데모 절차

VPC 콘솔 접속
VPC와 서브넷 생성 (자동 생성 기능 이용)
추가 퍼블릭 서브넷 생성
추가 프라이빗 서브넷 생성
결과 확인

📸 [스크린샷: VPC 생성 — "VPC 등" 선택하여 서브넷/IGW/라우트 테이블 자동 생성 화면]

VPC 콘솔의 "VPC 등" 옵션을 선택하면 VPC + 서브넷 + IGW + 라우트 테이블을 한 번에 생성할 수 있다.

📸 [스크린샷: 생성된 VPC 구성도 — 2개 AZ에 퍼블릭/프라이빗 서브넷 배치 미리보기]

구성 예시:

VPC CIDR: 10.0.0.0/16
퍼블릭 서브넷: 10.0.0.0/20 (AZ-a), 10.0.16.0/20 (AZ-b)
프라이빗 서브넷: 10.0.64.0/20 (AZ-a), 10.0.80.0/20 (AZ-b)

📸 [스크린샷: 퍼블릭 서브넷 라우트 테이블 — 0.0.0.0/0 → IGW 확인]

📸 [스크린샷: 프라이빗 서브넷 라우트 테이블 — 10.0.0.0/16 → local만 존재]

📸 [스크린샷: 서브넷 목록에서 4개 서브넷 확인 — 이름, AZ, CIDR 표시]

💡 실습 중 느낀 점

"VPC 등" 자동 생성 기능이 상당히 편리했다. 수동으로 VPC → 서브넷 → IGW → 라우트 테이블을 하나씩 만들면 빠뜨리기 쉬운데, 한 번에 구성도까지 미리보기로 보여준다.
/20 서브넷은 4,096개 IP를 제공한다. 실습에서는 충분하지만 프로덕션에서는 확장을 고려해 CIDR 범위를 넉넉하게 잡는 것이 좋다. 한 번 생성한 서브넷의 CIDR은 변경할 수 없다.
프라이빗 서브넷의 라우트 테이블에 0.0.0.0/0 경로가 없는 것을 직접 확인하니, "인터넷과 단절되어 있다"는 개념이 명확해졌다.

학습 정리

S3는 3개 이상의 AZ에 객체를 중복 저장하여 99.999999999%의 내구성을 제공하는 객체 스토리지다
스토리지 클래스(Standard, IA, Glacier 등)를 접근 빈도에 따라 선택하면 비용을 최적화할 수 있다
퍼블릭 액세스 차단 해제와 버킷 정책 설정은 별개의 단계다 — 둘 다 해야 외부 접근이 가능하다
VPC 생성을 위해 리전을 선택하고, CIDR 표기법으로 프라이빗 주소 범위를 결정한다
퍼블릭 서브넷 = 라우트 테이블에 IGW가 등록된 서브넷, 프라이빗 서브넷 = IGW 없이 VPC 내부 통신만 가능
네트워크 ACL은 서브넷 수준의 Stateless 방화벽, 보안 그룹은 인스턴스 수준의 Stateful 방화벽이다
보안 그룹 간 참조 방식으로 웹 서버 → DB 접근을 제어하면 IP 변경에 강건한 구조를 만들 수 있다

'개인공부' 카테고리의 다른 글

[AWS] 8. 클라우드 아키텍처 설계 기초 (0)	2026.06.20
[AWS] 7. 보안 서비스 WAF, GuardDuty 이해 (1)	2026.06.10
[AWS] 5. EC2 기반 컴퓨팅 서비스 이해하기 (0)	2026.06.10
[AWS] 4. IAM을 활용한 사용자 권한 관리 및 보안 기초 (0)	2026.06.10
[AWS] 3. AWS 비용 구조 및 과금 모델 이해하기 (0)	2026.06.09

grimcode 님의 블로그

[AWS] 6. S3 및 VPC 기초 이해하기

1. S3 서비스 개요

S3 버킷 이름 규칙

S3 사용 사례

2. S3 스토리지 클래스

기타 기능

3. S3 버킷 보안

S3 버킷 정책 (Bucket Policy)

IAM 정책

4. S3 실습 — 버킷 생성, 업로드, 정적 웹 호스팅

데모 절차

💡 실습 중 느낀 점

5. VPC 기본 개념과 구성요소

VPC (Virtual Private Cloud)란?

VPC 생성 시 선택해야 할 항목

CIDR (Classless Inter-Domain Routing)

기본 VPC

6. 퍼블릭 서브넷과 프라이빗 서브넷

서브넷 생성 시 선택 항목

퍼블릭 서브넷 (Public Subnet)

프라이빗 서브넷 (Private Subnet)

💡 실습 중 느낀 점

7. 네트워크 ACL과 보안 그룹

비교

네트워크 ACL (Access Control List)

보안 그룹 (Security Group)

VPC 보안 권장 사항

💡 실습 중 느낀 점

8. VPC 실습 — VPC와 서브넷 생성

데모 목적

데모 절차

💡 실습 중 느낀 점

학습 정리

'개인공부' 카테고리의 다른 글

티스토리툴바

[AWS] 6. S3 및 VPC 기초 이해하기

1. S3 서비스 개요

S3 버킷 이름 규칙

S3 사용 사례

2. S3 스토리지 클래스

기타 기능

3. S3 버킷 보안

S3 버킷 정책 (Bucket Policy)

IAM 정책

4. S3 실습 — 버킷 생성, 업로드, 정적 웹 호스팅

데모 절차

💡 실습 중 느낀 점

5. VPC 기본 개념과 구성요소

VPC (Virtual Private Cloud)란?

VPC 생성 시 선택해야 할 항목

CIDR (Classless Inter-Domain Routing)

기본 VPC

6. 퍼블릭 서브넷과 프라이빗 서브넷

서브넷 생성 시 선택 항목

퍼블릭 서브넷 (Public Subnet)

프라이빗 서브넷 (Private Subnet)

💡 실습 중 느낀 점

7. 네트워크 ACL과 보안 그룹

비교

네트워크 ACL (Access Control List)

보안 그룹 (Security Group)

VPC 보안 권장 사항

💡 실습 중 느낀 점

8. VPC 실습 — VPC와 서브넷 생성

데모 목적

데모 절차

💡 실습 중 느낀 점

학습 정리

'개인공부' 카테고리의 다른 글

'개인공부' Related Articles

티스토리툴바