전 포스팅에서는 AWS SAA-C03을 공부할 때 [문제 상황 조합으로 정답 매핑하기] 를 꿀팁으로 알고 가라고 했다.
➡️ https://rb-cloud.tistory.com/29
이번에는 AWS SAA-C03을 공부할 때 꼭 알고 가야하는 기초 지식을 알아보았다!
어떤 서비스를 쓰든 이 개념들은 배경지식이라고 한다.
- Region/AZ
- IAM
- VPC
- 보안그룹/NACL
- Auto Scaling
- ELB
- Route 53
- CloudFront
- CloudWatch
1. Region과 Availability Zone (AZ)
AWS는 전 세계에 인프라를 분산해서 운영한다.
리전(Region)은 지리적으로 독립된 AWS 데이터센터 묶음이다. 예를 들어 ap-northeast-2는 서울 리전이다.
AZ는 한 리전 안에 있는 독립된 데이터센터다. 서울 리전에는 AZ가 4개 있다.
AWS Global
└ 도쿄 Region
└ 버지니아 Region
└ 서울 Region
├ AZ (ap-northeast-2a)
├ AZ (ap-northeast-2b)
├ AZ (ap-northeast-2c)
└ AZ (ap-northeast-2d)
한 AZ에 장애가 생겨도 다른 AZ에서 서비스가 유지되는 것을 고가용성(High Availability)이라 한다.
"고가용성을 갖춰야 한다" → 여러 AZ에 분산 배포 해야한다.
2. IAM (Identity and Access Management)
IAM은 누가 무엇을 할 수 있는지 정의하는 서비스다.
IAM
├ User → 실제 사람 또는 애플리케이션
├ Group → User의 모음
├ Role → AWS 서비스나 외부 계정에 권한 부여
└ Policy → JSON으로 작성된 권한 정의서
Policy는 어떤 액션을 허용하거나 거부하는지 JSON으로 작성된 규칙이다.
{
# 권한을 허용
"Effect": "Allow",
# 수행 가능한 작업은 s3:파일 조회
"Action": "s3:GetObject",
# 대상 리소스는 my-bucket 안의 모든 객체*
"Resource": "arn:aws:s3:::my-bucket/*"
}
이 Policy를 User, Group, Role에 붙이면 해당 권한이 부여된다.
Role은 언제 쓸까?
User는 사람이 로그인해서 쓰는 계정이다.
그런데 AWS 서비스가 다른 AWS 서비스에 접근해야 할 때는 User를 쓸 수 없다.
이럴 때 Role을 만들어서 서비스에 붙여준다.
예를 들어, EC2 안에서 돌아가는 애플리케이션이 S3에서 파일을 읽어야 한다고 치자.
이때 Access Key를 EC2 코드 안에 직접 넣는 방식은 보안상 위험하다.
키가 노출되면 누구든 S3에 접급할 수 있게 된다.
대신 "S3 읽기 권한"이 담긴 IAM Role을 만들어서 EC2에 붙이면 EC2가 자동으로 그 권한으로 S3에 접근한다. 키를 심을 필요가 없다.
3. VPC (Virtual Private Cloud)
VPC는 AWS 안에 나만의 가상 네트워크를 만드는 것이다.
VPC (10.0.0.0/16)
├ Public Subnet (10.0.1.0/24)
│ └ EC2 ← 인터넷 통신 가능
│ ↑
│ Internet Gateway
│
└ Private Subnet (10.0.1.0/24)
└ RDS ← 인터넷 직접 접근 불가
- Public Subnet: Internet Gateway와 연결. 인터넷 통신 가능
- Private Subnet: 인터넷과 직접 연결되지 않음. 보통 DB를 여기 넣음
Private Subnet의 EC2가 인터넷에 나가야 한다 → NAT Gateway 사용
NAT Gateway는 Public Subnet에 배치한다.
4. 보안그룹 vs NACL
VPC
└ NACL (서브넷 단위 방화벽)
└ Subnet
└ 보안그룹 (인스턴스 단위 방화벽)
└ EC2
보안그룹(Security Group)
- EC2 인스턴스 단위 적용
- Stateful: 인바운드 허용 시 아웃바운드 응답 자동 허용
- 허용 규칙만 작성 가능 (거부규칙 없음)
NACL (Network ACL)
- 서브넷 단위 적용
- Stateless: 인바운드, 아웃바운드 각각 따로 허용해야 함
- 허용 + 거부 규칙 모두 작성 가능
- 규칙 번호 순서대로 평가 (낮은 번호 먼저)
특정 IP를 차단해야 한다 → NACL (보안그룹은 거부 규칙이 없다)
5. Auto Scaling
Auto Scaling은 트래픽에 따라 EC2 인스턴스 수를 자동으로 조절하는 서비스다.
Auto Scaling Group (ASG)
├ 최소 인스턴스 수 (Minimum)
├ 최대 인스턴스 수 (Maximum)
└ 원하는 인스턴스 수 (Desired)
스케일링 정책 종류
- 단순 스케일링 (Simple): CloudWatch 알람 하나에 반응해서 고정 수만큼 추가/제거. 가장 기본적
- 단계 스케일링 (Step): 알람 수치에 따라 단계별로 다르게 반응. GPU 50% → 2대 추가, GPU 80% → 5대 추가
- 대상 추적 스케일링 (Target Tracking): 특정 지표를 목표값으로 유지
예) CPU 사용률을 50%로 유지. 가장 많이 사용 - 예약 스케일링 (Scheduled): 특정 시간에 미리 스케일링
예) 매일 오전 9시에 인스턴스 5대로 증가
"트래픽 패턴이 예측 가능하다" → 예약 스케일링
"CPU 사용률을 일정하게 유지하고 싶다" → 대상 추적 스케일링
스케일링 쿨다운 (Cooldown)
스케일링 후 일정 시간 동안 추가 스케일링을 하지 않는 대기 시간이다.
인스턴스가 올라오는 시간 동안 중복으로 스케일링 되는 것을 막기 위해 존재한다.
6. ELB (Elastic Load Balancer)
ELB는 트래픽을 여러 인스턴스에 자동으로 분산시켜주는 서비스다.
Auto Scaling과 항상 세트로 쓴다.
사용자 요청
↓
ELB
├ EC2 (AZ-a)
├ EC2 (AZ-b)
├ EC2 (AZ-c)
ELB 종류
- ALB (Application Load Balancer)
- L7 계층
- HTTP/HTTPS
- URL 경로
- 헤더 기반 라우팅 가능
- NLB (Network Load Balancer)
- L4 계층
- TCP/UDP
- 매우 낮은 레이턴시
- 고정 IP 가능
- GLB (Gateway Load Balancer)
- 방화벽
- 보안 어플라이언스 앞단에 배치
URL 경로 기반 라우팅 → ALB
고정 IP가 필요하다 → NLB
고성능, 낮은 레이턴시 → NLB
7. Route 53
Route53은 AWS의 DNS 서비스다.
도메인 이름을 실제 서버 주소(IP)로 변환해주는 역할을 한다.
사용자가 www.example.com 입력
↓
Route 53
↓
실제 서버 IP로 연결 (EC2, ELB, CloudFront)
라우팅 정책 종류
- 단순 (Simple): 도메인 → 하나의 IP, 기본 값
- 가중치 기반 (Weighted): 여러 서버에 비율로 트래픽 분산
예) A 서버 70%, B 서버 30% - 지연 기반 (Latency): 사용자와 가장 가까운(레이턴시 낮은) 리전으로 연결
- 장애 조치 (Failover): Primary 서버 장애 시 Sencondary로 자동 전환
- 지리적 (Geolocation): 사용자 위치 기반으로 특정 리전으로 연결
"한국 사용자는 서울 리전으로, 미국 사용자는 버지니아 리전으로 연결하고 싶다" → 지리적 라우팅
"Primary 서버 다운 시 자동으로 백업 서버로 전환해야 한다" → 장애 조치 라우팅
"신버전을 일부 사용자에게만 먼저 배포하고 싶다" → 가중치 기반 라우팅
헬스 체크 (Health Check)
Route 53은 서버 상태를 주기적으로 확인하는 헬스 체크 기능을 제공한다.
장애 조치 라우팅과 함께 써서, 서버가 다운되면 자동으로 다른 서버로 전환된다.
8. CloudFront
CloudFront는 AWS의 CDN(Content Delivery Network) 서비스다.
전 세계 엣지 로케이션에 콘텐츠를 캐싱해서 사용자와 가까운 곳에서 빠르게 응답한다.
오리진 서버 (S3, EC2, ELB)
↓ 최초 요청 시 캐싱
CloudFront 엣지 로케이션
(전 세계 400개 이상)
↓
사용자
오리진 종류
- S3 버킷: 정적 파일(이미지, HTML, JS) 배포에 적합
- EC2 / ELB: 동적 콘텐츠도 캐싱 가능
- 커스텀 오리진: 온프레미스 서버도 오리진으로 설정 가능
CloudFront + S3 조합
정적 웹사이트 배포에서 가장 자주 나오는 구성이다.
S3 버킷 (정적 파일 저장)
↓
CloudFront (전 세계 캐싱 + HTTPS)
↓
사용자 (가장 가까운 엣지에서 응답)
S3에 직접 접근하면 속도가 느리고 비용도 비쌀 수 있다.
CloudFront를 앞에 두면 캐싱으로 속도 개선 + 비용 절감 두 가지 모두 해결된다.
OAC (Origin Access Control)
CloudFront를 통해서만 S3에 접근하도록 제한하는 설정이다.
S3 버킷을 퍼블릭으로 열지 않아도 Cloud Front를 통해 파일을 제공할 수 있다.
"S3를 외부에 직접 노출하지 않고 CloudFront를 통해서만 접근하게 하고 싶다" → OAC 설정
9. CloudWatch
CloudWatch는 AWS 리소스와 애플리케이션을 모니터링하는 서비스다.
거의 모든 AWS 서비스와 연계되기 때문에 기반 지식으로 알고 있어야 한다.
CloudWatch
├ Metrics → CPU, 메모리, 네트워크 등 수치 데이터 수집
├ Logs → 애플리케이션 로그 수집 및 저장
├ Alarms → 지표가 임계값 초과 시 알림 or 자동 행동
└ Events → 특정 이벤트 발생 시 Lambda 실행 등 자동화
Metrics (지표)
AWS 서비스가 자동으로 CloudWatch에 지표를 보낸다.
- EC2: CPU 사용률, 네트워크 in/out, 디스크 I/O
- RDS: DB 연결 수, 읽기/쓰기 레이턴시
- ELB: 요청 수, 응답 시간, 에러율
단, EC2 메모리 사용률은 기본 제공되지 않는다. CloudWatch Agent를 직접 설치해야 수집할 수 있다.
Alarms (알람)
지표가 특정 임계값을 넘으면 행동을 취하도록 설정한다.
CPU 사용률 > 80%가 5분간 지속
↓
CloudWatch Alarm
↓
Auto Scaling → 인스턴스 추가
SNS → 담당자에게 이메일 발송
Auto Scaling과 CloudWatch는 항상 세트다.
스케일링 정책이 동작하려면 CloudWatch Alarm이 기준이 된다.
Logs (로그)
애플리케이션 로그를 CloudWatch Logs에 수집해서 분석할 수 있다.
Lambda, EC2, ECS 등 대부분의 서비스 로그가 여기에 모인다.
핵심 정리
- Region/AZ
- 지리적 단위
- 다중 AZ = 고가용성
- IAM
- 접근 제어
- 서비스 간 접근엔 Role 사용
- VPC
- 가상 네트워크
- Public/Private Subnet + NAT gateway
- 보안그룹 vs NACL
- Stateful vs Stateless
- IP 차단은 NACL
- Auto Scaling
- 트래픽에 따라 인스턴스 수 자동 조절
- 정책 종류 구분 필수
- ELB
- 트래픽 분산
- ALB(L7) vs NLB(L4)
- Route 53
- DNS
- 라우팅 정책 종류(가중치/지연/장애 조치/지리적) 구분
- CloudFront
- CDN
- S3 앞에 붙여서 속도 개선 + 비용 절감
- CloudWatch
- 모니터링
- Metrics/Logs/Alarms
- Auto Scaling과 항상 세트
'자격증 따기 > AWS-SAA C03' 카테고리의 다른 글
| [AWS SAA-C03] 2단원 Storage (0) | 2026.03.25 |
|---|---|
| [AWS SAA-C03] 단원별 예제 풀이 (0) | 2026.03.24 |
| [AWS SAA-C03] 1단원 Compute & Container & Serverless (0) | 2026.03.24 |
| [AWS-SAA03 공부법] 알아야 할 서비스 (0) | 2026.03.24 |
| AWS SAA-C03 공부법 [문제 상황 조합으로 정답 매핑하기 1] (2) | 2026.02.20 |