AWS 101 Workshop
AWS를 처음 접하는 분들을 위한 핸즈온 워크샵입니다. 각 단계별로 필요한 기본 지식을 전문가처럼 쉽게 설명해드립니다.
워크샵 바로가기워크샵 개요
이 워크샵에서는 AWS에서 확장 가능하고 안전한 웹 애플리케이션을 실행하기 위한 기본 구성 요소를 다룹니다.
💰 예상 비용: 약 $0.44/시간 (본인 AWS 계정 사용 시)
워크샵 완료 후 반드시 리소스를 정리하여 추가 비용이 발생하지 않도록 하세요.
단계별 기본 지식
VPC (Virtual Private Cloud)
AWS 클라우드 안에 만드는 '나만의 사설 네트워크'입니다. 마치 회사 건물 안에 내부 네트워크를 구축하는 것과 같아요. 다른 AWS 사용자의 네트워크와 완전히 분리되어 있어 안전합니다.
🏢 비유: VPC는 '울타리 쳐진 나만의 땅'입니다. 이 안에서 건물(서버)을 짓고, 도로(네트워크)를 만들 수 있어요.
CIDR (사이더 블록)
IP 주소의 범위를 표현하는 방법입니다. 슬래시(/) 뒤의 숫자는 네트워크 부분의 비트 수를 의미합니다. 32비트 중 네트워크 비트를 제외한 나머지가 호스트(서버)에 할당 가능한 IP입니다.
🏠 비유: '서울시 강남구'처럼 주소의 범위를 지정하는 것입니다. /16은 '서울시' 수준(넓음), /24는 '강남구' 수준(좁음)이에요.
📊 CIDR 범위별 IP 개수: /16 = 65,536개 IP (10.0.0.0 ~ 10.0.255.255) - VPC용 권장 /20 = 4,096개 IP - 대규모 서브넷 /24 = 256개 IP (10.0.1.0 ~ 10.0.1.255) - 일반 서브넷 권장 /28 = 16개 IP - 소규모 서브넷 (최소 크기) ⚠️ AWS 예약 IP (서브넷당 5개 사용 불가): .0 - 네트워크 주소 .1 - VPC 라우터용 .2 - DNS 서버용 .3 - AWS 향후 사용 예약 .255 - 브로드캐스트 (VPC에서 미지원이지만 예약) 💡 예시: /24 서브넷은 256개 중 5개 예약 = 251개 실제 사용 가능
Subnet 유형 (Public vs Private)
서브넷 자체에 'Public/Private' 설정이 있는 것이 아닙니다. Route Table에 Internet Gateway로 가는 경로(0.0.0.0/0 → IGW)가 있으면 Public, 없으면 Private입니다.
🏗️ 비유: VPC가 '아파트 단지'라면, Subnet은 '각 동(棟)'입니다. 정문(IGW)으로 가는 길이 연결된 동이 Public이에요.
🌐 Public Subnet: - Route Table에 0.0.0.0/0 → Internet Gateway 경로 존재 - 인스턴스에 Public IP 할당 시 인터넷 직접 통신 가능 - 용도: 웹 서버, Bastion Host, NAT Gateway, ALB 🔒 Private Subnet: - Internet Gateway로 가는 직접 경로 없음 - 인터넷 아웃바운드 필요 시 NAT Gateway 사용 - 용도: DB 서버, 애플리케이션 서버, 내부 서비스 🛡️ Isolated Subnet (완전 격리): - 인터넷 연결 자체가 없음 (NAT도 없음) - 용도: 민감한 데이터 처리, 규정 준수 필요 시스템
Internet Gateway (IGW)
VPC와 인터넷을 연결하는 관문입니다. 이게 없으면 VPC 안의 서버는 인터넷과 통신할 수 없습니다. VPC당 하나만 연결 가능하며, 고가용성이 기본 제공됩니다.
🚪 비유: 아파트 단지의 '정문'입니다. 외부 손님(인터넷 트래픽)이 들어오고 나가는 유일한 통로예요.
NAT Gateway
Private Subnet의 인스턴스가 인터넷으로 나가는 것(아웃바운드)만 허용하는 게이트웨이입니다. 외부에서 들어오는 연결은 차단됩니다. 소프트웨어 업데이트 등에 필요합니다.
📤 비유: '일방통행 출구'입니다. 안에서 밖으로는 나갈 수 있지만, 밖에서 안으로는 들어올 수 없어요.
- Public Subnet에 생성해야 함 (IGW 접근 필요) - 시간당 + 데이터 처리량 기준 과금 (비용 주의!) - 고가용성 위해 AZ마다 하나씩 생성 권장
Route Table (라우팅 테이블)
네트워크 트래픽이 어디로 가야 하는지 알려주는 규칙 모음입니다. 각 서브넷은 하나의 Route Table과 연결되며, 목적지 IP에 따라 트래픽을 어디로 보낼지 결정합니다.
🗺️ 비유: 내비게이션의 경로 안내입니다. '인터넷으로 가려면 IGW로, 내부 서버로 가려면 local로'라고 알려줘요.
📋 Route Table 구성 요소: - Destination: 목적지 IP 범위 (예: 0.0.0.0/0, 10.0.0.0/16) - Target: 트래픽을 보낼 대상 (예: igw-xxx, nat-xxx, local) 🌐 Public Subnet Route Table 예시:
🔒 Public Subnet Route Table
| Destination | Target | 설명 |
|---|---|---|
| 10.0.0.0/16 | local | VPC 내부 통신 |
| 0.0.0.0/0 | igw-xxxxxxxx | 인터넷 통신 |
🔒 Private Subnet Route Table
| Destination | Target | 설명 |
|---|---|---|
| 10.0.0.0/16 | local | VPC 내부 통신 |
| 0.0.0.0/0 | nat-xxxxxxxx | 아웃바운드만 허용 |
⚡ 라우팅 우선순위: 가장 구체적인(긴 prefix) 경로가 우선 예: 10.0.1.0/24로 가는 트래픽은 10.0.0.0/16보다 우선 적용
Availability Zone (AZ)
하나의 리전 안에 있는 물리적으로 분리된 데이터센터입니다. 서울 리전에는 ap-northeast-2a, 2b, 2c, 2d 총 4개의 AZ가 있습니다. 각 AZ는 독립된 전원, 냉각, 네트워크를 갖추고 있습니다.
🏛️ 비유: 같은 도시에 있는 여러 개의 독립된 건물입니다. 한 건물에 문제가 생겨도 다른 건물은 정상 운영됩니다.
- 고가용성을 위해 최소 2개 AZ에 리소스 분산 권장 - 같은 AZ 내 통신은 무료, AZ 간 통신은 소액 과금 - 서브넷은 하나의 AZ에만 존재 (AZ 간 확장 불가)
실무 팁
- •VPC CIDR은 나중에 변경하기 어려우니 처음부터 넉넉하게 /16으로 설정하세요
- •서브넷 설계 시 향후 확장을 고려해 /24 (251개 IP)로 시작하는 것이 좋습니다
- •Public Subnet에는 웹 서버, ALB처럼 외부 접근이 필요한 리소스만 배치하세요
- •DB, 애플리케이션 서버는 Private Subnet에 배치하여 보안을 강화하세요
- •고가용성을 위해 최소 2개 이상의 AZ에 서브넷을 만드세요 (AZ 장애 대비)
- •NAT Gateway는 비용이 발생하므로 개발 환경에서는 NAT Instance 고려
Security Group (보안 그룹)
EC2 인스턴스 수준의 가상 방화벽입니다. 어떤 트래픽을 허용할지 '허용 규칙'만 정의합니다. 명시적으로 허용하지 않은 트래픽은 모두 차단됩니다.
🚨 비유: 건물 입구의 '출입 허가 명단'입니다. 명단에 있는 사람만 들어올 수 있어요.
Inbound Rules (인바운드 규칙)
외부에서 서버로 들어오는 트래픽을 제어합니다. 웹 서버라면 HTTP(80), HTTPS(443) 포트를 열어야 합니다.
📥 비유: '누가 우리 집에 방문할 수 있는가?'를 정하는 규칙입니다.
Outbound Rules (아웃바운드 규칙)
서버에서 외부로 나가는 트래픽을 제어합니다. 기본적으로 모든 아웃바운드가 허용되어 있습니다.
📤 비유: '우리가 어디로 나갈 수 있는가?'를 정하는 규칙입니다.
Stateful (상태 저장)
Security Group의 핵심 특성입니다. 인바운드로 들어온 요청의 응답은 아웃바운드 규칙과 관계없이 자동으로 허용됩니다.
🔄 비유: 손님이 문을 열고 들어왔으면, 나갈 때는 별도 허가 없이 나갈 수 있는 것과 같아요.
Port (포트)
서버에서 실행되는 서비스를 구분하는 번호입니다. HTTP는 80, HTTPS는 443, SSH는 22번 포트를 사용합니다.
🚪 비유: 건물의 '호수'입니다. 101호는 웹서비스, 102호는 SSH 서비스처럼 각 방에서 다른 서비스가 운영됩니다.
CIDR Source (소스)
트래픽을 허용할 출발지 IP 범위입니다. 0.0.0.0/0은 모든 IP를 의미하고, 특정 IP만 허용할 수도 있습니다.
📍 비유: '어디서 오는 손님을 받을 것인가?'입니다. 모든 곳(0.0.0.0/0) 또는 특정 지역만 허용할 수 있어요.
실무 팁
- •SSH(22번 포트)는 절대 0.0.0.0/0으로 열지 마세요. 본인 IP만 허용하거나 SSM을 사용하세요
- •웹 서버는 HTTP(80), HTTPS(443)만 열면 됩니다
- •Security Group은 여러 인스턴스에 재사용할 수 있으니 용도별로 만들어두세요
- •규칙 변경은 즉시 적용됩니다. 실수로 SSH를 막으면 접속이 안 될 수 있어요!
IAM (Identity and Access Management)
AWS 리소스에 대한 접근을 안전하게 제어하는 서비스입니다. '누가(Identity) 무엇을(Resource) 어떻게(Action) 할 수 있는가'를 정의합니다.
🔐 비유: 회사의 '인사팀 + 보안팀'입니다. 직원 등록, 권한 부여, 출입 관리를 담당해요.
IAM Role (역할)
AWS 서비스나 사용자가 임시로 맡을 수 있는 권한 묶음입니다. EC2 인스턴스에 Role을 부여하면 해당 인스턴스가 다른 AWS 서비스에 접근할 수 있습니다.
🎭 비유: '임시 사원증'입니다. 이 사원증을 가진 동안만 특정 구역에 출입할 수 있어요.
🎯 IAM Role의 구성 요소:
1️⃣ Trust Policy (신뢰 정책):
- 누가 이 Role을 맡을 수 있는지 정의
- EC2가 Role을 사용하려면 ec2.amazonaws.com 신뢰 필요
📌 Trust Policy 예제 (EC2용):
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
2️⃣ Permission Policy (권한 정책):
- 이 Role이 무엇을 할 수 있는지 정의
- AWS Managed 또는 Custom Policy 연결IAM Policy (정책)
어떤 작업을 허용하거나 거부하는 규칙을 JSON 형식으로 정의한 문서입니다. Effect(허용/거부), Action(작업), Resource(대상)로 구성됩니다.
📋 비유: '업무 권한 규정집'입니다. '영업팀은 고객 데이터를 읽을 수 있다' 같은 규칙이 적혀있어요.
📝 IAM Policy JSON 구조:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow | Deny",
"Action": "서비스:작업",
"Resource": "리소스 ARN"
}
]
}
🔑 주요 필드 설명:
• Version: 정책 언어 버전 (항상 2012-10-17 사용)
• Effect: Allow(허용) 또는 Deny(거부)
• Action: 허용/거부할 작업 (예: s3:GetObject)
• Resource: 대상 리소스의 ARN (* = 모든 리소스)
📌 예제 1: S3 버킷 읽기 전용
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}
]
}Instance Profile
IAM Role을 EC2 인스턴스에 연결하기 위한 컨테이너입니다. Role을 만들면 자동으로 같은 이름의 Instance Profile이 생성됩니다.
📎 비유: 사원증을 목에 거는 '목걸이 줄'입니다. Role(사원증)을 EC2(직원)에 연결해주는 역할이에요.
ARN (Amazon Resource Name)
AWS 리소스를 고유하게 식별하는 이름입니다. IAM Policy에서 어떤 리소스에 권한을 부여할지 지정할 때 사용합니다.
🏷️ 비유: 리소스의 '주민등록번호'입니다. 전 세계에서 유일하게 해당 리소스를 식별할 수 있어요.
📝 ARN 형식: arn:partition:service:region:account-id:resource-type/resource-id 📌 ARN 예시: • S3 버킷: arn:aws:s3:::my-bucket • S3 객체: arn:aws:s3:::my-bucket/folder/file.txt • EC2 인스턴스: arn:aws:ec2:ap-northeast-2:123456789012:instance/i-1234567890abcdef0 • IAM Role: arn:aws:iam::123456789012:role/MyRole • Lambda 함수: arn:aws:lambda:ap-northeast-2:123456789012:function:MyFunction 💡 와일드카드 사용: • * : 모든 것 (예: arn:aws:s3:::my-bucket/*) • ? : 단일 문자 매칭
최소 권한 원칙 (Least Privilege)
업무 수행에 필요한 최소한의 권한만 부여하는 보안 원칙입니다. 과도한 권한은 보안 사고의 원인이 됩니다.
🔑 비유: 청소 직원에게 금고 열쇠까지 줄 필요는 없죠. 필요한 방 열쇠만 주면 됩니다.
AWS Managed Policy
AWS가 미리 만들어둔 정책입니다. AmazonSSMManagedInstanceCore처럼 일반적인 사용 사례에 맞게 설계되어 있어 편리합니다.
📦 비유: '기성품 정장'입니다. 대부분의 상황에 맞게 만들어져 있어 바로 사용할 수 있어요.
📋 자주 사용하는 AWS Managed Policy:
| Policy 이름 | 용도 |
|---|---|
| AmazonSSMManagedInstanceCore | SSM Session Manager 접속 |
| AmazonS3ReadOnlyAccess | S3 읽기 전용 |
| AmazonS3FullAccess | S3 전체 권한 |
| AmazonEC2ReadOnlyAccess | EC2 읽기 전용 |
| CloudWatchAgentServerPolicy | CloudWatch 로그 전송 |
| AmazonDynamoDBReadOnlyAccess | DynamoDB 읽기 전용 |
⚠️ FullAccess 정책은 개발/테스트용으로만 사용하세요! 프로덕션에서는 최소 권한 원칙에 따라 Custom Policy 권장
실무 팁
- •EC2에서 AWS CLI를 사용하려면 반드시 IAM Role을 부여하세요. Access Key를 인스턴스에 저장하면 안 됩니다!
- •SSM으로 EC2에 접속하려면 AmazonSSMManagedInstanceCore 정책이 필요합니다
- •처음에는 AWS Managed Policy를 사용하고, 익숙해지면 Custom Policy를 만드세요
- •IAM 변경사항은 전파되는 데 몇 초 걸릴 수 있습니다
EC2 (Elastic Compute Cloud)
AWS의 가상 서버 서비스입니다. 몇 분 만에 서버를 생성하고, 필요 없으면 바로 삭제할 수 있습니다. 사용한 시간만큼만 비용을 지불합니다.
💻 비유: '렌트 컴퓨터'입니다. 필요할 때 빌리고, 안 쓰면 반납하면 돼요. 직접 서버를 사서 관리할 필요가 없습니다.
AMI (Amazon Machine Image)
EC2 인스턴스를 시작하는 데 필요한 운영체제와 소프트웨어가 포함된 템플릿입니다. Amazon Linux, Ubuntu, Windows 등 다양한 AMI가 있습니다.
💿 비유: 컴퓨터 '복원 이미지'입니다. 이 이미지로 똑같은 환경의 컴퓨터를 여러 대 만들 수 있어요.
Instance Type (인스턴스 유형)
CPU, 메모리, 스토리지, 네트워크 용량의 조합입니다. t2.micro는 1 vCPU, 1GB 메모리로 테스트용으로 적합하고 프리티어에서 무료입니다.
🚗 비유: 자동차 '모델'입니다. 경차(t2.micro)부터 트럭(r5.24xlarge)까지 용도에 맞게 선택하세요.
Key Pair (키 페어)
EC2 인스턴스에 SSH로 접속할 때 사용하는 암호화 키입니다. 공개키는 AWS에, 개인키(.pem)는 본인이 안전하게 보관해야 합니다.
🔑 비유: 집 '열쇠'입니다. 잃어버리면 집에 못 들어가요! 개인키는 절대 공유하지 마세요.
User Data
인스턴스가 처음 시작될 때 자동으로 실행되는 스크립트입니다. 웹 서버 설치, 설정 파일 생성 등 초기 설정을 자동화할 수 있습니다.
📝 비유: '입주 전 체크리스트'입니다. 새 집에 들어가면 자동으로 가구 배치, 인터넷 설치가 되는 것처럼요.
EBS (Elastic Block Store)
EC2에 연결하는 가상 하드디스크입니다. 인스턴스를 중지해도 데이터가 유지되며, 스냅샷으로 백업할 수 있습니다.
💾 비유: 컴퓨터의 'SSD/HDD'입니다. 용량을 늘리거나 다른 컴퓨터에 연결할 수도 있어요.
실무 팁
- •프리티어는 t2.micro 또는 t3.micro를 월 750시간 무료로 제공합니다
- •Key Pair는 한 번만 다운로드 가능합니다. 분실하면 인스턴스에 SSH 접속이 불가능해요
- •User Data 스크립트는 root 권한으로 실행됩니다. sudo가 필요 없어요
- •인스턴스를 Stop하면 요금이 멈추지만, EBS 비용은 계속 발생합니다
AWS Systems Manager (SSM)
AWS 인프라를 관리하기 위한 통합 서비스입니다. 서버 접속, 패치 관리, 자동화 등 다양한 기능을 제공합니다.
🎛️ 비유: 건물의 '통합 관제 센터'입니다. 모든 서버를 한 곳에서 모니터링하고 관리할 수 있어요.
Session Manager
SSM의 기능 중 하나로, SSH 키나 포트 개방 없이 브라우저에서 바로 EC2에 접속할 수 있습니다. 모든 세션이 로깅되어 감사(Audit)에도 유용합니다.
🖥️ 비유: '원격 데스크톱'입니다. 별도 프로그램 설치 없이 웹 브라우저로 서버에 접속할 수 있어요.
SSM Agent
EC2 인스턴스에 설치되어 SSM 서비스와 통신하는 에이전트입니다. Amazon Linux 2/2023에는 기본 설치되어 있습니다.
📡 비유: 서버에 설치된 '무전기'입니다. 이게 있어야 관제 센터(SSM)와 통신할 수 있어요.
IAM Role for SSM
EC2가 SSM 서비스와 통신하려면 AmazonSSMManagedInstanceCore 정책이 포함된 IAM Role이 필요합니다.
🪪 비유: '통신 허가증'입니다. 이 허가증이 있어야 관제 센터와 대화할 수 있어요.
실무 팁
- •Session Manager를 사용하면 SSH 포트(22번)를 열 필요가 없어 보안이 강화됩니다
- •모든 명령어와 출력이 CloudWatch Logs에 기록되어 감사 추적이 가능합니다
- •Private Subnet의 인스턴스도 VPC Endpoint를 통해 SSM 접속이 가능합니다
- •Session Manager는 추가 비용 없이 사용할 수 있습니다
Load Balancer (로드 밸런서)
들어오는 트래픽을 여러 서버에 분산시키는 서비스입니다. 한 서버가 다운되어도 다른 서버로 트래픽을 보내 서비스 중단을 방지합니다.
🚦 비유: 고속도로 '톨게이트'입니다. 차량(트래픽)을 여러 차선(서버)으로 분산시켜 정체를 방지해요.
ALB (Application Load Balancer)
HTTP/HTTPS 트래픽에 최적화된 로드 밸런서입니다. URL 경로, 호스트 헤더 등을 기반으로 라우팅할 수 있습니다.
🏢 비유: 건물 '안내 데스크'입니다. 방문 목적(URL)에 따라 적절한 부서(서버)로 안내해줘요.
Target Group (대상 그룹)
로드 밸런서가 트래픽을 보낼 대상(EC2 인스턴스 등)의 그룹입니다. Health Check를 통해 정상 대상에만 트래픽을 전달합니다.
👥 비유: '근무 가능한 직원 명단'입니다. 아픈 직원(비정상 서버)은 명단에서 제외되어 업무를 받지 않아요.
Health Check (상태 확인)
로드 밸런서가 주기적으로 대상 서버가 정상인지 확인하는 것입니다. 응답이 없으면 해당 서버로 트래픽을 보내지 않습니다.
🩺 비유: 정기 '건강 검진'입니다. 건강한 서버만 일을 시키고, 아픈 서버는 쉬게 해요.
Listener (리스너)
로드 밸런서가 연결 요청을 확인하는 프로세스입니다. 포트와 프로토콜을 지정하고, 어떤 Target Group으로 보낼지 규칙을 정의합니다.
👂 비유: '접수 창구'입니다. 80번 창구(HTTP)로 오면 웹팀으로, 443번 창구(HTTPS)로 오면 보안웹팀으로 안내해요.
Cross-Zone Load Balancing
여러 가용 영역(AZ)에 걸쳐 트래픽을 균등하게 분산하는 기능입니다. ALB는 기본적으로 활성화되어 있습니다.
⚖️ 비유: 여러 지점에 '균등하게 손님 배분'하는 것입니다. A지점에 손님이 몰려도 B지점으로 분산시켜요.
실무 팁
- •ALB는 최소 2개 이상의 AZ에 서브넷을 지정해야 합니다 (고가용성)
- •Health Check 경로는 실제로 200 OK를 반환하는 경로로 설정하세요
- •ALB의 DNS 이름으로 접속하세요. IP는 변경될 수 있습니다
- •HTTPS를 사용하려면 ACM(AWS Certificate Manager)에서 인증서를 발급받으세요
DNS Name (도메인 이름)
ALB는 고정 IP 대신 DNS 이름을 제공합니다. 이 DNS 이름으로 접속하면 로드 밸런서를 통해 서버에 연결됩니다.
📛 비유: 전화번호 대신 '회사 대표번호'를 사용하는 것입니다. 내부에서 알아서 담당자에게 연결해줘요.
HTTP 상태 코드
서버의 응답 상태를 나타내는 숫자입니다. 200은 성공, 404는 페이지 없음, 500은 서버 오류, 502/503은 로드밸런서가 서버에 연결 못함을 의미합니다.
🚥 비유: 신호등 색깔입니다. 초록(200)은 정상, 빨강(500)은 문제 발생이에요.
502 Bad Gateway
로드 밸런서가 백엔드 서버로부터 유효한 응답을 받지 못했을 때 발생합니다. 서버가 다운되었거나 Security Group 설정이 잘못된 경우가 많습니다.
📞 비유: 안내 데스크에서 담당 부서에 전화했는데 '연결이 안 됨' 상태입니다.
503 Service Unavailable
Target Group에 정상(Healthy) 상태인 대상이 없을 때 발생합니다. Health Check가 실패하고 있는지 확인하세요.
🏥 비유: '현재 근무 가능한 직원이 없습니다' 상태입니다. 모든 서버가 아프거나 점검 중이에요.
실무 팁
- •접속이 안 되면 순서대로 확인: Security Group → Target Group Health → 서버 상태
- •브라우저 캐시 때문에 변경사항이 안 보일 수 있어요. Ctrl+Shift+R로 강력 새로고침하세요
- •curl 명령어로 테스트하면 더 정확한 응답을 볼 수 있습니다
- •ALB DNS 전파에 1-2분 걸릴 수 있으니 조금 기다려보세요
S3 (Simple Storage Service)
AWS의 객체 스토리지 서비스입니다. 무제한에 가까운 용량, 99.999999999%(11 9's)의 내구성을 제공합니다. 파일을 '객체'라고 부릅니다.
📦 비유: 무한대 크기의 '창고'입니다. 물건(파일)을 넣고 빼기만 하면 되고, 창고 관리는 AWS가 해줘요.
Bucket (버킷)
S3에서 객체를 저장하는 컨테이너입니다. 버킷 이름은 전 세계에서 유일해야 합니다. 리전을 지정하여 생성합니다.
🗄️ 비유: 창고 안의 '보관함'입니다. 각 보관함에 이름표를 붙이고 물건을 정리해요.
Object (객체)
S3에 저장되는 기본 단위입니다. 파일 데이터와 메타데이터로 구성됩니다. 최대 5TB까지 저장 가능합니다.
📄 비유: 보관함에 넣는 '물건'입니다. 파일 자체와 함께 라벨(메타데이터)도 붙어있어요.
Key (키)
버킷 내에서 객체를 식별하는 고유한 이름입니다. 폴더처럼 보이지만 실제로는 '/'가 포함된 긴 이름일 뿐입니다.
🏷️ 비유: 물건의 '위치 태그'입니다. images/photo.jpg는 실제 폴더가 아니라 그냥 긴 이름이에요.
Bucket Policy
버킷 수준에서 접근 권한을 제어하는 JSON 정책입니다. 누가 어떤 작업을 할 수 있는지 정의합니다.
📋 비유: 보관함의 '출입 규칙'입니다. 누가 열어볼 수 있고, 누가 물건을 넣을 수 있는지 정해요.
Storage Class (스토리지 클래스)
데이터 접근 빈도에 따른 저장 옵션입니다. Standard(자주 접근), Glacier(아카이브) 등이 있으며 비용이 다릅니다.
🏠 비유: '창고 위치'입니다. 자주 쓰는 물건은 가까운 창고(비쌈), 안 쓰는 물건은 먼 창고(저렴)에 보관해요.
실무 팁
- •버킷 이름은 한번 정하면 변경 불가능합니다. 신중하게 정하세요
- •퍼블릭 접근은 기본적으로 차단되어 있습니다. 필요한 경우에만 열어주세요
- •정적 웹사이트 호스팅 기능으로 S3만으로 웹사이트를 운영할 수 있습니다
- •대용량 파일은 Multipart Upload를 사용하면 빠르고 안정적입니다
Auto Scaling Group (ASG)
EC2 인스턴스의 모음을 자동으로 관리하는 서비스입니다. 최소/최대/원하는 인스턴스 수를 설정하면 자동으로 유지합니다.
👥 비유: '자동 인력 관리 시스템'입니다. 바쁘면 직원을 더 뽑고, 한가하면 줄여요. 항상 적정 인원을 유지합니다.
Launch Template
새 인스턴스를 시작할 때 사용할 설정을 미리 정의한 템플릿입니다. AMI, 인스턴스 타입, 보안 그룹, User Data 등을 포함합니다.
📋 비유: '신입 직원 온보딩 체크리스트'입니다. 새 직원(인스턴스)이 오면 이 체크리스트대로 세팅해요.
Desired Capacity (원하는 용량)
ASG가 유지하려는 인스턴스 수입니다. 인스턴스가 종료되면 자동으로 새 인스턴스를 시작하여 이 수를 유지합니다.
🎯 비유: '목표 직원 수'입니다. 항상 이 인원을 유지하려고 해요. 누가 퇴사하면 바로 충원합니다.
Scaling Policy (스케일링 정책)
언제, 얼마나 스케일링할지 정의하는 규칙입니다. CPU 사용률이 70% 넘으면 인스턴스 2개 추가 같은 조건을 설정합니다.
📊 비유: '인력 충원 기준'입니다. 업무량(CPU)이 많아지면 자동으로 인원을 늘리는 규칙이에요.
Target Tracking Scaling
목표 지표(예: CPU 50%)를 설정하면 ASG가 자동으로 인스턴스 수를 조절하여 해당 목표를 유지합니다.
🌡️ 비유: 에어컨의 '자동 온도 조절'입니다. 25도로 설정하면 알아서 냉방/난방을 조절해요.
Cooldown Period (쿨다운 기간)
스케일링 활동 후 다음 스케일링까지 대기하는 시간입니다. 너무 빈번한 스케일링을 방지합니다.
⏰ 비유: '의사결정 대기 시간'입니다. 직원을 뽑은 직후에는 잠시 상황을 지켜보고 추가 채용을 결정해요.
Health Check
ASG가 인스턴스 상태를 확인하는 방법입니다. EC2 상태 확인 또는 ELB 상태 확인을 사용할 수 있습니다.
🩺 비유: '직원 건강 검진'입니다. 아픈 직원(비정상 인스턴스)은 퇴사시키고 새 직원으로 교체해요.
실무 팁
- •Launch Template은 버전 관리가 되므로 변경사항을 추적할 수 있습니다
- •최소 2개 이상의 AZ에 인스턴스를 분산하여 고가용성을 확보하세요
- •스케일 아웃(확장)은 빠르게, 스케일 인(축소)은 천천히 설정하는 것이 안전합니다
- •ALB와 함께 사용하면 새 인스턴스가 자동으로 Target Group에 등록됩니다
- •비용 절감을 위해 스팟 인스턴스를 혼합 사용할 수도 있습니다
템플릿에 포함된 리소스:
- • VPC + Subnets (2 AZ)
- • Internet Gateway
- • Route Tables
- • Security Groups
- • IAM Role (SSM 접속용)
- • Application Load Balancer
- • Auto Scaling Group
- • S3 Bucket
# AWS CLI로 스택 생성:
aws cloudformation create-stack \ --stack-name aws101-workshop \ --template-body file://aws-101-workshop.yaml \ --capabilities CAPABILITY_NAMED_IAM워크샵 완료 후 생성한 리소스를 삭제하지 않으면 계속 비용이 발생합니다. 다음 순서로 삭제하세요:
- Auto Scaling Group 삭제
- Load Balancer 삭제
- Target Group 삭제
- EC2 인스턴스 종료
- S3 버킷 비우기 후 삭제
- NAT Gateway 삭제 (있는 경우)
- VPC 삭제 (연결된 리소스 자동 삭제)