테마
14. AWS 입문 핵심 로드맵
원본 강의 전사는 AWS를 처음 접하는 사람에게 필요한 서비스를 넓게 훑는다. 이 문서는 그 흐름을 유지하되, 콘솔 UI나 오래된 실습 방식에 묶이지 않도록 2026년 기준의 개념과 보안 원칙으로 다시 정리한다.
먼저 잡아야 할 큰 그림
AWS는 "인터넷으로 빌려 쓰는 컴퓨터와 운영 도구"에 가깝다. 서버, 디스크, 데이터베이스, 네트워크, 권한, 배포 도구를 직접 구매하고 설치하는 대신 필요한 만큼 생성하고, 사용량에 따라 비용을 낸다.
처음에는 서비스 이름을 모두 외우려 하지 말고, 각 서비스가 어떤 질문에 답하는지만 잡으면 된다.
| 질문 | 대표 서비스 |
|---|---|
| 서버를 어디서 실행할까? | EC2, Lambda, ECS |
| 파일은 어디에 저장할까? | S3, EBS, EFS |
| 데이터베이스는 어떻게 운영할까? | RDS, DynamoDB |
| 사용자를 어떻게 보내고 보호할까? | Route 53, CloudFront, ELB, VPC, Security Group |
| 누가 무엇을 할 수 있게 할까? | IAM |
| 문제가 생겼는지 어떻게 알까? | CloudWatch, CloudTrail |
| 코드를 어떻게 배포할까? | CodePipeline, CodeBuild, CodeDeploy, GitHub Actions |
2026년 기준으로 고쳐 이해할 점
| 오래된 설명 | 지금은 이렇게 이해하기 |
|---|---|
| Free Tier는 가입 후 12개월 무료 | 2025년 7월 15일 이후 생성 계정은 Free plan / Paid plan을 고르고, 기본 크레딧과 6개월 Free plan 조건을 함께 본다. 이전 계정은 기존 12개월 Free Tier가 적용된다. |
EC2 Free Tier는 t2.micro만 | 계정 생성일에 따라 다르다. 2025년 7월 15일 이후 계정은 t3.micro, t3.small, t4g.micro, t4g.small, c7i-flex.large, m7i-flex.large 등이 Free Tier eligible로 표시될 수 있다. 콘솔의 "Free tier eligible" 표시를 확인한다. |
| 루트 유저로 시작해서 IAM User를 만든다 | 루트 유저는 MFA 설정과 긴급 작업에만 쓰고, 사람은 IAM Identity Center 또는 역할 기반 임시 자격 증명으로 접근하는 것이 기본이다. |
| 액세스 키와 비밀 키를 만들어 CLI/API를 쓴다 | 장기 Access Key는 예외로 둔다. 로컬 실습은 SSO/Identity Center, 워크로드는 IAM Role, CI/CD는 OIDC 기반 Role 연합을 우선한다. |
| EC2 구매 옵션은 On-Demand, Reserved, Spot 세 가지 | Savings Plans, Capacity Reservations, Dedicated Hosts/Instances, GPU용 Capacity Blocks까지 함께 봐야 한다. 비용 절감은 보통 Savings Plans가 더 유연하다. |
EBS 기본 범용 볼륨은 gp2 | gp3가 최신 범용 SSD이며 대부분의 새 워크로드에서 우선 검토한다. standard Magnetic은 이전 세대 볼륨이다. |
| S3 단일 객체는 최대 5TB | 현재 문서 기준 멀티파트 업로드로 최대 50TB 객체까지 다룰 수 있다. 단일 PUT은 5GB, 콘솔 업로드는 160GB 한도가 따로 있다. |
| S3 정적 사이트는 퍼블릭 버킷으로 열면 된다 | 학습용 데모 외에는 S3를 비공개로 두고 CloudFront Origin Access Control(OAC)로 CloudFront만 접근하게 하는 구성이 기본이다. OAI는 기존 방식으로 이해하면 된다. |
| CodeCommit은 신규 고객에게 제한될 수 있다 | 2025년 11월 25일 문서 기준 CodeCommit은 다시 신규 고객에게 제공된다. 다만 실무 CI/CD는 GitHub/GitLab과 AWS OIDC 연동을 함께 고려한다. |
1. 계정, 비용, 루트 유저
AWS 계정을 만들면 루트 유저가 생긴다. 루트 유저는 계정의 모든 권한을 가진 최고 관리자이므로 일상 작업에 쓰면 안 된다.
처음 해야 할 일은 세 가지다.
- 루트 유저 MFA를 켠다. 가능하면 패스키나 보안 키처럼 피싱에 강한 MFA를 사용한다.
- Billing 대시보드와 AWS Budgets에서 비용 알림을 만든다.
- 사람용 접근은 IAM Identity Center 또는 최소 권한 Role/User로 분리한다.
Free Tier는 "무조건 공짜"가 아니다. 계정 생성일, 선택한 플랜, 서비스별 한도, 리전, 데이터 전송량에 따라 과금될 수 있다. 실습 후에는 EC2, RDS, NAT Gateway, Load Balancer, EIP, EBS 볼륨, S3 버킷을 반드시 확인한다.
2. IAM: 권한은 사용자보다 역할 중심으로 본다
IAM은 AWS에서 "누가 무엇을 할 수 있는가"를 정하는 서비스다.
| 개념 | 초심자용 설명 | 실무 감각 |
|---|---|---|
| User | 특정 사람이나 장기 자격 증명 | 가능하면 줄이고, 필요한 경우 MFA와 최소 권한 적용 |
| Group | 여러 User에 같은 권한 적용 | 레거시/소규모 계정에서 사용 |
| Role | 누군가 잠시 맡는 권한 묶음 | EC2, Lambda, ECS, GitHub Actions의 기본 방식 |
| Policy | 허용/거부 규칙을 담은 JSON 문서 | 처음엔 AWS 관리형 정책, 운영 전에는 최소 권한으로 축소 |
| Trust Policy | 누가 Role을 맡을 수 있는지 | Role 설계에서 Permission Policy만큼 중요 |
강의 원문처럼 DynamoDB 읽기 권한만 주는 예시는 IAM을 이해하기 좋다. 다만 새 실습에서는 "사용자에게 장기 액세스 키를 발급한다"보다 "역할을 만들고 필요한 서비스가 그 역할을 맡게 한다"는 흐름으로 바꾸는 편이 안전하다.
권한이 헷갈릴 때는 IAM Policy Simulator와 IAM Access Analyzer를 함께 쓴다. Simulator는 특정 작업이 허용되는지 확인하고, Access Analyzer는 과하게 열린 정책이나 실제 사용 기록 기반 최소 권한 정책을 점검하는 데 유용하다.
3. EC2와 EBS: 서버와 디스크를 나눠서 본다
EC2는 가상 서버이고, EBS는 EC2에 붙이는 블록 스토리지다. 일반 PC로 비유하면 EC2는 본체, EBS는 SSD/HDD에 해당한다.
| 구성 요소 | 역할 |
|---|---|
| AMI | OS와 기본 소프트웨어가 들어 있는 이미지 |
| Instance Type | CPU, 메모리, 네트워크 성능 조합 |
| EBS Volume | 영구 디스크 |
| Security Group | 인스턴스 앞의 상태 저장 방화벽 |
| Key Pair / Session Manager | 리눅스 SSH, 윈도우 RDP, 또는 에이전트 기반 접속 |
EC2 비용 옵션은 워크로드의 예측 가능성과 중단 가능성으로 고른다.
| 옵션 | 적합한 상황 |
|---|---|
| On-Demand | 짧은 실습, 예측이 어려운 개발/테스트 |
| Savings Plans | 일정한 컴퓨팅 사용량이 있고 유연성이 필요할 때 |
| Reserved Instances | 특정 인스턴스 구성/리전이 장기간 고정될 때 |
| Spot Instances | 중단되어도 재시도 가능한 배치, 분석, CI 작업 |
| Capacity Reservations | 특정 AZ에 반드시 용량을 확보해야 할 때 |
EBS는 새로 시작한다면 gp3를 먼저 검토한다. io2는 높은 IOPS와 낮은 지연이 필요한 데이터베이스에, st1/sc1은 큰 순차 I/O와 저비용 저장에 맞는다. standard Magnetic은 이전 세대이므로 새 설계의 기본 선택지가 아니다.
4. 네트워크, DNS, 로드 밸런싱
EC2 하나를 만들면 끝나는 것처럼 보이지만, 운영에서는 네트워크 경계가 더 중요하다.
| 개념 | 핵심 |
|---|---|
| Region | 어느 지리적 위치에 리소스를 둘지 |
| AZ | 리전 안에서 물리적으로 분리된 데이터센터 묶음 |
| VPC | AWS 안의 내 전용 네트워크 |
| Subnet | VPC를 더 작게 나눈 구간 |
| Security Group | 인스턴스/ENI 단위 방화벽 |
| ELB/ALB | 여러 서버로 트래픽 분산 |
| Route 53 | 도메인 이름을 AWS 리소스에 연결 |
처음 실습은 Public Subnet의 EC2에 HTTP를 열어 웹 서버를 확인해도 된다. 하지만 운영 구조는 보통 ALB만 공개하고, 애플리케이션 서버와 DB는 Private Subnet에 둔다.
5. S3와 CloudFront: 파일 저장과 전송을 분리한다
S3는 객체 스토리지다. 폴더처럼 보이는 구조도 실제로는 객체 키의 접두사(prefix)다.
| S3 개념 | 설명 |
|---|---|
| Bucket | 객체를 담는 최상위 컨테이너. 이름은 전 세계적으로 고유해야 한다. |
| Object | 실제 파일 데이터와 메타데이터 |
| Key | 객체 이름 또는 경로처럼 보이는 식별자 |
| Version ID | 버전 관리 활성화 시 객체 버전을 구분하는 값 |
| Storage Class | 접근 빈도와 복구 시간에 따라 고르는 저장 등급 |
CloudFront는 S3, EC2, ALB 같은 오리진 앞에 두는 CDN이다. 사용자는 가까운 엣지 로케이션에서 캐시된 콘텐츠를 받으므로 지연 시간이 줄어든다.
정적 사이트 실습에서는 퍼블릭 S3 버킷이 쉬워 보이지만, 현재 기준의 안전한 기본값은 다음과 같다.
- S3 버킷은 Block Public Access를 유지한다.
- CloudFront Distribution을 만든다.
- OAC를 설정해 CloudFront가 서명된 요청으로만 S3에 접근하게 한다.
- 사용자에게는 CloudFront 도메인 또는 Route 53 도메인만 공개한다.
6. RDS와 DynamoDB: 관계형과 NoSQL을 구분한다
RDS는 MySQL, PostgreSQL 같은 관계형 데이터베이스를 관리형으로 제공한다. 서버 패치, 백업, 장애 조치 일부를 AWS가 맡아준다.
| 기능 | 의미 |
|---|---|
| Automated Backup | 지정 기간 안에서 시점 복원 가능 |
| Multi-AZ | 장애 시 다른 AZ의 대기 인스턴스로 전환 |
| Read Replica | 읽기 부하 분산 |
| Parameter Group | DB 엔진 설정 묶음 |
DynamoDB는 서버리스 NoSQL 데이터베이스다. 테이블, 항목(Item), 속성(Attribute), 파티션 키를 중심으로 설계한다.
| DynamoDB 작업 | 감각 |
|---|---|
| Query | 키 조건을 사용해 필요한 범위만 조회. 우선 선택 |
| Scan | 테이블 전체를 훑음. 작은 실습 외에는 주의 |
| GSI | 다른 접근 패턴을 위한 보조 인덱스 |
| Stream | 변경 이벤트를 Lambda 등으로 전달 |
| DAX | 읽기 캐시가 필요한 경우 선택 |
7. Lambda, API Gateway, CloudWatch
Lambda는 이벤트가 발생했을 때 코드를 실행하는 서버리스 컴퓨팅이다. 서버를 직접 관리하지 않지만, 실행 시간, 메모리, 패키지 크기, 동시성, 네트워크 연결 같은 제한은 반드시 고려해야 한다. 기본 타임아웃은 짧고, 최대 타임아웃은 15분이다.
API Gateway는 외부 HTTP 요청을 Lambda, EC2, VPC Link 등 백엔드로 연결한다. 초심자 실습에서는 "POST 요청 -> Lambda 실행 -> DynamoDB 저장" 흐름이 가장 이해하기 쉽다.
CloudWatch는 로그, 지표, 알람을 모으는 관측 도구다.
| CloudWatch 기능 | 사용 예 |
|---|---|
| Logs | Lambda 실행 로그, 애플리케이션 로그 |
| Metrics | EC2 CPU, ALB 요청 수, DynamoDB 소비량 |
| Alarms | 임계값 초과 시 SNS 알림 |
| Dashboard | 여러 지표를 한 화면에 배치 |
8. CI/CD: AWS 도구와 GitHub를 함께 본다
원본 강의는 CodeCommit, CodeDeploy, CodePipeline 흐름을 다룬다. 개념 학습에는 여전히 좋다.
| 서비스 | 역할 |
|---|---|
| CodeCommit | AWS 관리형 Git 저장소 |
| CodeBuild | 빌드와 테스트 실행 |
| CodeDeploy | EC2, Lambda, 온프레미스 등에 배포 |
| CodePipeline | 소스, 빌드, 배포 단계를 파이프라인으로 연결 |
다만 현재 실무에서는 GitHub/GitLab을 소스 저장소로 쓰고, AWS에는 OIDC로 임시 권한을 받아 배포하는 흐름도 흔하다. 따라서 학습 순서는 이렇게 잡으면 좋다.
- CodePipeline으로 CI/CD 단계의 큰 그림을 이해한다.
- CodeDeploy의 in-place, rolling, blue/green 배포 차이를 익힌다.
- GitHub Actions + AWS OIDC로 장기 Access Key 없는 배포를 구성한다.
- ECS/Fargate 또는 Lambda 배포로 서버 관리 부담을 줄이는 방향을 검토한다.
실습 체크리스트
- [ ] AWS 계정 생성 후 루트 유저 MFA, 비용 알림, Budgets를 설정한다.
- [ ] IAM Identity Center 또는 최소 권한 Role/User로 일상 작업 계정을 분리한다.
- [ ] EC2 Free Tier eligible 인스턴스를 생성하고, Security Group에서 SSH는 내 IP로만 제한한다.
- [ ] Amazon Linux 2023 또는 Ubuntu AMI로 웹 서버를 띄우고, 종료 후 EBS/EIP까지 정리한다.
- [ ] S3 버킷을 만들고 객체 키, 메타데이터, 버전 관리, 스토리지 클래스를 확인한다.
- [ ] S3를 퍼블릭으로 열지 않고 CloudFront OAC로 정적 콘텐츠를 배포한다.
- [ ] RDS MySQL/PostgreSQL을 만들고 EC2 또는 로컬 클라이언트에서 보안 그룹을 통해 접속한다.
- [ ] DynamoDB 테이블을 만들고
Query와Scan의 차이를 체감한다. - [ ] S3 업로드 또는 API Gateway 요청으로 Lambda를 실행하고 CloudWatch Logs를 확인한다.
- [ ] CodePipeline/CodeDeploy 또는 GitHub Actions OIDC로 간단한 배포 파이프라인을 구성한다.
이 프로젝트에서 이어서 읽을 문서
| 더 알고 싶은 것 | 이어서 읽기 |
|---|---|
| 클라우드와 AWS 큰 그림 | 00. 클라우드 컴퓨팅과 AWS 개요 |
| 가상 서버와 디스크 | 01. EC2 |
| 객체 스토리지 | 02. S3 |
| 관계형 데이터베이스 | 04. RDS |
| NoSQL과 권한 | 05. DynamoDB와 IAM |
| CDN과 모니터링 | 06. CloudFront와 CloudWatch |
| 로드 밸런싱과 확장 | 07. ELB, 08. Auto Scaling |
| VPC/IAM 운영 관점 | 12. AWS 네트워킹과 보안 |
| 컨테이너 배포 | 13. Docker와 ECS Fargate 배포 |
출처와 검증 기준
- 원문 자료:
ing-0020-aws-입문.md - AWS 공식 문서: IAM 보안 모범 사례, AWS Free Tier, EC2 구매 옵션, EBS 볼륨 유형, S3 객체 업로드, CloudFront OAC, Lambda 타임아웃, CodeCommit 문서 이력
- Context7 AWS 문서 스니펫과 Claude 검토를 함께 사용해 오래된 설명을 현대 기준으로 재정리했다.