AWS 기초 개념

클라우드 컴퓨팅이란

회사에 서버가 필요하면 어떻게 했을까요? 서버를 구매하고, 전용 공간을 만들고, 전원·냉각·네트워크를 설치하고, 운영팀이 24시간 관리해야 했습니다. 초기 비용이 크고, 트래픽이 갑자기 늘어나면 대응이 늦습니다.

클라우드 컴퓨팅은 이 서버를 인터넷으로 빌려 쓰는 방식입니다. 필요할 때 켜고, 안 쓸 때 끄고, 사용한 만큼만 냅니다. 전기처럼요.

클라우드 서비스 모델 — IaaS·PaaS·SaaS

클라우드는 어디까지 관리해주느냐에 따라 세 가지로 나뉩니다.

AWS의 대부분 서비스는 IaaS입니다. EC2는 가상 서버를 빌려주지만 그 위에 무엇을 설치하고 어떻게 운영할지는 내가 결정합니다. 반면 Lambda는 코드만 올리면 실행해주는 PaaS에 가깝습니다.

온프레미스 vs 클라우드

가상화 — EC2가 만들어지는 원리

AWS에서 EC2 인스턴스를 생성하면 수십 초 안에 서버가 생깁니다. 물리 서버를 주문한 게 아닌데 어떻게 가능할까요?

가상화(Virtualization)는 물리 서버 하나를 여러 개의 독립된 가상 서버로 나누는 기술입니다. 하이퍼바이저(Hypervisor)라는 소프트웨어가 물리 자원(CPU, 메모리, 디스크)을 나눠서 각 가상 머신에 할당합니다.

AWS는 자체 개발한 Nitro System을 하이퍼바이저로 사용합니다. EC2 인스턴스는 서로 완전히 격리돼 있어서, 같은 물리 서버에 있는 다른 고객의 인스턴스에 접근할 수 없습니다.

AWS 구조 — 리전·가용 영역·엣지

AWS는 전 세계에 물리적 인프라를 분산해서 운영합니다. 이 구조를 이해하면 "왜 서울 리전에서 만든 EC2가 도쿄 콘솔에서 안 보이는지"가 바로 이해됩니다.

리전 (Region)

리전은 지리적으로 독립된 AWS 인프라 집합입니다. 서울(ap-northeast-2), 도쿄(ap-northeast-1), 버지니아(us-east-1) 등 전 세계 30개 이상의 리전이 있습니다.

리전은 완전히 독립적입니다. 서울에서 만든 EC2는 도쿄 콘솔에서 보이지 않습니다. 콘솔 우측 상단 리전 드롭다운이 잘못 선택돼 있으면 "분명히 만들었는데 없다"는 상황이 생깁니다. 실수의 90%가 여기서 납니다.

가용 영역 (Availability Zone, AZ)

리전 안에는 물리적으로 분리된 데이터센터 그룹이 있습니다. 서울 리전에는 2a·2b·2c·2d 네 개의 AZ가 있습니다. 각 AZ는 서로 수십 km 떨어져 있고, 독립된 전원·냉각·네트워크를 갖습니다.

RDS에서 "다중 AZ: 아니요"를 선택했던 이유가 이겁니다. 다중 AZ는 장애 복구에는 좋지만 인스턴스가 두 배라 요금도 두 배입니다.

엣지 로케이션 (Edge Location)

CloudFront가 사용하는 캐시 서버 위치입니다. 리전보다 훨씬 많아서(200개 이상), 사용자와 지리적으로 가까운 곳에서 정적 파일을 제공합니다. 서울에 있는 사용자가 미국 서버의 파일을 요청해도, 서울 엣지 로케이션에 캐시가 있으면 거기서 바로 받습니다.

AWS 계정과 프리 티어

AWS 계정은 모든 리소스와 청구의 단위입니다. 하나의 계정 안에 여러 리전, 여러 서비스, 여러 사용자(IAM)가 있을 수 있습니다.

프리 티어 세 종류

공동 책임 모델 (Shared Responsibility Model)

AWS와 고객은 보안 책임을 나눠서 집니다. 이걸 모르면 "AWS가 다 알아서 해주겠지"라는 착각을 하게 됩니다.

IAM — 누가 무엇을 할 수 있는가

IAM(Identity and Access Management)은 AWS 리소스에 대한 접근 권한을 제어하는 서비스입니다. "이 사람은 EC2를 볼 수만 있고 생성은 못 한다", "이 프로그램은 S3에 파일을 올릴 수 있다" 같은 규칙을 정합니다.

IAM 구성 요소

IAM 정책 구조

정책은 JSON 형식으로 작성합니다. 실제로 작성할 일은 많지 않지만, 읽을 수는 있어야 합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",          // 허용 (또는 Deny)
      "Action": "s3:GetObject",   // 어떤 작업을
      "Resource": "arn:aws:s3:::my-bucket/*"  // 어디에
    }
  ]
}

IAM 역할 (Role) — EC2에 S3 접근 권한 주기

EC2에서 S3에 파일을 올리려면 권한이 필요합니다. 방법이 두 가지입니다.

임시 자격증명 — 액세스 키보다 안전한 이유

IAM 역할이 부여되면 AWS는 EC2에 임시 자격증명(Temporary Credentials)을 자동으로 발급합니다. 이 자격증명은 만료 시간이 있고(보통 1시간), 자동으로 갱신됩니다.

Spring Boot에서 AWS SDK를 쓸 때 별도로 액세스 키를 설정하지 않아도 S3나 RDS에 접근할 수 있는 이유가 여기 있습니다. SDK가 EC2의 메타데이터 서버에서 임시 자격증명을 자동으로 가져옵니다.

AWS CLI에서의 인증 체계

SDK와 CLI는 다음 순서로 자격증명을 찾습니다:

1. 환경변수 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
2. ~/.aws/credentials 파일
3. EC2 인스턴스 메타데이터 서버 (IAM 역할)
4. ECS 태스크 역할, Lambda 실행 역할

로컬 개발 환경에서는 1~2번, EC2 프로덕션 환경에서는 3번을 쓰는 게 일반적입니다. 키를 application.yml에 하드코딩하는 건 절대 안 됩니다.

핵심 정리