[에스넷시스템 부트캠프] TIL Day 25 - AWS 개념 1
1. AWS 글로벌 인프라
1) AWS 데이터 센터
- 단일 데이터 센터에 수천 개의 서버 운영
- 모든 데이터 센터는 온라인으로 연결됨
- Amazon 사용자 정의 네트워크 장비 및 프로토콜 스택 사용 : 아마존이 직접 설계한 맞춤형 하드웨어와 소프트웨어 스택으로 구성
- 다양한 ODM(Original Design Manufacturer) 기반 하드웨어 채택
2) 가용 영역 (Availability Zone, AZ)
- 하나 이상의 데이터 센터로 구성
- 결함 격리 설계: 하나가 장애 나도 나머지는 정상 운영
- 고속 프라이빗 링크를 통해 다른 AZ와 상호 연결
- 사용자가 AZ 선택 가능
- 복원력 확보를 위해 여러 AZ에 걸쳐 배포 권장
- 일반적으로 리전당 2개 AZ 권장
- 3개 이상 AZ 사용 시 비용 효율성 저하 가능
3) 리전 (Region)
- 각 리전은 두 개 이상의 가용 영역으로 구성
- 사용자가 데이터 복제를 리전 단위로 제어 가능
- 리전 간 통신은 AWS 백본 네트워크 인프라 이용
- 리전 선택 시 고려사항
- 데이터 주권 및 규제 준수
- 사용자 또는 서비스 근접성
- 서비스 및 기능 가용성
- 비용 효율성
4) 비관리형과 관리형 서비스
유형 | 설명 | 예시 |
비관리형 서비스 | 사용자가 확장, 고가용성, 내결함성을 직접 관리 | EC2에 직접 DB 설치 |
관리형 서비스 | AWS가 확장성, 내결함성, 가용성을 기본 제공 | Amazon RDS 사용 |
5) 공동 책임 모델
- AWS 책임: 글로벌 인프라, 하드웨어, 네트워크, 물리적 보안 등
- 고객 책임: OS 패치, 애플리케이션 설정, IAM 관리, 데이터 보호 등
2. AWS 핵심 서비스
1) VPC (Virtual Private Cloud)
1-1) VPC란?
- AWS 계정 전용의 가상 네트워크(Virtual Network) 를 클라우드 상에 구성할 수 있도록 해주는 서비스
- 다른 AWS 계정의 VPC와 논리적으로 격리되어 있음
- 대부분의 AWS 리소스는 VPC 내에서 실행됨 (예: EC2)
- S3, DynamoDB와 같은 서비스는 퍼블릭 인터넷 없이도 연결되도록 VPC 엔드포인트 제공
- VPC의 주요 기능:
- IP 주소 범위(CIDR)
- 라우팅 테이블
- 게이트웨이 구성
- 보안 그룹 및 ACL 설정
1-2) VPC 구성 전략
- 다중 VPC 패턴
- 단일 조직/단일 팀 중심
- 관리가 간편하고 표준화 유지에 유리
- 거버넌스 및 규정 준수 기준 만족 가능
- 복수 계정 패턴
- 대규모 조직 및 IT 팀이 많은 경우
- 조직 간 자원 분리 및 보안성 확보에 유리
- 표준 유지와 권한 관리가 상대적으로 복잡
1-3) VPC 및 IP 주소
- IP 주소 범위를 CIDR (Classless Inter-Domain Routing) 형식으로 설정
- 예: 10.0.0.0/16 → 약 65,536개 IP 주소 가능
- 가장 낮은 IP: 10.0.0.0
- 가장 높은 IP: 10.0.255.255
- 초기 설정 시 너무 작게 잡으면 나중에 확장 불가 → 여유 있는 범위 권장
1-4) 서브넷
- CIDR 범위 안에서 네트워크를 세그먼트 단위로 나눈 것
- 각 서브넷에서 처음 4개 + 마지막 1개 IP는 AWS가 예약
- 서브넷 유형
-
유형 특징 주 용도 퍼블릭 서브넷 인터넷 게이트웨이를 통한 외부 액세스 허용 웹 서버, 로드 밸런서 프라이빗 서브넷 외부에서 직접 접근 불가 DB 서버, 백엔드 서버, 배치 처리 등
-
- 권장사항
- 가용영역(AZ)마다 퍼블릭 1개 + 프라이빗 1개로 시작
- 프라이빗 서브넷에 더 많은 IP 할당
- 서브넷 CIDR 크기는 /24 이상(256개 IP)으로 넉넉하게 설정
2) EC2 인스턴스
2-1) 인스턴스 유형
유형 | 설명 |
일반 목적 | 균형 잡힌 CPU, 메모리, 네트워크 성능 (ex. t4g, m6i 등) |
컴퓨팅 최적화 | 높은 CPU 성능이 필요한 워크로드에 적합 (ex. c6g, c7i 등) |
메모리 최적화 | 대용량 인메모리 데이터 처리에 유리 (ex. r6i, x2idn 등) |
스토리지 및 I/O 최적화 | 고속 SSD나 IOPS가 중요한 워크로드에 적합 (ex. i4i 등) |
GPU/FPGA 인스턴스 | 머신러닝, 그래픽 렌더링, 과학 계산용 (ex. p4, f1 등) |
버스트 가능 인스턴스 (T 타입) | 기본 성능 유지 + 크레딧 방식으로 일시적인 고성능 지원 사용량이 적을 때 CPU 크레딧이 충전되며, 필요 시 소모 |
2-2) EC2 요금 종류
- 온디맨드 (On-Demand)
- 필요할 때 즉시 생성하고 사용한 만큼만 지불
- 초 단위 청구
- 유연성과 편의성이 높음
- 장기 실행 시 비용이 비쌈
- 스팟 인스턴스 (Spot)
- AWS의 남는 용량을 경매 방식으로 저렴하게 제공
- 초 단위 청구
- 인스턴스가 언제든 중단될 수 있음
- 예시: 5달러짜리 인스턴스를 스팟으로 3달러에 사용 중, 누군가가 3.1달러로 입찰 시 중단됨
- 적합한 상황:
- 단기/일시적 작업
- 장애 허용 가능한 애플리케이션
- 대규모 배치 처리, 분산 컴퓨팅
- 추가 기능:
- EBS 기반 인스턴스는 최대 절전 상태로 전환 가능
- 복원 시 암호화된 루트 볼륨 유지
- 별도 최대 절전 에이전트 설치 필요
- 예약 인스턴스 (Reserved)
- 1년 또는 3년 단위 계약
- 장기적인 워크로드에 적합
- 선결제 없이도 요금 할인 가능
- 해지 불가 (마켓플레이스 재판매는 가능)
- 예측 가능한 컴퓨팅 리소스 확보
- 전용 호스트 (Dedicated Host)
- 물리 서버 단위로 전용 인스턴스를 운영
- 온디맨드나 예약 방식 모두 지원
- 최대 70% 할인된 예약 옵션 존재
- 라이선스 BYOL(Bring Your Own License) 가능
- 규제 또는 보안 규정 준수가 필요한 환경에 적합
3) 스토리지
3-1) S3 (Simple Storage Service)
- 객체 스토리지 서비스
- 수십억 개의 객체를 저장할 수 있고, 자동 중복 저장으로 높은 내구성 제공
- 관리형 서비스로 확장성 뛰어남
- 데이터 업로드/삭제 시 알림, 워크플로, 스크립트 트리거 가능
- 전송 및 저장 시 자동 암호화 (SSL/TLS)
- S3 Analytics로 스토리지 클래스 자동 분석 및 최적화
- 요금:
- 월별 GB 단위 청구
- 다른 리전으로 전송 시 비용 발생
- 같은 리전 내 EC2/CloudFront 간 통신은 무료
3-2) EBS (Elastic Block Store)
- 블록 스토리지 서비스 (EC2 전용 디스크)
- 볼륨 단위 생성 후 EC2 인스턴스에 연결
- 변경된 블록만 업데이트되어 성능 및 저장 효율성 향상
- 가용 영역 내에서 자동 복제
- SSD / HDD 볼륨 선택 가능
- 용도: EC2 루트 디스크, 데이터 저장, DB용 디스크 등
3-3) EFS (Elastic File Storage)
- 공유 파일 스토리지 (NFS 기반)
- 페타바이트(PB) 단위 확장 지원
- 여러 EC2 인스턴스가 동시에 파일 시스템 공유 가능
- VPC 내 서브넷 및 보안 그룹 구성 필수
- 가용 영역(AZ)마다 하나씩 배포 필요
3-4) S3 Glacier
- 아카이빙 전용 객체 스토리지
- 낮은 비용 & 높은 내구성
- 데이터는 장기 보관용, 즉각 접근은 어려움
- SSL/TLS 기반 전송 및 저장 암호화
- 스토리지 잠금 기능을 통해 규제 준수 강화
💡 백업 vs 아카이브
백업은 운영 중 생기는 불상사를 대비해서 만들어주는 압축, 이미지화된 파일
아카이빙은 보관, 더이상 변하지 않을 데이터로 영구 보관급으로 저장
3-5) 데이터베이스
- RDS (Relational Database Service)
- 완전 관리형 관계형 DB 서비스
- 자동 백업, 모니터링, 확장, 고가용성 지원
- 지원 엔진:
- Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, MS SQL Server
- 적합한 사용 사례:
- 복잡한 트랜잭션 처리
- 보통~고속의 쿼리 처리
- 단일 노드 기반 애플리케이션
- 부적합한 경우:
- 초고속 대규모 처리 (샤딩 필요)
- 간단한 키-값 저장 (NoSQL이 더 적합)
- DynamoDB
- 완전 관리형 NoSQL 데이터베이스
- 초당 수백만 요청까지 확장 가능
- 10ms 미만의 일관된 응답 속도
- 글로벌 테이블 기능으로 리전 간 데이터 복제
- SSD 기반, 자동 백업 지원
- 문서형 및 키-값 모델 지원
- 적합한 분야:
- 모바일/웹 앱, IoT, 게임, 광고 트래픽 등
4) IAM (Identity and Access Managment)
- AWS 리소스에 대한 사용자의 액세스 및 인증을 중앙에서 관리해주는 서비스
- 사용자, 그룹 및 역할을 생성하고 정책을 이에 적용하여 AWS 리소스에 대한 액세스를 제어
- 사용자에게는 최소한의 권한만 부여
4-1) 보안 자격 증명 유형
유형 | 설명 |
이메일 주소 + 암호 | AWS 루트 계정 로그인 시 사용 |
IAM 사용자 이름 + 암호 | 콘솔 로그인용 |
액세스 키 (Access Key) | 프로그래밍 또는 CLI 접근용 (ID + Secret Key) |
MFA (Multi-Factor Authentication) | 추가 인증 수단 (OTP 앱, 보안 키 등) |
키 페어 (Key Pair) | EC2 인스턴스 접속을 위한 공개/비공개 키 세트 |
4-2) 권한 평가 흐름
- Group에 Policy x를 지정해주면 Group에 속한 Alice, Bob, Chris가 본인이 원래 가지고 있던 Policy에 Policy x가 추가로 붙음
- Alice가 Role ㄱ을 Assume하면, 기존의 User Policy(a) 및 Group Policy(x)는 적용되지 않고 Role ㄱ의 정책만 적용됨
- 하지만 Role ㄱ에는 아무 Policy도 없기 때문에 Alice는 어떤 권한도 가지지 않음
- Bob이 Role ㄴ을 Assume하면, 기존의 User Policy(b) 및 Group Policy(x)는 적용되지 않고 Role ㄴ의 Policy(x)만 적용됨
4-3) CloudTrail
- AWS API 요청을 추적하고 기록하는 로깅 서비스
- 누가 언제 어떤 리소스에 어떤 작업을 했는지 로그로 확인 가능
- 기본적으로 계정 전체 및 모든 리전에 대해 설정 가능
- S3 버킷에 로그 저장, 접근은 관리자 등 필요한 사용자만 허용
- 루트 계정을 생성하자마자 CloudTrail 활성화 권장
3. 백업 및 복구 모범 사례
- 인스턴스 주기적 백업
- 고가용성 구성
- IP 주소 동적 할당 설계
- 이벤트 모니터링 및 자동 대응
- 장애 조치 절차 문서화
- 복구 테스트 정기 수
4. VPC 트래픽 제어
1) 라우팅 테이블
- VPC 내 리소스 간 트래픽 흐름을 제어
- 서브넷마다 하나의 라우팅 테이블만 연결 가능
- 로컬 경로(Local Route): 같은 VPC 내 통신을 위한 기본 경로
- 메인 라우팅 테이블 vs 사용자 지정 라우팅 테이블
→ 사용자 지정 라우팅 테이블은 특정 서브넷에 명시적으로 연결
2) 보안그룹
- 인스턴스 단위의 가상 방화벽
- 상태 기반(Stateful):
- 인바운드가 허용되면 그에 대한 아웃바운드는 자동 허용
- 기본 설정: 모든 인바운드 트래픽 차단, 모든 아웃바운드 허용
- CIDR 블록 또는 다른 보안 그룹을 소스/대상으로 지정 가능
- EC2, RDS 등 인스턴스 레벨 제어에 주로 사용
3) 네트워크 ACL (NACL)
- 서브넷 단위의 방화벽
- 상태 비저장(Stateless): 요청과 응답을 별도로 정의해야 함
- 기본 설정: 모든 트래픽 허용
- 명시적으로 허용/거부 규칙 정의 가능
- 서브넷 경계에 적용되며, 보안 그룹보다 우선적으로 동작하지 않음 (보완적 역할)
4) 인터넷 게이트웨이 (IGW)
- 퍼블릭 서브넷에 있는 인스턴스가 인터넷과 통신할 수 있도록 연결해주는 장치
- 중복 구성 + 고가용성 보장
- 라우팅 테이블에 IGW 경로를 추가해야 인터넷 통신 가능
- 퍼블릭 통신을 위해서는 인스턴스에 퍼블릭 IP 또는 탄력적 IP(EIP) 할당 필요
- 관련 보안 그룹 및 NACL도 인터넷 트래픽 허용 필요
5) NAT
VPC의 프라이빗 서브넷 인스턴스가 인터넷에 아웃바운드 연결은 가능하지만 인바운드 연결은 차단되도록 할 때 사용
- VPC NAT 게이트웨이
- AWS 관리형 서비스
- 고가용성 및 자동 확장 지원
- 퍼블릿 서브넷에 배치, 프라이빗 서브넷에서 라우팅
- EC2의 NAT 인스턴스
- 사용자가 직접 EC2 인스턴스를 NAT 용도로 설정
- 비용은 저렴하지만 확장성, 유지보수 부담 큼
- 고가용성 구성 시 수동 작업 필요
5. VPC 트래픽 로깅 - VPC Flow Logs
- VPC, 서브넷, 네트워크 인터페이스(ENI) 단위로 트래픽 흐름 로깅 가능
- 로그는 CloudWatch Logs 또는 S3에 저장 가능
- 보안, 성능 문제 분석, 이상 징후 탐지 등에 유용
💡 ENI (Elastic Network Interface)란?
AWS에서 가상 네트워크 인터페이스를 의미한다. IP 주소, MAC 주소, 보안 그룹 등 네트워크 속성을 가지고 장애 조치나 멀티 NIC 네트워크 설계에 활용된다.
하나의 EC2 인스턴스에 하나 이상의 ENI 연결이 가능하다.
6. VPC 피어링
1) VPC 피어링이란?
- 서로 다른 VPC 간에 프라이빗 IP를 사용하여 통신 가능하게 하는 연결 방식
- 마치 같은 네트워크에 있는 것처럼 EC2 인스턴스 간 통신 가능
- 리전 간 피어링도 지원
- 전이(transitive) 피어링은 지원하지 않음 → 반드시 1:1 직접 연결 필요
2) 제한 조건
- IP 주소 범위(CIDR)가 중복되면 피어링 불가
- 2개의 VPC 사이에는 하나의 피어링 연결만 허용
- 다른 AWS 계정 간에도 연결 가능 (Cross-account 지원)
- 전이적 피어링 ❌, 즉 A ↔ B, B ↔ C가 되어도 A ↔ C는 자동 연결되지 않음
3) 보안 구성 요소
- 라우팅 테이블 : 피어 VPC의 서브넷으로 트래픽을 라우팅
- 보안 그룹 : 인스턴스 수준에서 수신/송신 트래픽 제어
- NACL : 서브넷 수준에서 트래픽 허용/차단 제어
- 양쪽 승인 필요 : 피어링 요청자는 요청, 상대는 수락해야 연결 성립
💡 Edge-to-Edge 라우팅이란?
IGW, VPN, Direct Connect 등 엣지 장치(인터넷 출입구)를 통해 들어온 트래픽을 피어링된 VPC로 자동 전달하는 것을 말한다.
💡 전이적 트러스트란?
A가 B와 피어링, B가 C와 피어링했을 때 A가 C와 통신 가능한 것처럼 연결 관계를 전이하는 것을 말한다.
7. Direct Connect
- AWS와 사용자의 온프레미스 데이터 센터 간의 전용 네트워크 연결
- 인터넷을 통하지 않고 안정적인 네트워크 통신 가능
- 주요 이점
- 전송 비용 절감: 대역폭이 큰 데이터 이전 시 효율적
- 지연 시간 감소: 애플리케이션 성능 향상
- 보안 강화: 인터넷이 아닌 전용 회선을 통해 연결되어 규정 준수 수월
8. 기본 VPC와 기본 서브넷
1) 기본 VPC
- AWS 계정 생성 시 각 리전에 자동으로 생성
- CIDR: 172.31.0.0/16
- 별도의 VPC를 지정하지 않으면 기본 VPC에 리소스 배치됨
- 다음 리소스를 기본으로 포함:
- 퍼블릭 서브넷
- 인터넷 게이트웨이(IGW)
- 라우팅 테이블
- 보안 그룹
- 네트워크 ACL
2) 기본 서브넷
- 각 가용 영역마다 하나씩 자동 생성
- 기본적으로 퍼블릭 서브넷(/20) 으로 설정
- IGW로 향하는 경로를 제거하면 프라이빗 서브넷으로 변환 가능
- 리전에 새 AZ가 생기면, 기본 VPC에 해당 AZ용 기본 서브넷이 자동 추가됨
✅ 기본 VPC/서브넷은 실습이나 테스트용으로만 사용하고,
운영 환경에서는 보안과 구조를 고려한 사용자 정의 VPC를 사용하는 것이 권장된다.
9. 고가용성
1) ELB (Elastic Load Balancing)
- 여러 인스턴스에 트래픽을 자동 분산
- 비정상 인스턴스 자동 감지 및 제외
- HTTP, HTTPS, TCP 및 SSL 프로토콜 사용
- 각 로드밸런서에 퍼블릭 DNS 이름이 제공됨
- 기능:
- 상태 확인
- 교차 영역 로드 밸런싱
- 프록시 프로토콜
- 고정 세션: 사용자의 세션을 세션 수명 동안에 특정 인스턴스에 바인딩
- 연결 드레이닝 : 인스턴스가 등록 해지되거나 비정상이 되는 경우 새로운 요청을 백엔드 인스턴스에 전송하지 않음
- 제품 종류:
- ALB (Application Load Balancer) : 7계층에서 운영
- NLB (Network Load Balancer) : 4계층에서 운영
- CLB (Classic Load Balancer) : 4계층과 7계층 모두에서 운영, 요즘 안쓰임
2) 탄력적 IP 주소
- 고정된 퍼블릭 IP를 EC2 인스턴스에 연결
- 인스턴스가 교체되더라도 IP 주소를 유지 가능
- 고가용성 환경에서 장애 시 빠른 복구 용도로 활용
3) Route53
- AWS의 신뢰성 높은 DNS 서비스
- 도메인 이름 → IP 주소 매핑
- 이름 유래: DNS 포트 번호인 53번
10.CloudWatch
- EC2 등 AWS 리소스의 지표(Metrics), 로그, 이벤트를 실시간 모니터링
- 지정 조건에 따라 알림 전송
- Auto Scaling 트리거 가능
- 사용자 정의 지표 생성 및 CloudWatch Logs 저장
- 하이퍼바이저 수준의 기본 지표 자동 수집
11. Auto Scaling
- 조건 기반으로 EC2 인스턴스 수 자동 조절
- 과부하 시 자동으로 인스턴스 확장 / 사용량 줄면 축소
- 시작 구성:
- 시작 템플릿 → EC2 설정 정의
- Auto Scaling 그룹 → 여러 AZ에 걸쳐 확장 가능
- 로드밸런서와 연동 자동 등록
12. Lambda
- 서버 없는(Serverless) 컴퓨팅 서비스
- 코드만 업로드하고 인프라는 AWS가 관리
- 이벤트 또는 시간 기반으로 자동 실행
- 사용 사례:
- 백엔드 이벤트 핸들링
- 실시간 데이터 처리
- 파일 업로드 후 후처리 등
13. CloudFormation
- Infrastructure as Code (IaC) 도구
- 인프라 설정을 JSON 또는 YAML 템플릿으로 코드화
- 자동 생성, 배포, 변경, 삭제를 체계적으로 수행
- 용어:
- 템플릿 : 생성될 리소스를 설명하는 파일, 소스코드로 취급되어 리포지토리에 저장
- 엔진 : 템플릿을 AWS 리소스 스택을 해석
- 스택 : CloudFormation에서 생성한 리소스 모음
완성된 리소스를 역으로 CloudFormation 템플릿로 변환해주는 툴 : https://former2.com/
✍️ 하루 회고
그동안 AWS의 기본적인 서비스들만 어렴풋이 알고 있었는데, 이번 학습을 통해 각 서비스의 구조와 동작 원리에 대해 좀 더 깊이 있게 이해할 수 있었다. 물론 지금 배운 서비스들은 빙산의 일각이겠지만...
단순히 이름만 알고 있던 서비스들이 왜 필요한지, 어떻게 사용되는지를 알게 되니 훨씬 명확해졌고, 나중에 AWS SAA 자격증을 준비할 때에도 큰 도움이 될 것 같다.