AWS

별빛사막·2025년 3월 13일

목록 보기

1/3

1. AWS와 테라폼

AWS : AWS(Amazon Web Services)는 아마존에서 제공하는 클라우드 컴퓨팅 서비스
테라폼 : HashiCorp에서 개발한 인프라스트럭처를 코드로 관리하는 오픈소스 도구
→ Terraform의 선언적 구성(Declarative Configuration) 문법을 사용하여 클라우드 리소스를 생성, 관리, 업데이트할 수 있다

// AWS 프로바이더 선언
provider "aws" {
  region = var.region
}

✔️ provider "aws" → AWS를 사용하겠다는 선언
✔️ region = var.region → AWS 리전(예: us-east-1, ap-northeast-2)을 변수로 설정
✔️ 이 코드는 Terraform이 AWS 인프라를 관리하는 데 필요한 기본 설정을 정의하는 부분

✅ EC2 100개 생성 방식 비교: AWS 콘솔 vs Terraform**

비교 항목	AWS 콘솔 (수동 방식)	Terraform (자동화 방식)
설정 방식	웹 UI에서 수동으로 EC2를 하나씩 생성	코드로 선언한 후 한 번에 생성
자동화 수준	❌ 없음 (완전 수동)	✅ 코드 실행 한 번으로 자동 생성
EC2 100개 생성 시간	⏳ 오래 걸림 (각 인스턴스마다 클릭 필요)	🚀 빠름 (한 번의 `terraform apply`로 생성)
오류 가능성	❌ 사람의 실수 가능 (설정 누락, 옵션 잘못 선택)	✅ 일정한 설정 유지 (인프라 일관성 보장)
유지보수	❌ 불편 (100개 수정 시 하나씩 변경 필요)	✅ 편리 (코드 수정 후 `terraform apply` 실행)
대량 배포 가능 여부	❌ 어려움 (수작업으로 많은 인스턴스 생성 비효율적)	✅ 쉬움 (변수 설정으로 여러 개 자동 생성)
재현 가능성	❌ 동일한 환경을 다시 만들기 어려움	✅ 코드 기반으로 동일한 인프라 재현 가능
삭제 및 정리	❌ 하나씩 삭제해야 함	✅ `terraform destroy` 한 번으로 모든 EC2 삭제 가능
버전 관리	❌ 설정 변경 내역 추적 어려움	✅ 코드 기반으로 Git 등 버전 관리 가능

결론

✔ AWS 콘솔: 클릭 몇 번으로 간단하게 EC2를 생성할 수 있지만, 100개를 만들려면 매우 비효율적이고 실수 가능성이 큼
✔ Terraform: 선언형 코드로 EC2를 자동화하여 빠르고 일관되게 배포할 수 있으며 유지보수도 훨씬 편리함

즉, 대량의 EC2 인스턴스를 생성하려면 Terraform을 사용하는 것이 훨씬 효율적이고 안정적이다!

2. 루트 계정과 AWS IAM

2-1. 관계

루트 계정: 최상위 관리자 계정. 해킹 시 심각한 보안 위험 발생 가능
IAM 계정 : 보안 강화를 위해 루트 계정의 직접 사용을 피하고, 필요한 권한만 부여하여 관리할 수 있도록 하기 위해 생성한다

ex. admin(사용자)에게 AdministratorAccess 정책 부여

이때, 역할에 부여하는 정책은 하나가 아니라 여러 권한을 모아놓은 묶음이다!!
즉, 정책(policy) = 권한 묶음

2-2. 로그인 방법

루트 계정 로그인 : 루트계정 + 비밀번호
IAM 계정 로그인 : 루트계정 ID or 루트 계정 별칭 IAM계정이름 + 비밀번호

루트계정 ID는 어려우니까 루트 계정 별칭을 만들어주고 사용하는게 좋다

2-3. AWS IAM

AWS IAM에서 권한을 부여할 수 있는 대상은 크게 사용자(User), 그룹(Group), 역할(Role) 3가지이다.
역할(Role)에 권한을 부여한다는 의미 = 특정 AWS 리소스나 외부 사용자가 임시로 사용할 수 있는 권한을 부여한다는 의미
IAM은 글로벌 서비스로 특정 리전에 귀속되지 않는다.

🤷‍♀️why? AWS 계정(Account) 단위로 역할(Role)을 생성하고 부여하는 방식이기 때문에
만약 IAM이 특정 리전에 귀속된다면, 각 리전에 대해 동일한 IAM 역할을 중복으로 설정해야 하는 불편함이 생긴다.

3. 여러 용어 설명

리전 : 하나 이상의 데이터센터가 모여 하나의 가용영역을 형성하는데, 하나의 리전에는 2개 이상의 가용영역(AZ)으로 구성되어 있다. 가용영역은 물리적으로 떨어져있다.
VPC((Virtual Private Cloud)) : AWS 클라우드 내 가상 네트워크

✅ CIDR 블록(서브넷) 비교: /16 vs /24

CIDR 블록	네트워크에서 관리하는 IP 개수	서브넷 마스크	사용 가능한 IP 대역	설명
10.0.0.0/16	`65,536개` (`256 * 256`)	`255.255.0.0` (`/16`)	`10.0.0.0 ~ 10.0.255.255`	뒤의 `16비트(8*2)`를 사용 가능 → 뒤의 2자리
10.0.0.0/24	`256개` (`256`)	`255.255.255.0` (`/24`)	`10.0.0.0 ~ 10.0.0.255`	뒤의 `8비트(8*1)`만 사용 가능 → 뒤의 1자리

🔹 비트 표현

1) 10.0.0.0/16

11111111 11111111 00000000 00000000
(앞의 16비트는 고정, 뒤의 16비트(8*2) 사용 가능) → IP 대역: 10.0.0.0 ~ 10.0.255.255

2) 10.0.0.0/24

11111111 11111111 11111111 00000000 → IP 대역: 10.0.0.0 ~ 10.0.0.255
(앞의 24비트는 고정, 뒤의 8비트(8*1) 사용 가능)

서브넷 : VPC에 속해있는 하위 네트워크
라우팅 테이블: 네트워크 패킷이 어디로 가야 하는지 결정하는 지도 같은 역할
인터넷 게이트웨이: 퍼블릭 서브넷에서 인터넷과 통신할 때 사용, 이때 게이트웨이 자체는 아무 역할도 하지 않음. 라우팅 테이블에 연결되어야 인터넷 연결이 가능함
보안그룹 : EC2 인스턴스에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 가상 방화벽

4. 테라폼 프로젝트

terraform.tfstate, terraform.tfstate.backup 파일에는 민감한 정보(AWS RDS 비밀번호 등)들이 포함되어 있을 수 있어 리포지토리를 private로 관리해야한다.

✅ 퍼블릭 서브넷을 만들 때 필요한 구성

VPC 생성
서브넷 생성 (퍼블릭 서브넷)
인터넷 게이트웨이 생성 및 연결
라우팅 테이블 생성 및 IGW로 경로 추가
퍼블릭 서브넷에 라우팅 테이블 연결
EC2 인스턴스에 퍼블릭 IP 할당

             ┌──────────────────────────────────────────────┐
             │              (dev-vpc-1)                 │
             │ CIDR: 10.0.0.0/16                        │
             │                                          │
             │  ┌───────────────────────────────────────┐   │
             │  │   Internet Gateway (dev-igw-1)        │
             │  └────────────────────────────────────────┘  │
             │         │                                 │
             │         ▼                                 │
             │  ┌────────────────────────────────────────┐  │
             │  │   Route Table (dev-rt-1)               │
             │  │   0.0.0.0/0 → IGW                      │
             │  └────────────────────────────────────────┘  │
             │         │            │            │       │
             │         ▼            ▼            ▼       │
             │   ┌──────────┐  ┌──────────┐  ┌──────────┐  │
             │   │ Subnet-1 │  │ Subnet-2 │  │ Subnet-3 │
             │   │ 10.0.1.0 │  │ 10.0.2.0 │  │ 10.0.3.0 │  
             │   └────▲─────┘  └────▲─────┘  └────▲─────┘  │
             │        │            │            │       │
             │   ┌────┴─────┐  ┌────┴─────┐  ┌────┴─────┐  │
             │   │  EC2-1   │  │  EC2-2   │  │  EC2-3   │
             │   │ (Public) │  │ (Public) │  │ (Public) │
             │   └──────────┘  └──────────┘  └──────────┘  │
             └──────────────────────────────────────────────┘

테라폼 명령어

terraform init  : 라이브러리 다운로드
terraform plan : 현재 소스 코드가 실행가능한지 검사
terraform apply : 리소스 생성
terraform destory : 리로스 삭제

→ "terraform apply와 terraform destroy 명령어를 사용하면 AWS 콘솔에서 직접 클릭하며 리소스를 생성하거나 삭제할 필요가 없다."

5. IAM - IAM 인스턴스 프로파일 - EC2 인스턴스 연결

AWS 개념	비유적인 표현	설명
IAM Role (IAM 역할)	비행기 운항 매뉴얼	EC2가 수행할 수 있는 권한과 정책을 정의함. 하지만 EC2가 직접 적용할 수 없음.
IAM Instance Profile (IAM 인스턴스 프로파일)	관제탑	IAM 역할과 EC2를 연결하는 중간 다리 역할. EC2가 IAM 역할을 사용할 수 있도록 전달함.
EC2 Instance (EC2 서버)	비행기	IAM 역할을 직접 이해할 수 없고, 인스턴스 프로파일을 통해 매뉴얼을 적용받아 AWS 서비스를 사용함.

IAM 역할은 EC2에 직접 연결될 수 없고, IAM 인스턴스 프로파일을 통해 연결됨.
IAM 인스턴스 프로파일은 하나의 IAM 역할만 포함 가능 → 1:1 관계
→ 하나의 인스턴스에 여러 개의 IAM 역할을 부여하면 역할 간의 정책 충돌이 발생할 가능성이 높음.

ex. IAM 역할 A: S3 읽기만 허용 / IAM 역할 B: S3 전체 접근 허용
EC2 인스턴스가 두 역할을 모두 가지면, 어떤 정책이 적용될지 모호해짐.

IAM 인스턴스 프로파일은 여러 EC2 인스턴스에 적용 가능 → 1:N 관계

별빛사막

조금씩 매일 성장하자

다음 포스트

AWS

aws