L3 AWS 인프라 & 보안 입구

분류: Layer 3 - AWS 인프라 & 보안

핵심 질문

애플리케이션을 AWS에서 운영할 때, 누가 어떤 리소스를 만들고 접근하며 그 리소스는 어디에 놓이고 서로 어떻게 통신하고 데이터를 보존하며 실행되어야 하는가?

3줄 요약

L3는 AWS 서비스를 외우는 레이어가 아니라 소유와 배치, 권한, 네트워크, 데이터, 실행환경의 경계를 연결하는 레이어다.
AWS가 관리형 서비스의 반복 운영을 맡아도 계정, 데이터, 접근 권한, 네트워크 노출, 애플리케이션 설정에 대한 팀의 책임은 사라지지 않는다.
실제 순서는 권한 → 네트워크 → 데이터 → 실행환경 → 다층 보안 → 시크릿으로 이어지며, 뒤 토픽일수록 앞에서 만든 경계를 함께 사용한다.

1. 정의 - AWS 클라우드를 읽는 첫 좌표

AWS 클라우드는 단순히 다른 회사의 컴퓨터를 빌리는 방식이 아니다. 서버, 네트워크, 저장소, 데이터베이스 같은 자원을 API로 만들고, 각 자원의 소유 범위와 배치 위치, 접근 권한, 연결 경로, 운영 책임을 명시하는 환경이다. L3의 목표는 콘솔 메뉴를 많이 아는 것이 아니라 리소스 하나를 보고 어느 경계에 있고 누가 무엇을 책임지는지 설명하는 것이다.

이 설명의 출발점은 계정, 리전, AZ다.

**AWS 계정(account)**은 리소스 소유, 비용, 신원과 정책이 모이는 기본 경계다. 계정의 최상위 소유자인 root 자격증명으로 일상 작업을 하지 않고, 사람과 워크로드를 IAM(Identity and Access Management, AWS API 요청의 권한을 판단하는 시스템) 주체로 분리하는 이유도 이 경계를 한 자격증명이 전부 가지지 않게 하기 위해서다. 계정 ID가 **ARN(Amazon Resource Name, AWS 리소스를 고유하게 가리키는 이름)**과 감사 기록에 등장하는 이유는 “누가 소유한 리소스인가”를 식별해야 하기 때문이다.

**리전(Region)**은 리소스를 운영할 지리적 영역이다. 서울 리전을 고르면 모든 리소스가 한 건물에 놓인다는 뜻은 아니다. 한 리전은 여러 **가용 영역(AZ, Availability Zone)**으로 나뉘며, AZ는 전원·네트워크·건물 장애를 서로 격리하도록 구성된 장애 도메인이다. **VPC(Virtual Private Cloud, AWS 안의 격리된 가상 네트워크)**는 리전 범위에서 설계하고, **Subnet(VPC 주소 범위를 특정 AZ와 용도에 맞게 나눈 구역)**은 하나의 AZ에 둔다. **RDS(Relational Database Service, AWS 관리형 관계형 데이터베이스)**의 **Multi-AZ(주 DB와 대기 DB를 서로 다른 AZ에 두는 고가용성 구성)**나 여러 AZ의 **ECS Task(Elastic Container Service가 컨테이너 실행 스펙을 실제로 실행한 단위)**처럼 한 AZ의 실패를 다른 AZ가 흡수하게 배치할 수 있다.

여기서 중요한 것은 Region = 지리적 선택, AZ = 리전 안의 장애 격리 단위라는 구분이다. 모든 AWS 서비스가 같은 배치 단위를 쓰는 것은 아니다. 어떤 서비스는 리전 단위로 보이고, 어떤 리소스는 특정 AZ의 Subnet과 직접 연결된다. 새 리소스를 볼 때는 이름보다 먼저 계정, 리전, AZ 중 어느 범위에 속하는지 묻는다.

공동 책임과 관리형 서비스

AWS의 **공동 책임 모델(shared responsibility model)**은 보안을 AWS나 고객 한쪽에 전부 맡기지 않는다. AWS는 데이터센터, 물리 장비, 서비스의 기반 인프라처럼 클라우드 자체를 운영한다. 고객은 자신의 계정 안에서 어떤 주체에 권한을 주고, 데이터를 어떻게 보호하고, 네트워크를 어디까지 열고, 애플리케이션을 어떻게 설정할지 책임진다.

서비스가 더 관리형일수록 책임의 일부가 AWS 쪽으로 이동하지만 제품과 데이터에 대한 판단까지 이동하지는 않는다. RDS는 DB 설치, 백업, 패치, 장애 감지와 failover 일부를 관리한다. 그래도 팀은 Private/DB Subnet 배치, Security Group(SG, 리소스에 붙어 허용할 통신을 정하는 stateful 방화벽 규칙), 백업 보관 기간과 복구 검증, 쿼리와 인덱스, 연결 수, 비밀번호 관리를 결정해야 한다. ECS on Fargate도 서버 풀과 OS 운영 부담은 줄이지만 Task의 이미지, CPU와 메모리, IAM Role, Subnet, Security Group, health check는 팀의 설계로 남는다.

따라서 **관리형 서비스(managed service)**는 “운영을 몰라도 되는 서비스”가 아니다. 반복 가능한 기반 운영을 AWS에 넘기고, 팀은 남은 책임의 경계를 더 분명하게 관리하는 선택이다.

2. 선행 단계의 한계와 L3가 등장한 문제

앞선 레이어에서 런타임, HTTP와 API, DNS와 TCP를 알면 요청이 어떻게 만들어지고 네트워크를 지나 서버에 도착하는지 설명할 수 있다. 하지만 그 지식만으로는 운영 환경의 다음 질문에 답하기 어렵다.

배포 파이프라인, 사람, 실행 중인 컨테이너 중 누가 객체 저장소인 S3와 RDS에 접근해도 되는가?
서버와 DB는 어느 계정·리전·AZ에 놓이고, 한 AZ가 실패하면 무엇이 남는가?
인터넷 요청은 어디까지만 공개하고, 애플리케이션과 DB 사이 통신은 어떻게 제한하는가?
이미지와 로그 같은 객체, 관계형 데이터, 실행 중인 프로세스는 각각 어떤 리소스에 두는가?
AWS가 관리하는 영역과 팀이 계속 운영해야 하는 영역은 어디에서 갈리는가?

단일 서버에서는 이 결정들이 서버 한 대의 사용자 계정, 방화벽, 디스크, 프로세스 설정 안에 섞여 있었다. 클라우드에서는 같은 결정을 여러 독립 리소스와 정책으로 나누어 표현한다. 분리는 확장과 자동화를 가능하게 하지만, 경계를 연결하지 못하면 서버는 실행 중인데 DB 연결만 실패하거나, 정책은 있어 보이는데 S3가 AccessDenied를 반환하거나, Task는 정의됐는데 이미지와 secret을 가져오지 못하는 일이 생긴다.

L3는 이 문제를 경계와 책임을 먼저 그리고, 서비스 설정을 그 위에 놓는 방식으로 해결한다.

3. 핵심 철학 - 서비스를 외우지 말고 경계를 연결한다

L3에서 서비스 이름은 목적지가 아니라 경계를 구현하는 수단이다. 다음 다섯 질문을 한 시스템에 이어 붙이는 것이 이 레이어의 핵심 철학이다.

사고 축	먼저 묻는 질문	다음 축과의 연결
리소스 경계	어느 계정·리전·AZ에 무엇을 만들며, 어떤 장애 범위를 받아들이는가?	배치한 리소스를 누가 만들고 변경할 수 있는지 권한 경계로 이어진다.
권한	어떤 주체가 어떤 Action을 어떤 Resource에 어떤 조건으로 수행하는가?	API 호출 권한과 실제 패킷이 도달할 네트워크 경로는 별도로 통과해야 한다.
네트워크	source에서 destination까지 주소, Route, Subnet, SG가 어떻게 이어지는가?	도달 가능한 경로 위에서 어떤 데이터와 실행환경을 노출할지 결정한다.
데이터	객체와 관계형 데이터 중 무엇을 저장하며, 삭제·복구·복제를 누가 맡는가?	실행환경이 이 데이터를 읽고 쓸 권한, 연결 수, secret 전달 방식과 이어진다.
실행환경	VM과 컨테이너 중 무엇을 어디서 몇 개 실행하고, 실패 시 누가 복구하는가?	실제 트래픽 경로가 생기면 network security와 secrets가 전체 경계를 다시 좁힌다.

이 다섯 축은 독립 체크리스트가 아니다. 예를 들어 Private Subnet의 ECS Task가 RDS에 연결하려면 다음 조건이 동시에 맞아야 한다.

계정·리전·AZ: Task와 DB가 의도한 환경과 장애 도메인에 배치된다
권한:         ECS 플랫폼과 애플리케이션이 각각 필요한 IAM Role을 가진다
네트워크:     Subnet 경로와 RDS SG가 Task SG의 DB 포트를 허용한다
데이터:       RDS가 관계형 상태를 보존하고 백업·failover 경계를 제공한다
실행환경:     ECS Service가 원하는 수의 healthy Task를 유지한다
secret:       DB credential이 코드가 아니라 허용된 경로로 Task에 전달된다

한 줄이라도 빠지면 전체 요청은 실패한다. 그래서 “AWS 설정이 문제다”라고 뭉개지 않고 어느 경계까지 통과했는지 분리해서 본다.

4. 레이어 사고 모델 - 계정에서 실행 중인 요청까지

L3의 리소스를 아래처럼 읽으면 서비스가 낱개로 흩어지지 않는다.

AWS Account
├─ 권한과 감사: IAM 주체, Role, Policy, API 호출 기록
└─ Region
   ├─ VPC: 주소 범위와 통신 경로
   │  ├─ AZ-A: 공개 진입점, 애플리케이션 Subnet, DB Subnet
   │  │  └─ ALB(Application Load Balancer, 공개 요청을 분산하는 진입점), ECS Task, RDS
   │  └─ AZ-B: 장애를 분리할 두 번째 배치
   │     └─ ECS Task, RDS standby
   └─ S3(Simple Storage Service): bucket + key로 보존하는 리전 단위 객체 저장소

외부 요청
  -> 공개 진입점
  -> 허용된 네트워크 경로
  -> ECS 실행환경
  -> S3 또는 RDS 데이터

이 그림은 모든 AWS 서비스가 VPC 안에 있다는 뜻이 아니다. IAM은 AWS API 호출의 권한 계층이고, S3 같은 서비스는 이후 VPC 본문에서 배우는 private AWS 서비스 접근 경로나 인터넷 방향의 outbound 경로를 통해 Private Subnet의 워크로드와 연결될 수 있다. 중요한 것은 경로 기술의 이름을 지금 외우는 것이 아니라 요청이 권한 판정, 네트워크 경로, 데이터 접근, 실행 상태를 각각 통과한다는 점이다.

장애를 볼 때도 같은 순서를 거꾸로 사용한다.

호출 주체가 예상한 사람·Role·Task인가?
요청한 리소스와 Action이 정책 범위에 들어가는가?
source와 destination 사이에 Route와 Security Group 허용이 있는가?
S3 key, RDS endpoint, ECS Task처럼 실제 대상이 기대한 상태인가?
관리형 서비스가 맡은 부분과 애플리케이션이 맡은 부분 중 어디가 실패했는가?

이것은 운영 런북이 아니라 문제를 놓을 좌표다. 각 토픽은 이 질문 중 하나를 더 깊게 다룬다.

5. 실제 learning_order를 읽는 순서

learning_order는 개념이 자연스럽게 누적되도록 정한 추천 서술 순서이지, 일곱 문서가 모두 한 줄로만 연결된 엄격한 선수 체인은 아니다. IAM과 VPC는 서로를 먼저 요구하지 않는 독립 root다. 권한 경계가 급하면 IAM부터, 네트워크 배치가 급하면 VPC부터 시작할 수 있지만, 처음 읽을 때는 아래 순서가 두 관점을 가장 매끄럽게 합친다.

L3 추천 학습 순서

10. IAM - 모든 AWS 작업의 권한 경계
누가 어떤 리소스에 어떤 작업을 할 수 있는지 먼저 배운다. 뒤의 S3, ECS, secret 접근은 모두 IAM 판정을 통과한다.
20. VPC / Subnet / Security Group - 배치와 통신 경계
리전 안의 주소 범위를 AZ별 Subnet으로 나누고, Route와 SG로 패킷이 갈 수 있는 길과 허용 범위를 만든다.
30. S3 Basics - 객체 데이터의 경계
bucket + key 기반 객체 저장, IAM과 Bucket Policy, 보존 수명과 공개 범위를 본다. RDS와 다른 데이터 형태를 먼저 잡는다.
40. RDS Basics - 관리형 관계형 데이터의 책임 경계
VPC 위에서 관계형 DB를 배치하고, 백업·Multi-AZ·연결 중 AWS가 맡는 일과 팀이 남겨 둔 일을 구분한다.
50. ECS vs EC2(Elastic Compute Cloud, AWS 가상 서버) - 경계가 만나는 실행환경
IAM, VPC, S3, RDS를 실제 애플리케이션 Task와 연결한다. compute와 orchestration, EC2와 Fargate의 책임 차이를 본다.
60. Network Security - 통신 경계의 다층 방어
이미 그린 요청 경로 위에서 리소스·서브넷·HTTP·암호화·관측 계층의 방어가 각각 어떤 공격과 실패를 보는지 구분한다. 구체 도구는 본문에서 배운다.
70. Secrets Management - 권한 값을 실행환경에 전달하는 경계
권한, 암호화 키 관리, 네트워크, ECS 주입 경로를 합쳐 DB 비밀번호와 API key를 코드 밖에서 저장·조회·교체하는 모델을 완성한다.

실제 prerequisite 그래프는 두 root에서 갈라졌다 다시 합쳐진다. S3는 IAM의 권한 관점을 이어받고, RDS는 VPC의 네트워크 관점을 이어받는 서로 다른 데이터 경로다. ECS는 IAM·VPC·S3·RDS와 HTTP 기초를 실행환경에서 합친다. 따라서 S3 다음 RDS는 직접 선수 관계가 아니라 객체 데이터와 관계형 데이터를 차례로 비교하기 위한 추천 순서다.

후반에도 두 분기가 있다. Network Security는 VPC와 L1 Web Security를 바탕으로 통신 방어를 확장하므로 ECS를 반드시 먼저 요구하지 않는다. Secrets Management는 IAM·VPC·ECS를 바탕으로 자격증명 전달 경계를 완성하며, Network Security를 선수로 요구하지 않는다. 60 → 70은 요청 경로의 방어를 본 뒤 그 경로로 전달되는 secret을 읽기 위한 추천 서술 순서이고, 각 prerequisite를 충족했다면 필요한 분기부터 읽을 수 있다.

6. 첫 회독과 선택 심화의 경계

첫 회독의 목표는 모든 AWS 옵션과 가격을 기억하는 것이 아니다. 각 문서에서 아래 통과선까지만 잡고 다음 순서로 이동한다.

토픽	첫 회독에서 반드시 잡을 것	문제를 만났을 때 선택 심화할 범주
IAM	요청 주체, 작업, 대상 리소스, 조건, 명시적 거부, 임시 권한 역할	외부 시스템 신뢰, 조직·역할별 권한 상한, 정책 변경 복구
VPC	가상 네트워크·Subnet·AZ, 목적지 경로, Public/Private 구분, 리소스 간 허용	주소 공간 확장, private outbound 비용, Subnet 방어와 연결 상태
S3	bucket + key 객체 모델, 주체·리소스 정책, 버전 보존과 수명 주기	클라이언트 직접 업로드, 고요청률 key 설계, 저장 등급, 대량 삭제
RDS	관리 책임 경계, 고가용성과 읽기 확장 차이, 접속 주소, 애플리케이션 연결 수	시점 복구, DB 연결 중계와 세션 상태, DB 설정, 비용
ECS	서버·오케스트레이션·관리형 실행 차이, 실행 스펙·Task·Service, 목표 상태·경로	실행 자원 혼합, 배포 여유, 자원 크기, 중단형 할인, 실행 방식 전환
Network Security	IP/포트·Subnet·HTTP·DDoS·전송 암호화·로그가 맡는 방어 계층	HTTP 규칙 조정과 비용, 고급 DDoS 보호, 내부 구간 암호화 운영
Secrets Management	secret을 권한으로 보는 관점, 권한·키·네트워크·소비자 경로, 교체	API 한도, 무중단 DB 자격증명 교체, 저장소 선택, 짧은 수명 자격증명

첫 회독에서 표의 오른쪽 내용을 이해하지 못해도 실패가 아니다. 왼쪽 질문으로 현재 설계를 설명할 수 있고, 어느 문제가 생겼을 때 오른쪽으로 들어가야 하는지 알면 입구의 목적을 달성한 것이다. 오른쪽 범주의 구체 기술명과 동작 방식은 각 후속 본문에서 처음 정의한 뒤 배운다.

7. 막힐 때 돌아갈 곳

막히는 느낌	보통 부족한 전제	돌아갈 곳
ALB, API, status code, 요청과 응답의 관계가 한꺼번에 섞인다	HTTP 요청 경로	`content/topics/L1/http-basics.mdx`
IP, port, timeout, L4/L7, 프록시 경계를 구분하기 어렵다	네트워크 계층과 전송 기초	`content/topics/L2/osi-web-server.mdx` → `content/topics/L2/tcp-udp-internals.mdx`
endpoint 이름과 실제 연결 주소, DNS cache가 왜 다른지 모르겠다	이름 해석과 TTL	`content/topics/L2/dns-basics.mdx`
WAF와 애플리케이션 인증·인가·입력 검증이 같은 방어처럼 보인다	웹 신뢰 경계	`content/topics/L1/web-security-basics.mdx`
ECS에서 image와 container가 같은 말처럼 느껴진다	Docker의 패키지와 실행 단위	외부 전제로 image와 container 차이만 먼저 확인한다. `content/topics/L5/docker-basics.mdx`는 이후 심화다.
RDS의 SQL·테이블·행·트랜잭션 용어 자체가 낯설다	관계형 DB와 SQL CRUD 기초	외부 기초를 먼저 보충하고, L3에서는 RDS의 관리 책임과 네트워크 배치까지만 읽는다.
KMS 설명에서 평문, 암호문, key가 구분되지 않는다	암호화 기본 용어	세 용어만 보충한 뒤 Secrets Management의 Envelope Encryption 흐름으로 돌아온다.

Docker Basics는 저장소 안에 있지만 L5 문서이므로 L3 frontmatter의 선수 토픽으로 역행 연결하지 않는다. ECS 첫 회독에 필요한 것은 image가 실행 템플릿이고 container가 그 템플릿의 실행 인스턴스라는 구분뿐이다. 마찬가지로 DB 내부 원리는 L8에서 깊게 다룬다. L3에서는 관리형 RDS를 어느 네트워크에 두고 어떤 책임을 남길지에 집중한다.

8. 준비 상태

L3 Readiness check

AWS 계정, 리전, AZ를 각각 소유·지리·장애 격리 경계로 구분해 설명할 수 있다.
관리형 서비스가 운영 책임을 줄이지만 데이터·권한·네트워크·애플리케이션 책임까지 없애지는 않는다고 말할 수 있다.
리소스 하나를 보고 계정·리전·AZ, 호출 주체, 네트워크 경로, 데이터, 실행환경을 차례로 질문할 수 있다.
learning_order가 추천 서술 순서이고, IAM·VPC 두 root에서 데이터·실행·보안 분기로 이어지는 실제 선수 관계와 다르다는 점을 설명할 수 있다.
S3와 RDS가 각각 객체와 관계형 데이터를 다루며, ECS가 이 데이터 경로를 사용하는 실행환경이라는 차이를 안다.
막힐 때 HTTP, 네트워크, DNS, 웹 보안, Docker, SQL, 암호화 중 어떤 기초로 돌아갈지 고를 수 있다.

모든 AWS 서비스를 직접 만들어 본 경험은 준비 조건이 아니다. 첫 세 항목을 내 말로 설명할 수 있고 막힐 때 돌아갈 경로를 안다면 IAM 문서로 들어갈 준비가 된 상태다.

9. Lineage - 다음 레이어로 이어지는 경계

앞의 lineage 절에서 본 단일 서버 운영의 한계를 L3가 소유·배치·권한·데이터·실행 경계로 분해했다면, 다음 단계는 이 경계를 반복 가능하고 관측 가능하게 만드는 일이다.

코드와 통신 이해 → L3 클라우드 경계 설계 → L5 자동화 → L6 운영·관측

L3의 핵심은 서비스 이름의 합이 아니라 리소스가 어디에 있고, 누가 어떤 경로로 무엇을 할 수 있으며, 어느 운영 책임이 팀에 남는지 연결하는 것이다.