AWS 콘솔과 리전 완벽 가이드

AWS를 처음 시작하는 개발자를 위한 관리 콘솔 사용법과 리전 개념 완벽 정리. 실무에서 꼭 알아야 할 리전 선택 기준과 글로벌 서비스 이해까지 한 번에 마스터하세요.

1. AWS 관리 콘솔 둘러보기

어느 날 신입 개발자 김클라우드 씨는 첫 AWS 계정을 받았습니다. 로그인 후 화면을 보니 수많은 메뉴와 서비스들이 눈앞에 펼쳐졌습니다.

"대체 어디서부터 시작해야 하지?" 막막함이 밀려왔습니다.

AWS 관리 콘솔은 웹 브라우저에서 AWS의 모든 서비스를 관리할 수 있는 통합 관리 도구입니다. 마치 스마트폰의 설정 앱처럼, 하나의 화면에서 모든 클라우드 자원을 제어할 수 있습니다.

처음에는 복잡해 보이지만, 구조를 이해하면 매우 직관적으로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// AWS SDK를 통한 프로그래밍 방식 접근도 가능합니다
const AWS = require('aws-sdk');

// AWS 자격증명 설정
AWS.config.update({
  region: 'ap-northeast-2',
  accessKeyId: process.env.AWS_ACCESS_KEY,
  secretAccessKey: process.env.AWS_SECRET_KEY
});

// EC2 서비스 객체 생성
const ec2 = new AWS.EC2();

// 인스턴스 목록 조회 - 콘솔에서 보는 것과 동일한 정보
ec2.describeInstances({}, (err, data) => {
  if (err) console.error(err);
  else console.log('인스턴스 목록:', data.Reservations);
});

김클라우드 씨는 입사 첫날 AWS 계정을 받았습니다. 선배 개발자 이클라우드 씨가 옆에 앉아 친절하게 설명해줍니다.

"걱정하지 마세요. 처음엔 다들 그래요.

하나씩 천천히 알아가면 됩니다." AWS 관리 콘솔이란 정확히 무엇일까요? 쉽게 비유하자면, AWS 관리 콘솔은 마치 거대한 쇼핑몰의 안내 데스크와 같습니다.

쇼핑몰에 수백 개의 매장이 있듯이, AWS에는 200개가 넘는 서비스가 있습니다. 안내 데스크에서 원하는 매장 위치를 검색하고 찾아가듯, 콘솔에서 필요한 서비스를 검색하고 접근할 수 있습니다.

로그인하면 가장 먼저 보이는 화면이 홈 대시보드입니다. 화면 최상단에는 검색창이 있습니다.

이것이 가장 중요한 기능입니다. 서비스 이름을 입력하면 즉시 해당 서비스로 이동할 수 있습니다.

예를 들어 "EC2"라고 입력하면 가상 서버 관리 화면으로, "S3"라고 입력하면 파일 저장소로 바로 이동합니다. 왼쪽 상단에는 서비스 메뉴가 있습니다.

이 메뉴를 클릭하면 모든 AWS 서비스가 카테고리별로 정리되어 나타납니다. 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 등 용도별로 분류되어 있어서 어떤 서비스가 어디에 속하는지 이해하기 쉽습니다.

오른쪽 상단을 보면 중요한 요소들이 있습니다. 먼저 리전 선택 메뉴가 보입니다.

현재 "서울"이라고 표시되어 있다면, 지금 서울 리전에서 작업하고 있다는 뜻입니다. 이 부분은 매우 중요해서 나중에 자세히 다루겠습니다.

그 옆에는 계정 이름과 알림 아이콘이 있습니다. 중앙 화면에는 최근 방문한 서비스가 표시됩니다.

자주 사용하는 서비스는 이 영역에 자동으로 나타나서, 매번 검색하지 않아도 빠르게 접근할 수 있습니다. 마치 웹 브라우저의 즐겨찾기와 비슷한 개념입니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 개발자는 하루에도 수십 번 콘솔에 접속합니다.

서버 상태를 확인하고, 로그를 살펴보고, 새로운 리소스를 생성합니다. 처음에는 마우스로 클릭하며 찾아다니지만, 익숙해지면 검색창만 사용해서 몇 초 만에 원하는 곳으로 이동합니다.

이클라우드 씨가 실전 팁을 알려줍니다. "검색창에 서비스 이름 전체를 입력할 필요 없어요.

'ec2'만 입력해도 되고, 심지어 'e'만 입력해도 EC2가 추천 목록에 나타납니다. 그리고 콘솔 화면은 여러 탭으로 열어두고 작업하면 편해요." 또 하나 중요한 점이 있습니다.

콘솔 언어 설정을 확인하세요. 하단에서 한국어나 영어를 선택할 수 있습니다.

하지만 실무에서는 영어로 사용하는 것을 추천합니다. 공식 문서나 에러 메시지가 모두 영어로 되어 있어서, 영어 용어에 익숙해지는 것이 장기적으로 도움이 됩니다.

김클라우드 씨는 이클라우드 씨의 설명을 들으며 고개를 끄덕였습니다. "생각보다 어렵지 않네요.

검색창만 잘 사용하면 되는군요!" AWS 관리 콘솔은 클라우드 여행의 시작점입니다. 이 도구를 자유자재로 다룰 수 있다면, AWS의 강력한 기능들을 마음껏 활용할 수 있습니다.

실전 팁

💡 - 검색창 단축키는 Alt+S (Windows) 또는 Option+S (Mac)입니다

자주 사용하는 서비스는 상단의 별표 아이콘을 눌러 즐겨찾기에 추가하세요
모바일 앱 "AWS Console"을 설치하면 스마트폰에서도 리소스를 모니터링할 수 있습니다

2. 서비스 검색과 즐겨찾기

김클라우드 씨는 매일 아침 출근하면 EC2, RDS, S3를 차례로 확인합니다. 처음에는 서비스 메뉴를 열어서 하나씩 찾아갔는데, 하루에도 수십 번 반복하다 보니 너무 번거로웠습니다.

"더 빠른 방법은 없을까?"

AWS 콘솔의 검색 기능과 즐겨찾기 시스템은 200개가 넘는 서비스 중에서 필요한 것을 빠르게 찾아주는 핵심 도구입니다. 마치 도서관에서 책을 찾을 때 사서에게 물어보는 것처럼, 검색창에 서비스명만 입력하면 즉시 이동할 수 있습니다.

자주 쓰는 서비스는 즐겨찾기로 등록하면 더욱 효율적입니다.

다음 코드를 살펴봅시다.

// AWS CLI를 통한 서비스 검색 및 리소스 조회
const { exec } = require('child_process');

// AWS CLI로 특정 서비스의 리소스 검색
function searchAWSResource(serviceName, resourceType) {
  // 예: EC2 인스턴스 검색
  const command = `aws ${serviceName} describe-${resourceType}`;

  exec(command, (error, stdout, stderr) => {
    if (error) {
      console.error(`검색 실패: ${error.message}`);
      return;
    }
    // JSON 형태로 결과 반환
    const resources = JSON.parse(stdout);
    console.log(`${serviceName} ${resourceType} 목록:`, resources);
  });
}

// 실제 사용 예시
searchAWSResource('ec2', 'instances');
searchAWSResource('s3', 'buckets');

김클라우드 씨는 매일 같은 작업을 반복하면서 불편함을 느꼈습니다. 이클라우드 씨가 그 모습을 보고 다가왔습니다.

"아직도 메뉴에서 찾아가요? 검색창을 활용하면 훨씬 빠릅니다." 검색창의 진정한 힘은 무엇일까요?

쉽게 비유하자면, AWS 검색창은 마치 스마트폰의 앱 검색과 같습니다. 홈 화면을 이리저리 넘기며 앱을 찾는 대신, 검색창에 앱 이름 몇 글자만 입력하면 바로 찾아집니다.

AWS도 마찬가지입니다. 메뉴를 펼치고 카테고리를 찾아 헤매는 대신, 검색창에 서비스명만 입력하면 됩니다.

검색창 사용법은 생각보다 훨씬 유연합니다. 예를 들어 EC2로 가고 싶다면 "ec2"라고 전체를 입력할 필요가 없습니다.

"e"만 입력해도 EC2가 상위에 표시됩니다. "s3"를 찾는다면 "s"만 입력해도 됩니다.

심지어 한글로 "가상서버"라고 입력해도 EC2를 찾아줍니다. 더 강력한 기능도 있습니다.

검색창은 서비스뿐만 아니라 리소스도 찾아줍니다. 예를 들어 특정 EC2 인스턴스의 ID를 검색하면, 해당 인스턴스의 상세 페이지로 바로 이동합니다.

S3 버킷 이름을 입력하면 그 버킷으로 직접 들어갑니다. 이제 즐겨찾기 기능을 알아보겠습니다.

화면 왼쪽을 보면 별표 아이콘이 있습니다. 자주 사용하는 서비스 페이지에서 이 별표를 클릭하면 즐겨찾기에 추가됩니다.

그러면 왼쪽 사이드바에 즐겨찾기 목록이 생기고, 클릭 한 번으로 바로 이동할 수 있습니다. 실제 현업 개발자들의 즐겨찾기 목록을 보면 패턴이 있습니다.

대부분 EC2, RDS, S3, CloudWatch를 즐겨찾기에 넣어둡니다. 이 네 가지가 가장 자주 사용하는 서비스이기 때문입니다.

여기에 Lambda나 DynamoDB처럼 프로젝트에서 쓰는 서비스를 추가합니다. 이클라우드 씨가 자신의 화면을 보여줍니다.

"제 즐겨찾기를 보세요. EC2, RDS, S3, CloudWatch, IAM, CloudFormation 이렇게 6개만 등록해뒀어요.

이것만으로도 일상 업무의 95퍼센트를 처리합니다. 나머지 서비스는 필요할 때만 검색해서 찾아가면 되니까요." 검색창에는 숨겨진 팁도 있습니다.

검색 결과에서 최근 방문한 항목이 우선적으로 표시됩니다. 만약 어제 특정 EC2 인스턴스를 봤다면, 다음날 "ec2"를 검색했을 때 그 인스턴스가 상위에 나타납니다.

AWS가 사용자의 작업 패턴을 학습하는 것입니다. 키보드 단축키를 활용하면 더욱 빨라집니다.

Windows에서는 Alt+S, Mac에서는 Option+S를 누르면 검색창으로 바로 이동합니다. 마우스로 클릭할 필요가 없습니다.

익숙해지면 검색창 단축키를 누르고, 서비스명 두세 글자를 입력하고, 엔터를 치는 것이 3초 안에 끝납니다. 김클라우드 씨는 이클라우드 씨의 작업 속도에 감탄했습니다.

"와, 정말 빠르네요! 저는 계속 마우스로 클릭해서 찾아갔는데, 이렇게 하니까 시간이 엄청 절약되네요." 이클라우드 씨가 웃으며 답합니다.

"처음에는 익숙하지 않겠지만, 일주일만 연습하면 자연스럽게 몸에 배게 될 거예요." 주의할 점도 있습니다. 즐겨찾기를 너무 많이 등록하면 오히려 복잡해집니다.

정말 자주 쓰는 서비스 5~8개 정도만 등록하는 것이 좋습니다. 그 이상은 검색창으로 찾는 것이 더 빠릅니다.

결국 효율적인 AWS 작업의 핵심은 검색입니다. 메뉴 구조를 외우려고 하지 말고, 검색에 익숙해지세요.

그것이 진짜 고수가 되는 첫걸음입니다.

실전 팁

💡 - 검색창 단축키 Alt+S (Win) 또는 Option+S (Mac)을 꼭 익히세요

즐겨찾기는 5~8개만 유지하는 것이 가장 효율적입니다
리소스 ID나 이름으로도 검색이 가능하니 적극 활용하세요

3. 리전 Region 이란

어느 날 김클라우드 씨는 어제 생성한 EC2 인스턴스가 보이지 않아 당황했습니다. 분명히 만들었는데 목록에 없습니다.

이클라우드 씨가 화면 오른쪽 상단을 가리킵니다. "리전이 '서울'이 아니라 '버지니아'로 되어 있네요.

리전을 바꿔보세요."

**리전(Region)**은 AWS가 전 세계에 운영하는 물리적인 데이터센터 집합을 의미합니다. 마치 대형 마트가 여러 지역에 지점을 두는 것처럼, AWS도 서울, 도쿄, 싱가포르, 버지니아 등 전 세계 30개 이상의 지역에 독립적인 인프라를 구축해두었습니다.

각 리전은 완전히 분리되어 있어서, 서울 리전에서 만든 서버는 도쿄 리전에서 보이지 않습니다.

다음 코드를 살펴봅시다.

// Node.js에서 특정 리전의 AWS 서비스 사용하기
const AWS = require('aws-sdk');

// 서울 리전(ap-northeast-2)에서 EC2 인스턴스 조회
const ec2Seoul = new AWS.EC2({ region: 'ap-northeast-2' });

ec2Seoul.describeInstances({}, (err, data) => {
  if (err) console.error('서울 리전 에러:', err);
  else console.log('서울 리전 인스턴스:', data.Reservations.length);
});

// 도쿄 리전(ap-northeast-1)에서 EC2 인스턴스 조회
const ec2Tokyo = new AWS.EC2({ region: 'ap-northeast-1' });

ec2Tokyo.describeInstances({}, (err, data) => {
  if (err) console.error('도쿄 리전 에러:', err);
  else console.log('도쿄 리전 인스턴스:', data.Reservations.length);
});

김클라우드 씨는 당황했습니다. 분명히 어제 EC2 인스턴스를 생성했는데, 오늘 보니 목록이 비어 있습니다.

"혹시 삭제된 건가?" 불안한 마음에 이클라우드 씨를 불렀습니다. 이클라우드 씨는 화면을 보자마자 원인을 알았습니다.

"화면 오른쪽 상단을 보세요. 지금 '버지니아 북부' 리전으로 되어 있죠?

어제는 아마 '서울' 리전에서 작업했을 거예요. 리전을 바꿔보세요." 김클라우드 씨가 리전을 '서울'로 변경하자, 사라졌던 인스턴스가 다시 나타났습니다.

리전이란 정확히 무엇일까요? 쉽게 비유하자면, 리전은 마치 은행의 지점과 같습니다.

신한은행 강남지점에서 계좌를 만들었다면, 그 계좌 정보는 강남지점 시스템에 저장됩니다. 분당지점 ATM에 가면 그 계좌를 볼 수 있지만, 그것은 본사 시스템을 통해 연결되어 있기 때문입니다.

하지만 AWS 리전은 그렇지 않습니다. 각 리전은 완전히 독립적입니다.

AWS는 왜 리전을 나누어 운영할까요? 첫 번째 이유는 지연시간 때문입니다.

한국에 있는 사용자가 미국 서버에 접속하면 데이터가 태평양을 건너야 합니다. 빛의 속도로도 최소 100밀리초 이상 걸립니다.

하지만 서울 리전의 서버라면 10밀리초 안에 응답합니다. 이 차이가 사용자 경험을 좌우합니다.

두 번째 이유는 법규 준수입니다. 많은 나라에서 개인정보는 반드시 자국 내에 저장하도록 법으로 규정합니다.

한국 사용자의 데이터를 한국 내 데이터센터에 보관해야 하는 것입니다. 리전 단위로 분리되어 있으면 이런 규정을 쉽게 만족시킬 수 있습니다.

세 번째 이유는 재해 대비입니다. 만약 전 세계 AWS가 하나의 거대한 데이터센터로 운영된다면, 그곳에 문제가 생기면 전 세계 서비스가 모두 멈춥니다.

하지만 리전이 분리되어 있으면, 한 리전에 문제가 생겨도 다른 리전은 정상 작동합니다. 현재 AWS는 전 세계에 30개 이상의 리전을 운영합니다.

한국에는 **서울 리전(ap-northeast-2)**이 있습니다. 이것이 한국 개발자들이 가장 많이 사용하는 리전입니다.

일본에는 도쿄와 오사카 리전이, 싱가포르에는 싱가포르 리전이 있습니다. 미국에는 버지니아, 오하이오, 캘리포니아 등 여러 리전이 있습니다.

각 리전의 코드명을 이해하면 도움이 됩니다. ap-northeast-2를 예로 들어보겠습니다.

"ap"는 Asia Pacific(아시아 태평양)을 의미합니다. "northeast"는 북동쪽, 즉 한국과 일본 지역입니다.

"2"는 이 지역의 두 번째 리전이라는 뜻입니다. 참고로 ap-northeast-1은 도쿄 리전입니다.

실제 현업에서는 어떻게 활용할까요? 대부분의 한국 서비스는 서울 리전을 기본으로 사용합니다.

하지만 글로벌 서비스라면 여러 리전을 동시에 사용합니다. 예를 들어 한국 사용자를 위해서는 서울 리전에, 일본 사용자를 위해서는 도쿄 리전에, 미국 사용자를 위해서는 버지니아 리전에 서버를 구축합니다.

주의할 점이 있습니다. 리전을 잘못 선택하면 나중에 바꾸기 매우 어렵습니다.

EC2 인스턴스를 버지니아에서 만들었다가 서울로 옮기려면, 단순히 이동시킬 수 없습니다. 백업을 만들고, 서울 리전에서 새로 생성하고, 데이터를 복사하는 복잡한 과정을 거쳐야 합니다.

또 하나 중요한 점이 있습니다. 리전마다 가격이 다릅니다.

같은 사양의 EC2 인스턴스라도 서울 리전이 버지니아 리전보다 약간 비쌉니다. 또한 모든 리전에서 모든 서비스가 제공되는 것은 아닙니다.

최신 서비스는 보통 버지니아 리전에 먼저 출시되고, 몇 개월 후 다른 리전으로 확대됩니다. 김클라우드 씨는 이제 리전의 중요성을 깨달았습니다.

"앞으로는 작업 시작 전에 항상 리전부터 확인해야겠어요." 이클라우드 씨가 고개를 끄덕입니다. "맞아요.

리전 확인은 AWS 작업의 기본 중의 기본입니다." 리전은 AWS 인프라의 가장 큰 단위입니다. 이것을 이해하지 못하면, 김클라우드 씨처럼 리소스를 찾지 못해 헤매게 됩니다.

항상 화면 오른쪽 상단의 리전 표시를 확인하는 습관을 들이세요.

실전 팁

💡 - 작업 시작 전 항상 오른쪽 상단의 리전을 먼저 확인하세요

한국 서비스라면 기본적으로 ap-northeast-2(서울)를 사용합니다
리전 간 데이터 전송에는 추가 비용이 발생하니 주의하세요

4. 가용 영역 AZ 개념

김클라우드 씨는 EC2 인스턴스를 생성하다가 "가용 영역"이라는 항목을 발견했습니다. "ap-northeast-2a", "ap-northeast-2c" 같은 선택지가 나타났습니다.

"리전도 선택했는데, 가용 영역은 또 뭐지?" 궁금증이 생겼습니다.

**가용 영역(Availability Zone, AZ)**은 하나의 리전 내에서 물리적으로 분리된 데이터센터 집합을 의미합니다. 마치 한 도시 안에 여러 개의 전력 공급소가 분산되어 있는 것처럼, 서울 리전 안에도 여러 개의 독립적인 데이터센터가 있습니다.

한 가용 영역에 장애가 발생해도 다른 가용 영역은 정상 작동하도록 설계되어 있습니다.

다음 코드를 살펴봅시다.

// Node.js에서 특정 리전의 모든 가용 영역 조회하기
const AWS = require('aws-sdk');

// 서울 리전의 EC2 객체 생성
const ec2 = new AWS.EC2({ region: 'ap-northeast-2' });

// 해당 리전의 모든 가용 영역 조회
ec2.describeAvailabilityZones({}, (err, data) => {
  if (err) {
    console.error('가용 영역 조회 실패:', err);
  } else {
    console.log('서울 리전의 가용 영역 목록:');
    data.AvailabilityZones.forEach(az => {
      console.log(`- ${az.ZoneName}: ${az.State}`);
      // 출력 예: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d
    });
  }
});

김클라우드 씨는 EC2 생성 화면을 보며 고개를 갸우뚱했습니다. 이클라우드 씨가 그 모습을 보고 설명해줍니다.

"가용 영역은 리전보다 더 작은 단위예요. 조금 복잡해 보이지만, 개념만 이해하면 쉽습니다." 가용 영역을 쉽게 이해해봅시다.

서울 리전을 하나의 큰 건물로 비유해보겠습니다. 이 건물 안에는 여러 개의 층이 있고, 각 층은 독립적인 전력과 네트워크를 갖추고 있습니다.

한 층에 화재가 나도 다른 층은 안전합니다. 각 층이 바로 가용 영역입니다.

같은 건물 안에 있지만, 서로 격리되어 있습니다. 서울 리전에는 몇 개의 가용 영역이 있을까요?

현재 서울 리전에는 4개의 가용 영역이 있습니다. ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d입니다.

각각이 독립적인 데이터센터이며, 서로 수 킬로미터 떨어져 있습니다. 가까우면서도 분리되어 있는 것입니다.

왜 이렇게 설계했을까요? 첫 번째 이유는 장애 대응입니다.

한 데이터센터에 정전이 발생하거나, 네트워크 장비가 고장 나거나, 심지어 자연재해가 발생해도 다른 가용 영역은 영향을 받지 않습니다. 실제로 2021년 미국 버지니아 리전에서 한 가용 영역에 정전이 발생했지만, 다른 가용 영역은 정상 작동했습니다.

두 번째 이유는 고가용성 구성입니다. 실무에서는 중요한 서비스를 구축할 때 반드시 여러 가용 영역에 분산 배치합니다.

예를 들어 웹 서버를 2a와 2c에 하나씩 두 대를 띄웁니다. 한 대가 다운되어도 다른 한 대가 서비스를 계속합니다.

사용자는 장애를 눈치채지 못합니다. 가용 영역 간에는 어떻게 통신할까요?

같은 리전 내의 가용 영역들은 고속 네트워크로 연결되어 있습니다. 지연시간이 매우 짧아서, 1밀리초 이내에 데이터가 전송됩니다.

따라서 서로 다른 가용 영역에 있는 서버끼리 통신해도 성능 저하가 거의 없습니다. 실제 현업에서는 어떻게 사용할까요?

대표적인 예가 RDS 다중 AZ 배포입니다. 데이터베이스를 생성할 때 "Multi-AZ"를 선택하면, AWS가 자동으로 주 데이터베이스를 2a에, 대기 데이터베이스를 2c에 만듭니다.

주 DB에 장애가 발생하면 몇 초 내에 자동으로 대기 DB로 전환됩니다. 또 다른 예는 로드 밸런서입니다.

Application Load Balancer를 만들 때 최소 2개 이상의 가용 영역을 선택해야 합니다. 그러면 트래픽이 여러 가용 영역의 서버에 골고루 분산됩니다.

한 가용 영역이 다운되어도 다른 가용 영역의 서버가 요청을 처리합니다. 이클라우드 씨가 실전 사례를 알려줍니다.

"작년에 우리 서비스가 하루 천만 명이 접속하는 이벤트를 했어요. 혹시 모를 장애에 대비해서 3개의 가용 영역에 서버를 배치했죠.

행사 중에 2a 가용 영역이 일시적으로 느려졌는데, 자동으로 트래픽이 2b와 2c로 우회되면서 사용자들은 전혀 몰랐어요." 주의할 점도 있습니다. 가용 영역 간 데이터 전송은 무료가 아닙니다.

같은 가용 영역 내에서는 무료지만, 다른 가용 영역으로 데이터를 보내면 GB당 소액의 비용이 발생합니다. 엄청난 양의 데이터를 주고받는다면 이 비용도 무시할 수 없습니다.

또한 모든 인스턴스 타입이 모든 가용 영역에서 제공되는 것은 아닙니다. 예를 들어 최신 GPU 인스턴스는 특정 가용 영역에서만 사용할 수 있습니다.

가끔 "용량 부족"이라는 에러가 나타나면, 다른 가용 영역을 선택해보세요. 김클라우드 씨가 정리합니다.

"그러니까 리전은 지역이고, 가용 영역은 그 안의 독립된 데이터센터군요. 중요한 서비스는 여러 AZ에 분산하는 게 좋겠네요." 이클라우드 씨가 엄지를 치켜듭니다.

"완벽해요!" 가용 영역은 AWS 고가용성 아키텍처의 핵심입니다. 단일 장애점을 없애고, 99.99퍼센트 이상의 가용성을 달성하려면 반드시 여러 AZ를 활용해야 합니다.

실전 팁

💡 - 프로덕션 환경에서는 항상 최소 2개 이상의 AZ에 리소스를 배치하세요

RDS는 Multi-AZ 옵션을 활성화하면 자동으로 장애 조치가 가능합니다
가용 영역 간 데이터 전송 비용을 고려해서 아키텍처를 설계하세요

5. 리전 선택 기준

김클라우드 씨의 팀은 새로운 모바일 앱을 출시하기로 했습니다. 한국 사용자가 80퍼센트, 일본 사용자가 20퍼센트입니다.

팀장이 물었습니다. "어느 리전에 서버를 구축할까요?" 김클라우드 씨는 고민에 빠졌습니다.

리전 선택은 서비스의 성능, 비용, 법규 준수에 직접적인 영향을 미치는 중요한 결정입니다. 마치 실제 매장을 어디에 열지 결정하는 것처럼, 신중하게 여러 요소를 고려해야 합니다.

주요 사용자와의 거리, 서비스 가용성, 가격, 규제 요구사항 등을 종합적으로 판단해야 합니다.

다음 코드를 살펴봅시다.

// Node.js에서 여러 리전의 서비스 가용성과 가격 정보 비교하기
const AWS = require('aws-sdk');

// 여러 리전에서 서비스 가용성 확인
async function checkRegionAvailability(regions) {
  const results = {};

  for (const region of regions) {
    const ec2 = new AWS.EC2({ region });

    try {
      // 해당 리전에서 사용 가능한 인스턴스 타입 조회
      const types = await ec2.describeInstanceTypes({
        Filters: [{ Name: 'instance-type', Values: ['t3.*'] }]
      }).promise();

      results[region] = {
        available: true,
        instanceCount: types.InstanceTypes.length
      };
    } catch (err) {
      results[region] = { available: false, error: err.message };
    }
  }

  return results;
}

// 사용 예시
checkRegionAvailability(['ap-northeast-2', 'ap-northeast-1', 'us-east-1']);

김클라우드 씨는 리전 선택이 이렇게 복잡한 문제인지 몰랐습니다. 이클라우드 씨가 화이트보드에 그림을 그리며 설명합니다.

"리전 선택에는 네 가지 핵심 요소가 있어요. 하나씩 살펴봅시다." 첫 번째 기준은 지연시간입니다.

쉽게 비유하자면, 리전 선택은 마치 피자 가게 위치를 정하는 것과 같습니다. 고객이 강남에 몰려 있다면 강남에 가게를 내야 배달이 빠릅니다.

서울에 가게를 두고 부산 고객에게 배달하면 너무 오래 걸립니다. AWS도 마찬가지입니다.

한국 사용자가 대부분이라면 서울 리전을 선택해야 빠릅니다. 실제 지연시간 차이는 얼마나 될까요?

한국에서 서울 리전에 접속하면 약 10~~20밀리초가 걸립니다. 하지만 미국 버지니아 리전에 접속하면 150~~200밀리초가 걸립니다.

10배 차이입니다. 웹 페이지 하나를 로딩하는 데 10번의 요청이 필요하다면, 총 1~2초의 차이가 발생합니다.

사용자는 이 차이를 명확히 느낍니다. 두 번째 기준은 법규 준수입니다.

많은 국가에서 개인정보는 반드시 자국 내에 저장하도록 법으로 규정합니다. 한국의 경우 개인정보보호법에서 주민등록번호 같은 민감 정보는 국내 서버에 보관하도록 요구합니다.

유럽은 GDPR이라는 더 엄격한 규정이 있습니다. 이런 경우 선택의 여지가 없습니다.

해당 국가의 리전을 사용해야 합니다. 세 번째 기준은 서비스 가용성입니다.

모든 AWS 서비스가 모든 리전에서 제공되는 것은 아닙니다. 새로운 서비스는 보통 버지니아 리전(us-east-1)에 먼저 출시됩니다.

그리고 몇 개월 후 다른 주요 리전으로 확대됩니다. 서울 리전은 아시아에서 두 번째로 많은 서비스를 제공하지만, 그래도 일부 최신 서비스는 아직 없을 수 있습니다.

이클라우드 씨가 예를 듭니다. "작년에 우리가 Amazon Kendra라는 AI 검색 서비스를 쓰려고 했는데, 서울 리전에서는 제공하지 않았어요.

결국 도쿄 리전을 사용했죠. 지연시간이 조금 늘었지만, 그 서비스가 꼭 필요했으니까요." 네 번째 기준은 가격입니다.

리전마다 운영 비용이 다르기 때문에 가격도 다릅니다. 일반적으로 미국 리전이 가장 저렴하고, 아시아와 유럽 리전이 약간 비쌉니다.

서울 리전은 버지니아 리전보다 약 10~15퍼센트 정도 비쌉니다. 큰 차이는 아니지만, 규모가 크면 무시할 수 없습니다.

그렇다면 실제로는 어떻게 결정할까요? 대부분의 경우 주요 사용자와의 거리가 가장 중요한 기준입니다.

한국 사용자 대상 서비스라면 서울 리전이 답입니다. 전 세계 사용자를 대상으로 한다면 여러 리전에 분산 배치하는 것이 좋습니다.

김클라우드 씨의 경우를 분석해봅시다. 한국 사용자가 80퍼센트, 일본 사용자가 20퍼센트입니다.

이 경우 서울 리전이 최선입니다. 대부분의 사용자가 빠른 속도를 경험하고, 일본 사용자도 서울까지는 30~40밀리초밖에 안 걸리므로 괜찮습니다.

만약 일본 사용자가 40퍼센트 이상이라면, 서울과 도쿄 두 리전을 모두 사용하는 것을 고려해야 합니다. 글로벌 서비스는 어떻게 할까요?

Netflix나 Spotify 같은 글로벌 서비스는 여러 리전을 동시에 사용합니다. 미국 사용자는 버지니아 리전에, 유럽 사용자는 아일랜드 리전에, 아시아 사용자는 서울이나 싱가포르 리전에 접속합니다.

사용자 위치에 따라 자동으로 가장 가까운 리전으로 연결하는 것입니다. 주의할 점이 있습니다.

한번 리전을 선택하면 나중에 변경하기 매우 어렵습니다. 데이터를 모두 옮기고, 설정을 다시 하고, DNS를 변경하는 등 복잡한 작업이 필요합니다.

따라서 초기에 신중하게 결정해야 합니다. 이클라우드 씨가 정리합니다.

"리전 선택은 집을 사는 것과 비슷해요. 한번 정하면 쉽게 바꿀 수 없으니, 여러 요소를 충분히 고려해서 결정하세요." 김클라우드 씨는 고개를 끄덕입니다.

"우리는 한국 사용자가 대부분이니 서울 리전이 답이네요. 나중에 일본 사용자가 많아지면 그때 도쿄 리전을 추가하면 되겠죠?" 결국 리전 선택은 사용자 경험과 직결됩니다.

빠른 응답 속도가 곧 사용자 만족도로 이어집니다. 신중하게 결정하세요.

실전 팁

💡 - 주요 사용자 위치에서 각 리전까지의 지연시간을 측정해보세요

AWS의 "Speed Test" 도구로 실제 속도를 비교할 수 있습니다
법규 요구사항을 반드시 먼저 확인하세요 - 선택의 여지가 없을 수 있습니다

6. 글로벌 vs 리전 서비스

김클라우드 씨는 IAM에서 사용자를 생성했습니다. 그런데 이상한 점을 발견했습니다.

리전을 서울에서 도쿄로 바꿔도 방금 만든 사용자가 여전히 보입니다. "어?

EC2는 리전마다 따로 보이는데, IAM은 왜 모든 리전에서 보이지?"

AWS 서비스는 크게 글로벌 서비스와 리전 서비스로 나뉩니다. 글로벌 서비스는 전 세계에서 하나의 통합된 시스템으로 운영되며, 리전을 선택할 필요가 없습니다.

반면 리전 서비스는 각 리전마다 독립적으로 운영되어, 서울 리전에서 만든 리소스는 도쿄 리전에서 보이지 않습니다. 이 차이를 이해하는 것이 AWS 아키텍처 설계의 기본입니다.

다음 코드를 살펴봅시다.

// Node.js에서 글로벌 서비스와 리전 서비스 사용하기
const AWS = require('aws-sdk');

// IAM은 글로벌 서비스 - 리전 지정 불필요
const iam = new AWS.IAM(); // 리전 파라미터 없음

// 모든 IAM 사용자 조회 (전 세계 공통)
iam.listUsers({}, (err, data) => {
  if (err) console.error(err);
  else console.log('IAM 사용자:', data.Users);
  // 어느 리전에서 조회해도 동일한 결과
});

// S3도 글로벌 네임스페이스를 사용하지만 버킷은 리전에 속함
const s3 = new AWS.S3(); // 리전 지정 가능하지만 네임스페이스는 전역

// EC2는 리전 서비스 - 반드시 리전 지정 필요
const ec2Seoul = new AWS.EC2({ region: 'ap-northeast-2' });
const ec2Tokyo = new AWS.EC2({ region: 'ap-northeast-1' });
// 각각 독립적인 리소스 목록 반환

김클라우드 씨는 혼란스러웠습니다. EC2를 만들 때는 리전을 신경 써야 했는데, IAM 사용자는 리전과 무관하게 보입니다.

이클라우드 씨가 설명합니다. "AWS 서비스는 두 가지 종류로 나뉘어요.

이것을 이해하면 많은 것이 명확해집니다." 글로벌 서비스란 무엇일까요? 쉽게 비유하자면, 글로벌 서비스는 마치 전국구 신분증과 같습니다.

주민등록증은 서울에서 발급받아도 부산에서도 그대로 사용할 수 있습니다. 전국 어디서나 동일한 정보가 조회됩니다.

IAM도 마찬가지입니다. 한 번 만든 사용자는 모든 리전에서 동일하게 인식됩니다.

대표적인 글로벌 서비스는 무엇이 있을까요? 첫째는 **IAM(Identity and Access Management)**입니다.

사용자, 역할, 정책을 관리하는 서비스입니다. 보안 관련 설정이므로 전 세계적으로 통일되어야 합니다.

김클라우드 씨가 만든 IAM 사용자는 서울 리전의 EC2에도, 도쿄 리전의 RDS에도 동일한 권한으로 접근할 수 있습니다. 둘째는 CloudFront입니다.

이것은 CDN(콘텐츠 전송 네트워크) 서비스입니다. 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 빠르게 전달합니다.

본질적으로 글로벌 서비스이므로, 리전을 선택할 필요가 없습니다. 셋째는 Route 53입니다.

DNS 관리 서비스입니다. 도메인 이름을 IP 주소로 변환하는 작업은 전 세계 어디서나 동일해야 하므로 글로벌 서비스입니다.

example.com이라는 도메인은 한국에서 봐도, 미국에서 봐도 같은 IP를 가리켜야 합니다. 그렇다면 리전 서비스는 무엇일까요?

리전 서비스는 마치 지역 은행 지점의 금고와 같습니다. 강남지점 금고에 넣은 물건은 분당지점 금고에서 볼 수 없습니다.

각 지점이 독립적으로 운영되는 것입니다. 대표적인 리전 서비스는 무엇이 있을까요?

EC2는 가장 대표적인 리전 서비스입니다. 서울 리전에서 만든 인스턴스는 서울 리전에만 존재합니다.

도쿄 리전으로 가면 보이지 않습니다. 각 리전의 데이터센터에 물리적으로 존재하기 때문입니다.

RDS 데이터베이스도 리전 서비스입니다. 서울 리전에 만든 MySQL 데이터베이스는 서울 데이터센터에 있습니다.

이것을 도쿄에서 접근하려면 인터넷을 통해 연결해야 하고, 지연시간이 발생합니다. Lambda 함수도 리전 서비스입니다.

같은 코드라도 각 리전에 따로 배포해야 합니다. 서울 리전의 Lambda 함수는 서울 리전의 다른 서비스와 빠르게 통신할 수 있지만, 도쿄 리전의 서비스와는 느립니다.

S3는 특별한 경우입니다. S3 버킷 이름은 전 세계적으로 고유해야 합니다.

"my-bucket"이라는 이름을 누군가 이미 사용했다면, 다른 리전에서도 그 이름을 사용할 수 없습니다. 하지만 버킷 자체는 특정 리전에 속합니다.

서울 리전에 만든 버킷은 서울 데이터센터에 저장됩니다. 실제 현업에서는 어떻게 활용할까요?

이클라우드 씨가 경험담을 들려줍니다. "우리가 글로벌 서비스를 출시할 때, 서울과 버지니아 두 리전에 인프라를 구축했어요.

EC2, RDS, Lambda는 각 리전에 따로 만들었죠. 하지만 IAM 사용자와 정책은 한 번만 만들면 두 리전에서 모두 사용할 수 있었어요." 왜 이렇게 구분했을까요?

글로벌 서비스는 전 세계에서 일관되어야 하는 것들입니다. 보안 설정, DNS, 콘텐츠 배포 같은 것들이죠.

반면 리전 서비스는 물리적 위치가 중요한 것들입니다. 컴퓨팅, 스토리지, 데이터베이스처럼 실제 데이터가 저장되고 처리되는 서비스들입니다.

주의할 점이 있습니다. IAM 같은 글로벌 서비스를 변경하면 전 세계 모든 리전에 즉시 반영됩니다.

IAM 사용자를 삭제하면, 그 사용자는 어떤 리전에서도 더 이상 접근할 수 없습니다. 실수로 중요한 권한을 삭제하면 전체 시스템에 영향을 줄 수 있으니 신중해야 합니다.

또 하나 팁이 있습니다. AWS 콘솔에서 글로벌 서비스를 사용할 때는 오른쪽 상단의 리전 선택이 "Global" 또는 비활성화됩니다.

IAM 화면을 열어보면 리전을 선택할 수 없습니다. 이것이 글로벌 서비스라는 신호입니다.

김클라우드 씨가 정리합니다. "그러니까 사용자 인증 같은 보안 관련은 글로벌 서비스고, 실제 서버와 데이터는 리전 서비스군요.

이제 왜 IAM이 모든 리전에서 보였는지 이해됐어요!" 이클라우드 씨가 마지막 조언을 합니다. "아키텍처를 설계할 때 이 차이를 꼭 기억하세요.

글로벌 서비스는 한 번만 설정하면 되지만, 리전 서비스는 각 리전마다 구축해야 합니다. 이것을 놓치면 나중에 큰 일 납니다." 글로벌 서비스와 리전 서비스의 차이를 이해하면 AWS 아키텍처가 한눈에 들어옵니다.

무엇이 어디에 속하는지 명확히 알고, 그에 맞게 설계하세요.

실전 팁

💡 - IAM, CloudFront, Route 53는 글로벌 서비스로 리전 선택이 불필요합니다

EC2, RDS, Lambda는 리전 서비스로 각 리전마다 따로 관리됩니다
S3 버킷 이름은 전역적으로 고유해야 하지만 버킷 자체는 특정 리전에 속합니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#Console#Region#AZ#GlobalServices

AWS 콘솔과 리전 완벽 가이드

# AWS 콘솔과 리전 완벽 가이드 AWS를 처음 시작하는 개발자를 위한 관리 콘솔 사용법과 리전 개념 완벽 정리. 실무에서 꼭 알아야 할 리전 선택 기준과 글로벌 서비스 이해까지 한 번에 마스터하세요. --- ## 목차 1. [AWS_관리_콘솔_둘러보기](#aws-관리-콘솔-둘러보기) 2. [서비스_검색과_즐겨찾기](#서비스-검색과-즐겨찾기) 3. [리전_Region_이란](#리전-region-이란) 4. [가용_영역_AZ_개념](#가용-영역-az-개념) 5. [리전_선택_기준](#리전-선택-기준) 6. [글로벌_vs_리전_서비스](#글로벌-vs-리전-서비스) --- ## 1. AWS_관리_콘솔_둘러보기 어느 날 신입 개발자 김클라우드 씨는 첫 AWS 계정을 받았습니다. 로그인 후 화면을 보니 수많은 메뉴와 서비스들이 눈앞에 펼쳐졌습니다. "대체 어디서부터 시작해야 하지?" 막막함이 밀려왔습니다. **AWS 관리 콘솔**은 웹 브라우저에서 AWS의 모든 서비스를 관리할 수 있는 통합 관리 도구입니다. 마치 스마트폰의 설정 앱처럼, 하나의 화면에서 모든 클라우드 자원을 제어할 수 있습니다. 처음에는 복잡해 보이지만, 구조를 이해하면 매우 직관적으로 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```javascript // AWS SDK를 통한 프로그래밍 방식 접근도 가능합니다 const AWS = require('aws-sdk'); // AWS 자격증명 설정 AWS.config.update({ region: 'ap-northeast-2', accessKeyId: process.env.AWS_ACCESS_KEY, secretAccessKey: process.env.AWS_SECRET_KEY }); // EC2 서비스 객체 생성 const ec2 = new AWS.EC2(); // 인스턴스 목록 조회 - 콘솔에서 보는 것과 동일한 정보 ec2.describeInstances({}, (err, data) => { if (err) console.error(err); else console.log('인스턴스 목록:', data.Reservations); }); ``` 김클라우드 씨는 입사 첫날 AWS 계정을 받았습니다. 선배 개발자 이클라우드 씨가 옆에 앉아 친절하게 설명해줍니다. "걱정하지 마세요. 처음엔 다들 그래요. 하나씩 천천히 알아가면 됩니다." AWS 관리 콘솔이란 정확히 무엇일까요? 쉽게 비유하자면, AWS 관리 콘솔은 마치 거대한 쇼핑몰의 안내 데스크와 같습니다. 쇼핑몰에 수백 개의 매장이 있듯이, AWS에는 200개가 넘는 서비스가 있습니다. 안내 데스크에서 원하는 매장 위치를 검색하고 찾아가듯, 콘솔에서 필요한 서비스를 검색하고 접근할 수 있습니다. 로그인하면 가장 먼저 보이는 화면이 홈 대시보드입니다. 화면 최상단에는 **검색창**이 있습니다. 이것이 가장 중요한 기능입니다. 서비스 이름을 입력하면 즉시 해당 서비스로 이동할 수 있습니다. 예를 들어 "EC2"라고 입력하면 가상 서버 관리 화면으로, "S3"라고 입력하면 파일 저장소로 바로 이동합니다. 왼쪽 상단에는 **서비스 메뉴**가 있습니다. 이 메뉴를 클릭하면 모든 AWS 서비스가 카테고리별로 정리되어 나타납니다. 컴퓨팅, 스토리지, 데이터베이스, 네트워킹 등 용도별로 분류되어 있어서 어떤 서비스가 어디에 속하는지 이해하기 쉽습니다. 오른쪽 상단을 보면 중요한 요소들이 있습니다. 먼저 **리전 선택 메뉴**가 보입니다. 현재 "서울"이라고 표시되어 있다면, 지금 서울 리전에서 작업하고 있다는 뜻입니다. 이 부분은 매우 중요해서 나중에 자세히 다루겠습니다. 그 옆에는 계정 이름과 알림 아이콘이 있습니다. 중앙 화면에는 **최근 방문한 서비스**가 표시됩니다. 자주 사용하는 서비스는 이 영역에 자동으로 나타나서, 매번 검색하지 않아도 빠르게 접근할 수 있습니다. 마치 웹 브라우저의 즐겨찾기와 비슷한 개념입니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 개발자는 하루에도 수십 번 콘솔에 접속합니다. 서버 상태를 확인하고, 로그를 살펴보고, 새로운 리소스를 생성합니다. 처음에는 마우스로 클릭하며 찾아다니지만, 익숙해지면 검색창만 사용해서 몇 초 만에 원하는 곳으로 이동합니다. 이클라우드 씨가 실전 팁을 알려줍니다. "검색창에 서비스 이름 전체를 입력할 필요 없어요. 'ec2'만 입력해도 되고, 심지어 'e'만 입력해도 EC2가 추천 목록에 나타납니다. 그리고 콘솔 화면은 여러 탭으로 열어두고 작업하면 편해요." 또 하나 중요한 점이 있습니다. 콘솔 언어 설정을 확인하세요. 하단에서 한국어나 영어를 선택할 수 있습니다. 하지만 실무에서는 영어로 사용하는 것을 추천합니다. 공식 문서나 에러 메시지가 모두 영어로 되어 있어서, 영어 용어에 익숙해지는 것이 장기적으로 도움이 됩니다. 김클라우드 씨는 이클라우드 씨의 설명을 들으며 고개를 끄덕였습니다. "생각보다 어렵지 않네요. 검색창만 잘 사용하면 되는군요!" AWS 관리 콘솔은 클라우드 여행의 시작점입니다. 이 도구를 자유자재로 다룰 수 있다면, AWS의 강력한 기능들을 마음껏 활용할 수 있습니다. **실전 팁** 💡 - 검색창 단축키는 Alt+S (Windows) 또는 Option+S (Mac)입니다 - 자주 사용하는 서비스는 상단의 별표 아이콘을 눌러 즐겨찾기에 추가하세요 - 모바일 앱 "AWS Console"을 설치하면 스마트폰에서도 리소스를 모니터링할 수 있습니다 --- ## 2. 서비스_검색과_즐겨찾기 김클라우드 씨는 매일 아침 출근하면 EC2, RDS, S3를 차례로 확인합니다. 처음에는 서비스 메뉴를 열어서 하나씩 찾아갔는데, 하루에도 수십 번 반복하다 보니 너무 번거로웠습니다. "더 빠른 방법은 없을까?" AWS 콘솔의 **검색 기능**과 **즐겨찾기 시스템**은 200개가 넘는 서비스 중에서 필요한 것을 빠르게 찾아주는 핵심 도구입니다. 마치 도서관에서 책을 찾을 때 사서에게 물어보는 것처럼, 검색창에 서비스명만 입력하면 즉시 이동할 수 있습니다. 자주 쓰는 서비스는 즐겨찾기로 등록하면 더욱 효율적입니다. 다음 코드를 살펴봅시다. ```javascript // AWS CLI를 통한 서비스 검색 및 리소스 조회 const { exec } = require('child_process'); // AWS CLI로 특정 서비스의 리소스 검색 function searchAWSResource(serviceName, resourceType) { // 예: EC2 인스턴스 검색 const command = `aws ${serviceName} describe-${resourceType}`; exec(command, (error, stdout, stderr) => { if (error) { console.error(`검색 실패: ${error.message}`); return; } // JSON 형태로 결과 반환 const resources = JSON.parse(stdout); console.log(`${serviceName} ${resourceType} 목록:`, resources); }); } // 실제 사용 예시 searchAWSResource('ec2', 'instances'); searchAWSResource('s3', 'buckets'); ``` 김클라우드 씨는 매일 같은 작업을 반복하면서 불편함을 느꼈습니다. 이클라우드 씨가 그 모습을 보고 다가왔습니다. "아직도 메뉴에서 찾아가요? 검색창을 활용하면 훨씬 빠릅니다." 검색창의 진정한 힘은 무엇일까요? 쉽게 비유하자면, AWS 검색창은 마치 스마트폰의 앱 검색과 같습니다. 홈 화면을 이리저리 넘기며 앱을 찾는 대신, 검색창에 앱 이름 몇 글자만 입력하면 바로 찾아집니다. AWS도 마찬가지입니다. 메뉴를 펼치고 카테고리를 찾아 헤매는 대신, 검색창에 서비스명만 입력하면 됩니다. 검색창 사용법은 생각보다 훨씬 유연합니다. 예를 들어 EC2로 가고 싶다면 "ec2"라고 전체를 입력할 필요가 없습니다. "e"만 입력해도 EC2가 상위에 표시됩니다. "s3"를 찾는다면 "s"만 입력해도 됩니다. 심지어 한글로 "가상서버"라고 입력해도 EC2를 찾아줍니다. 더 강력한 기능도 있습니다. 검색창은 서비스뿐만 아니라 **리소스**도 찾아줍니다. 예를 들어 특정 EC2 인스턴스의 ID를 검색하면, 해당 인스턴스의 상세 페이지로 바로 이동합니다. S3 버킷 이름을 입력하면 그 버킷으로 직접 들어갑니다. 이제 즐겨찾기 기능을 알아보겠습니다. 화면 왼쪽을 보면 **별표 아이콘**이 있습니다. 자주 사용하는 서비스 페이지에서 이 별표를 클릭하면 즐겨찾기에 추가됩니다. 그러면 왼쪽 사이드바에 즐겨찾기 목록이 생기고, 클릭 한 번으로 바로 이동할 수 있습니다. 실제 현업 개발자들의 즐겨찾기 목록을 보면 패턴이 있습니다. 대부분 EC2, RDS, S3, CloudWatch를 즐겨찾기에 넣어둡니다. 이 네 가지가 가장 자주 사용하는 서비스이기 때문입니다. 여기에 Lambda나 DynamoDB처럼 프로젝트에서 쓰는 서비스를 추가합니다. 이클라우드 씨가 자신의 화면을 보여줍니다. "제 즐겨찾기를 보세요. EC2, RDS, S3, CloudWatch, IAM, CloudFormation 이렇게 6개만 등록해뒀어요. 이것만으로도 일상 업무의 95퍼센트를 처리합니다. 나머지 서비스는 필요할 때만 검색해서 찾아가면 되니까요." 검색창에는 숨겨진 팁도 있습니다. 검색 결과에서 **최근 방문한 항목**이 우선적으로 표시됩니다. 만약 어제 특정 EC2 인스턴스를 봤다면, 다음날 "ec2"를 검색했을 때 그 인스턴스가 상위에 나타납니다. AWS가 사용자의 작업 패턴을 학습하는 것입니다. 키보드 단축키를 활용하면 더욱 빨라집니다. Windows에서는 **Alt+S**, Mac에서는 **Option+S**를 누르면 검색창으로 바로 이동합니다. 마우스로 클릭할 필요가 없습니다. 익숙해지면 검색창 단축키를 누르고, 서비스명 두세 글자를 입력하고, 엔터를 치는 것이 3초 안에 끝납니다. 김클라우드 씨는 이클라우드 씨의 작업 속도에 감탄했습니다. "와, 정말 빠르네요! 저는 계속 마우스로 클릭해서 찾아갔는데, 이렇게 하니까 시간이 엄청 절약되네요." 이클라우드 씨가 웃으며 답합니다. "처음에는 익숙하지 않겠지만, 일주일만 연습하면 자연스럽게 몸에 배게 될 거예요." 주의할 점도 있습니다. 즐겨찾기를 너무 많이 등록하면 오히려 복잡해집니다. 정말 자주 쓰는 서비스 5~8개 정도만 등록하는 것이 좋습니다. 그 이상은 검색창으로 찾는 것이 더 빠릅니다. 결국 효율적인 AWS 작업의 핵심은 검색입니다. 메뉴 구조를 외우려고 하지 말고, 검색에 익숙해지세요. 그것이 진짜 고수가 되는 첫걸음입니다. **실전 팁** 💡 - 검색창 단축키 Alt+S (Win) 또는 Option+S (Mac)을 꼭 익히세요 - 즐겨찾기는 5~8개만 유지하는 것이 가장 효율적입니다 - 리소스 ID나 이름으로도 검색이 가능하니 적극 활용하세요 --- ## 3. 리전_Region_이란 어느 날 김클라우드 씨는 어제 생성한 EC2 인스턴스가 보이지 않아 당황했습니다. 분명히 만들었는데 목록에 없습니다. 이클라우드 씨가 화면 오른쪽 상단을 가리킵니다. "리전이 '서울'이 아니라 '버지니아'로 되어 있네요. 리전을 바꿔보세요." **리전(Region)**은 AWS가 전 세계에 운영하는 물리적인 데이터센터 집합을 의미합니다. 마치 대형 마트가 여러 지역에 지점을 두는 것처럼, AWS도 서울, 도쿄, 싱가포르, 버지니아 등 전 세계 30개 이상의 지역에 독립적인 인프라를 구축해두었습니다. 각 리전은 완전히 분리되어 있어서, 서울 리전에서 만든 서버는 도쿄 리전에서 보이지 않습니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 특정 리전의 AWS 서비스 사용하기 const AWS = require('aws-sdk'); // 서울 리전(ap-northeast-2)에서 EC2 인스턴스 조회 const ec2Seoul = new AWS.EC2({ region: 'ap-northeast-2' }); ec2Seoul.describeInstances({}, (err, data) => { if (err) console.error('서울 리전 에러:', err); else console.log('서울 리전 인스턴스:', data.Reservations.length); }); // 도쿄 리전(ap-northeast-1)에서 EC2 인스턴스 조회 const ec2Tokyo = new AWS.EC2({ region: 'ap-northeast-1' }); ec2Tokyo.describeInstances({}, (err, data) => { if (err) console.error('도쿄 리전 에러:', err); else console.log('도쿄 리전 인스턴스:', data.Reservations.length); }); ``` 김클라우드 씨는 당황했습니다. 분명히 어제 EC2 인스턴스를 생성했는데, 오늘 보니 목록이 비어 있습니다. "혹시 삭제된 건가?" 불안한 마음에 이클라우드 씨를 불렀습니다. 이클라우드 씨는 화면을 보자마자 원인을 알았습니다. "화면 오른쪽 상단을 보세요. 지금 '버지니아 북부' 리전으로 되어 있죠? 어제는 아마 '서울' 리전에서 작업했을 거예요. 리전을 바꿔보세요." 김클라우드 씨가 리전을 '서울'로 변경하자, 사라졌던 인스턴스가 다시 나타났습니다. 리전이란 정확히 무엇일까요? 쉽게 비유하자면, 리전은 마치 은행의 지점과 같습니다. 신한은행 강남지점에서 계좌를 만들었다면, 그 계좌 정보는 강남지점 시스템에 저장됩니다. 분당지점 ATM에 가면 그 계좌를 볼 수 있지만, 그것은 본사 시스템을 통해 연결되어 있기 때문입니다. 하지만 AWS 리전은 그렇지 않습니다. 각 리전은 완전히 독립적입니다. AWS는 왜 리전을 나누어 운영할까요? 첫 번째 이유는 **지연시간** 때문입니다. 한국에 있는 사용자가 미국 서버에 접속하면 데이터가 태평양을 건너야 합니다. 빛의 속도로도 최소 100밀리초 이상 걸립니다. 하지만 서울 리전의 서버라면 10밀리초 안에 응답합니다. 이 차이가 사용자 경험을 좌우합니다. 두 번째 이유는 **법규 준수**입니다. 많은 나라에서 개인정보는 반드시 자국 내에 저장하도록 법으로 규정합니다. 한국 사용자의 데이터를 한국 내 데이터센터에 보관해야 하는 것입니다. 리전 단위로 분리되어 있으면 이런 규정을 쉽게 만족시킬 수 있습니다. 세 번째 이유는 **재해 대비**입니다. 만약 전 세계 AWS가 하나의 거대한 데이터센터로 운영된다면, 그곳에 문제가 생기면 전 세계 서비스가 모두 멈춥니다. 하지만 리전이 분리되어 있으면, 한 리전에 문제가 생겨도 다른 리전은 정상 작동합니다. 현재 AWS는 전 세계에 30개 이상의 리전을 운영합니다. 한국에는 **서울 리전(ap-northeast-2)**이 있습니다. 이것이 한국 개발자들이 가장 많이 사용하는 리전입니다. 일본에는 도쿄와 오사카 리전이, 싱가포르에는 싱가포르 리전이 있습니다. 미국에는 버지니아, 오하이오, 캘리포니아 등 여러 리전이 있습니다. 각 리전의 코드명을 이해하면 도움이 됩니다. **ap-northeast-2**를 예로 들어보겠습니다. "ap"는 Asia Pacific(아시아 태평양)을 의미합니다. "northeast"는 북동쪽, 즉 한국과 일본 지역입니다. "2"는 이 지역의 두 번째 리전이라는 뜻입니다. 참고로 ap-northeast-1은 도쿄 리전입니다. 실제 현업에서는 어떻게 활용할까요? 대부분의 한국 서비스는 서울 리전을 기본으로 사용합니다. 하지만 글로벌 서비스라면 여러 리전을 동시에 사용합니다. 예를 들어 한국 사용자를 위해서는 서울 리전에, 일본 사용자를 위해서는 도쿄 리전에, 미국 사용자를 위해서는 버지니아 리전에 서버를 구축합니다. 주의할 점이 있습니다. 리전을 잘못 선택하면 나중에 바꾸기 매우 어렵습니다. EC2 인스턴스를 버지니아에서 만들었다가 서울로 옮기려면, 단순히 이동시킬 수 없습니다. 백업을 만들고, 서울 리전에서 새로 생성하고, 데이터를 복사하는 복잡한 과정을 거쳐야 합니다. 또 하나 중요한 점이 있습니다. 리전마다 **가격이 다릅니다**. 같은 사양의 EC2 인스턴스라도 서울 리전이 버지니아 리전보다 약간 비쌉니다. 또한 모든 리전에서 모든 서비스가 제공되는 것은 아닙니다. 최신 서비스는 보통 버지니아 리전에 먼저 출시되고, 몇 개월 후 다른 리전으로 확대됩니다. 김클라우드 씨는 이제 리전의 중요성을 깨달았습니다. "앞으로는 작업 시작 전에 항상 리전부터 확인해야겠어요." 이클라우드 씨가 고개를 끄덕입니다. "맞아요. 리전 확인은 AWS 작업의 기본 중의 기본입니다." 리전은 AWS 인프라의 가장 큰 단위입니다. 이것을 이해하지 못하면, 김클라우드 씨처럼 리소스를 찾지 못해 헤매게 됩니다. 항상 화면 오른쪽 상단의 리전 표시를 확인하는 습관을 들이세요. **실전 팁** 💡 - 작업 시작 전 항상 오른쪽 상단의 리전을 먼저 확인하세요 - 한국 서비스라면 기본적으로 ap-northeast-2(서울)를 사용합니다 - 리전 간 데이터 전송에는 추가 비용이 발생하니 주의하세요 --- ## 4. 가용_영역_AZ_개념 김클라우드 씨는 EC2 인스턴스를 생성하다가 "가용 영역"이라는 항목을 발견했습니다. "ap-northeast-2a", "ap-northeast-2c" 같은 선택지가 나타났습니다. "리전도 선택했는데, 가용 영역은 또 뭐지?" 궁금증이 생겼습니다. **가용 영역(Availability Zone, AZ)**은 하나의 리전 내에서 물리적으로 분리된 데이터센터 집합을 의미합니다. 마치 한 도시 안에 여러 개의 전력 공급소가 분산되어 있는 것처럼, 서울 리전 안에도 여러 개의 독립적인 데이터센터가 있습니다. 한 가용 영역에 장애가 발생해도 다른 가용 영역은 정상 작동하도록 설계되어 있습니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 특정 리전의 모든 가용 영역 조회하기 const AWS = require('aws-sdk'); // 서울 리전의 EC2 객체 생성 const ec2 = new AWS.EC2({ region: 'ap-northeast-2' }); // 해당 리전의 모든 가용 영역 조회 ec2.describeAvailabilityZones({}, (err, data) => { if (err) { console.error('가용 영역 조회 실패:', err); } else { console.log('서울 리전의 가용 영역 목록:'); data.AvailabilityZones.forEach(az => { console.log(`- ${az.ZoneName}: ${az.State}`); // 출력 예: ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d }); } }); ``` 김클라우드 씨는 EC2 생성 화면을 보며 고개를 갸우뚱했습니다. 이클라우드 씨가 그 모습을 보고 설명해줍니다. "가용 영역은 리전보다 더 작은 단위예요. 조금 복잡해 보이지만, 개념만 이해하면 쉽습니다." 가용 영역을 쉽게 이해해봅시다. 서울 리전을 하나의 큰 건물로 비유해보겠습니다. 이 건물 안에는 여러 개의 층이 있고, 각 층은 독립적인 전력과 네트워크를 갖추고 있습니다. 한 층에 화재가 나도 다른 층은 안전합니다. 각 층이 바로 가용 영역입니다. 같은 건물 안에 있지만, 서로 격리되어 있습니다. 서울 리전에는 몇 개의 가용 영역이 있을까요? 현재 서울 리전에는 **4개의 가용 영역**이 있습니다. ap-northeast-2a, ap-northeast-2b, ap-northeast-2c, ap-northeast-2d입니다. 각각이 독립적인 데이터센터이며, 서로 수 킬로미터 떨어져 있습니다. 가까우면서도 분리되어 있는 것입니다. 왜 이렇게 설계했을까요? 첫 번째 이유는 **장애 대응**입니다. 한 데이터센터에 정전이 발생하거나, 네트워크 장비가 고장 나거나, 심지어 자연재해가 발생해도 다른 가용 영역은 영향을 받지 않습니다. 실제로 2021년 미국 버지니아 리전에서 한 가용 영역에 정전이 발생했지만, 다른 가용 영역은 정상 작동했습니다. 두 번째 이유는 **고가용성 구성**입니다. 실무에서는 중요한 서비스를 구축할 때 반드시 **여러 가용 영역에 분산 배치**합니다. 예를 들어 웹 서버를 2a와 2c에 하나씩 두 대를 띄웁니다. 한 대가 다운되어도 다른 한 대가 서비스를 계속합니다. 사용자는 장애를 눈치채지 못합니다. 가용 영역 간에는 어떻게 통신할까요? 같은 리전 내의 가용 영역들은 **고속 네트워크**로 연결되어 있습니다. 지연시간이 매우 짧아서, 1밀리초 이내에 데이터가 전송됩니다. 따라서 서로 다른 가용 영역에 있는 서버끼리 통신해도 성능 저하가 거의 없습니다. 실제 현업에서는 어떻게 사용할까요? 대표적인 예가 **RDS 다중 AZ 배포**입니다. 데이터베이스를 생성할 때 "Multi-AZ"를 선택하면, AWS가 자동으로 주 데이터베이스를 2a에, 대기 데이터베이스를 2c에 만듭니다. 주 DB에 장애가 발생하면 몇 초 내에 자동으로 대기 DB로 전환됩니다. 또 다른 예는 **로드 밸런서**입니다. Application Load Balancer를 만들 때 최소 2개 이상의 가용 영역을 선택해야 합니다. 그러면 트래픽이 여러 가용 영역의 서버에 골고루 분산됩니다. 한 가용 영역이 다운되어도 다른 가용 영역의 서버가 요청을 처리합니다. 이클라우드 씨가 실전 사례를 알려줍니다. "작년에 우리 서비스가 하루 천만 명이 접속하는 이벤트를 했어요. 혹시 모를 장애에 대비해서 3개의 가용 영역에 서버를 배치했죠. 행사 중에 2a 가용 영역이 일시적으로 느려졌는데, 자동으로 트래픽이 2b와 2c로 우회되면서 사용자들은 전혀 몰랐어요." 주의할 점도 있습니다. 가용 영역 간 데이터 전송은 무료가 아닙니다. 같은 가용 영역 내에서는 무료지만, 다른 가용 영역으로 데이터를 보내면 GB당 소액의 비용이 발생합니다. 엄청난 양의 데이터를 주고받는다면 이 비용도 무시할 수 없습니다. 또한 모든 인스턴스 타입이 모든 가용 영역에서 제공되는 것은 아닙니다. 예를 들어 최신 GPU 인스턴스는 특정 가용 영역에서만 사용할 수 있습니다. 가끔 "용량 부족"이라는 에러가 나타나면, 다른 가용 영역을 선택해보세요. 김클라우드 씨가 정리합니다. "그러니까 리전은 지역이고, 가용 영역은 그 안의 독립된 데이터센터군요. 중요한 서비스는 여러 AZ에 분산하는 게 좋겠네요." 이클라우드 씨가 엄지를 치켜듭니다. "완벽해요!" 가용 영역은 AWS 고가용성 아키텍처의 핵심입니다. 단일 장애점을 없애고, 99.99퍼센트 이상의 가용성을 달성하려면 반드시 여러 AZ를 활용해야 합니다. **실전 팁** 💡 - 프로덕션 환경에서는 항상 최소 2개 이상의 AZ에 리소스를 배치하세요 - RDS는 Multi-AZ 옵션을 활성화하면 자동으로 장애 조치가 가능합니다 - 가용 영역 간 데이터 전송 비용을 고려해서 아키텍처를 설계하세요 --- ## 5. 리전_선택_기준 김클라우드 씨의 팀은 새로운 모바일 앱을 출시하기로 했습니다. 한국 사용자가 80퍼센트, 일본 사용자가 20퍼센트입니다. 팀장이 물었습니다. "어느 리전에 서버를 구축할까요?" 김클라우드 씨는 고민에 빠졌습니다. **리전 선택**은 서비스의 성능, 비용, 법규 준수에 직접적인 영향을 미치는 중요한 결정입니다. 마치 실제 매장을 어디에 열지 결정하는 것처럼, 신중하게 여러 요소를 고려해야 합니다. 주요 사용자와의 거리, 서비스 가용성, 가격, 규제 요구사항 등을 종합적으로 판단해야 합니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 여러 리전의 서비스 가용성과 가격 정보 비교하기 const AWS = require('aws-sdk'); // 여러 리전에서 서비스 가용성 확인 async function checkRegionAvailability(regions) { const results = {}; for (const region of regions) { const ec2 = new AWS.EC2({ region }); try { // 해당 리전에서 사용 가능한 인스턴스 타입 조회 const types = await ec2.describeInstanceTypes({ Filters: [{ Name: 'instance-type', Values: ['t3.*'] }] }).promise(); results[region] = { available: true, instanceCount: types.InstanceTypes.length }; } catch (err) { results[region] = { available: false, error: err.message }; } } return results; } // 사용 예시 checkRegionAvailability(['ap-northeast-2', 'ap-northeast-1', 'us-east-1']); ``` 김클라우드 씨는 리전 선택이 이렇게 복잡한 문제인지 몰랐습니다. 이클라우드 씨가 화이트보드에 그림을 그리며 설명합니다. "리전 선택에는 네 가지 핵심 요소가 있어요. 하나씩 살펴봅시다." 첫 번째 기준은 **지연시간**입니다. 쉽게 비유하자면, 리전 선택은 마치 피자 가게 위치를 정하는 것과 같습니다. 고객이 강남에 몰려 있다면 강남에 가게를 내야 배달이 빠릅니다. 서울에 가게를 두고 부산 고객에게 배달하면 너무 오래 걸립니다. AWS도 마찬가지입니다. 한국 사용자가 대부분이라면 서울 리전을 선택해야 빠릅니다. 실제 지연시간 차이는 얼마나 될까요? 한국에서 서울 리전에 접속하면 약 10~20밀리초가 걸립니다. 하지만 미국 버지니아 리전에 접속하면 150~200밀리초가 걸립니다. 10배 차이입니다. 웹 페이지 하나를 로딩하는 데 10번의 요청이 필요하다면, 총 1~2초의 차이가 발생합니다. 사용자는 이 차이를 명확히 느낍니다. 두 번째 기준은 **법규 준수**입니다. 많은 국가에서 개인정보는 반드시 자국 내에 저장하도록 법으로 규정합니다. 한국의 경우 **개인정보보호법**에서 주민등록번호 같은 민감 정보는 국내 서버에 보관하도록 요구합니다. 유럽은 GDPR이라는 더 엄격한 규정이 있습니다. 이런 경우 선택의 여지가 없습니다. 해당 국가의 리전을 사용해야 합니다. 세 번째 기준은 **서비스 가용성**입니다. 모든 AWS 서비스가 모든 리전에서 제공되는 것은 아닙니다. 새로운 서비스는 보통 버지니아 리전(us-east-1)에 먼저 출시됩니다. 그리고 몇 개월 후 다른 주요 리전으로 확대됩니다. 서울 리전은 아시아에서 두 번째로 많은 서비스를 제공하지만, 그래도 일부 최신 서비스는 아직 없을 수 있습니다. 이클라우드 씨가 예를 듭니다. "작년에 우리가 Amazon Kendra라는 AI 검색 서비스를 쓰려고 했는데, 서울 리전에서는 제공하지 않았어요. 결국 도쿄 리전을 사용했죠. 지연시간이 조금 늘었지만, 그 서비스가 꼭 필요했으니까요." 네 번째 기준은 **가격**입니다. 리전마다 운영 비용이 다르기 때문에 가격도 다릅니다. 일반적으로 미국 리전이 가장 저렴하고, 아시아와 유럽 리전이 약간 비쌉니다. 서울 리전은 버지니아 리전보다 약 10~15퍼센트 정도 비쌉니다. 큰 차이는 아니지만, 규모가 크면 무시할 수 없습니다. 그렇다면 실제로는 어떻게 결정할까요? 대부분의 경우 **주요 사용자와의 거리**가 가장 중요한 기준입니다. 한국 사용자 대상 서비스라면 서울 리전이 답입니다. 전 세계 사용자를 대상으로 한다면 여러 리전에 분산 배치하는 것이 좋습니다. 김클라우드 씨의 경우를 분석해봅시다. 한국 사용자가 80퍼센트, 일본 사용자가 20퍼센트입니다. 이 경우 **서울 리전**이 최선입니다. 대부분의 사용자가 빠른 속도를 경험하고, 일본 사용자도 서울까지는 30~40밀리초밖에 안 걸리므로 괜찮습니다. 만약 일본 사용자가 40퍼센트 이상이라면, 서울과 도쿄 두 리전을 모두 사용하는 것을 고려해야 합니다. 글로벌 서비스는 어떻게 할까요? Netflix나 Spotify 같은 글로벌 서비스는 여러 리전을 동시에 사용합니다. 미국 사용자는 버지니아 리전에, 유럽 사용자는 아일랜드 리전에, 아시아 사용자는 서울이나 싱가포르 리전에 접속합니다. 사용자 위치에 따라 자동으로 가장 가까운 리전으로 연결하는 것입니다. 주의할 점이 있습니다. 한번 리전을 선택하면 나중에 변경하기 매우 어렵습니다. 데이터를 모두 옮기고, 설정을 다시 하고, DNS를 변경하는 등 복잡한 작업이 필요합니다. 따라서 초기에 신중하게 결정해야 합니다. 이클라우드 씨가 정리합니다. "리전 선택은 집을 사는 것과 비슷해요. 한번 정하면 쉽게 바꿀 수 없으니, 여러 요소를 충분히 고려해서 결정하세요." 김클라우드 씨는 고개를 끄덕입니다. "우리는 한국 사용자가 대부분이니 서울 리전이 답이네요. 나중에 일본 사용자가 많아지면 그때 도쿄 리전을 추가하면 되겠죠?" 결국 리전 선택은 사용자 경험과 직결됩니다. 빠른 응답 속도가 곧 사용자 만족도로 이어집니다. 신중하게 결정하세요. **실전 팁** 💡 - 주요 사용자 위치에서 각 리전까지의 지연시간을 측정해보세요 - AWS의 "Speed Test" 도구로 실제 속도를 비교할 수 있습니다 - 법규 요구사항을 반드시 먼저 확인하세요 - 선택의 여지가 없을 수 있습니다 --- ## 6. 글로벌_vs_리전_서비스 김클라우드 씨는 IAM에서 사용자를 생성했습니다. 그런데 이상한 점을 발견했습니다. 리전을 서울에서 도쿄로 바꿔도 방금 만든 사용자가 여전히 보입니다. "어? EC2는 리전마다 따로 보이는데, IAM은 왜 모든 리전에서 보이지?" AWS 서비스는 크게 **글로벌 서비스**와 **리전 서비스**로 나뉩니다. 글로벌 서비스는 전 세계에서 하나의 통합된 시스템으로 운영되며, 리전을 선택할 필요가 없습니다. 반면 리전 서비스는 각 리전마다 독립적으로 운영되어, 서울 리전에서 만든 리소스는 도쿄 리전에서 보이지 않습니다. 이 차이를 이해하는 것이 AWS 아키텍처 설계의 기본입니다. 다음 코드를 살펴봅시다. ```javascript // Node.js에서 글로벌 서비스와 리전 서비스 사용하기 const AWS = require('aws-sdk'); // IAM은 글로벌 서비스 - 리전 지정 불필요 const iam = new AWS.IAM(); // 리전 파라미터 없음 // 모든 IAM 사용자 조회 (전 세계 공통) iam.listUsers({}, (err, data) => { if (err) console.error(err); else console.log('IAM 사용자:', data.Users); // 어느 리전에서 조회해도 동일한 결과 }); // S3도 글로벌 네임스페이스를 사용하지만 버킷은 리전에 속함 const s3 = new AWS.S3(); // 리전 지정 가능하지만 네임스페이스는 전역 // EC2는 리전 서비스 - 반드시 리전 지정 필요 const ec2Seoul = new AWS.EC2({ region: 'ap-northeast-2' }); const ec2Tokyo = new AWS.EC2({ region: 'ap-northeast-1' }); // 각각 독립적인 리소스 목록 반환 ``` 김클라우드 씨는 혼란스러웠습니다. EC2를 만들 때는 리전을 신경 써야 했는데, IAM 사용자는 리전과 무관하게 보입니다. 이클라우드 씨가 설명합니다. "AWS 서비스는 두 가지 종류로 나뉘어요. 이것을 이해하면 많은 것이 명확해집니다." 글로벌 서비스란 무엇일까요? 쉽게 비유하자면, 글로벌 서비스는 마치 전국구 신분증과 같습니다. 주민등록증은 서울에서 발급받아도 부산에서도 그대로 사용할 수 있습니다. 전국 어디서나 동일한 정보가 조회됩니다. IAM도 마찬가지입니다. 한 번 만든 사용자는 모든 리전에서 동일하게 인식됩니다. 대표적인 글로벌 서비스는 무엇이 있을까요? 첫째는 **IAM(Identity and Access Management)**입니다. 사용자, 역할, 정책을 관리하는 서비스입니다. 보안 관련 설정이므로 전 세계적으로 통일되어야 합니다. 김클라우드 씨가 만든 IAM 사용자는 서울 리전의 EC2에도, 도쿄 리전의 RDS에도 동일한 권한으로 접근할 수 있습니다. 둘째는 **CloudFront**입니다. 이것은 CDN(콘텐츠 전송 네트워크) 서비스입니다. 전 세계에 분산된 엣지 로케이션을 통해 콘텐츠를 빠르게 전달합니다. 본질적으로 글로벌 서비스이므로, 리전을 선택할 필요가 없습니다. 셋째는 **Route 53**입니다. DNS 관리 서비스입니다. 도메인 이름을 IP 주소로 변환하는 작업은 전 세계 어디서나 동일해야 하므로 글로벌 서비스입니다. example.com이라는 도메인은 한국에서 봐도, 미국에서 봐도 같은 IP를 가리켜야 합니다. 그렇다면 리전 서비스는 무엇일까요? 리전 서비스는 마치 지역 은행 지점의 금고와 같습니다. 강남지점 금고에 넣은 물건은 분당지점 금고에서 볼 수 없습니다. 각 지점이 독립적으로 운영되는 것입니다. 대표적인 리전 서비스는 무엇이 있을까요? **EC2**는 가장 대표적인 리전 서비스입니다. 서울 리전에서 만든 인스턴스는 서울 리전에만 존재합니다. 도쿄 리전으로 가면 보이지 않습니다. 각 리전의 데이터센터에 물리적으로 존재하기 때문입니다. **RDS** 데이터베이스도 리전 서비스입니다. 서울 리전에 만든 MySQL 데이터베이스는 서울 데이터센터에 있습니다. 이것을 도쿄에서 접근하려면 인터넷을 통해 연결해야 하고, 지연시간이 발생합니다. **Lambda** 함수도 리전 서비스입니다. 같은 코드라도 각 리전에 따로 배포해야 합니다. 서울 리전의 Lambda 함수는 서울 리전의 다른 서비스와 빠르게 통신할 수 있지만, 도쿄 리전의 서비스와는 느립니다. **S3**는 특별한 경우입니다. S3 버킷 이름은 **전 세계적으로 고유**해야 합니다. "my-bucket"이라는 이름을 누군가 이미 사용했다면, 다른 리전에서도 그 이름을 사용할 수 없습니다. 하지만 버킷 자체는 특정 리전에 속합니다. 서울 리전에 만든 버킷은 서울 데이터센터에 저장됩니다. 실제 현업에서는 어떻게 활용할까요? 이클라우드 씨가 경험담을 들려줍니다. "우리가 글로벌 서비스를 출시할 때, 서울과 버지니아 두 리전에 인프라를 구축했어요. EC2, RDS, Lambda는 각 리전에 따로 만들었죠. 하지만 IAM 사용자와 정책은 한 번만 만들면 두 리전에서 모두 사용할 수 있었어요." 왜 이렇게 구분했을까요? 글로벌 서비스는 전 세계에서 일관되어야 하는 것들입니다. 보안 설정, DNS, 콘텐츠 배포 같은 것들이죠. 반면 리전 서비스는 물리적 위치가 중요한 것들입니다. 컴퓨팅, 스토리지, 데이터베이스처럼 실제 데이터가 저장되고 처리되는 서비스들입니다. 주의할 점이 있습니다. IAM 같은 글로벌 서비스를 변경하면 전 세계 모든 리전에 즉시 반영됩니다. IAM 사용자를 삭제하면, 그 사용자는 어떤 리전에서도 더 이상 접근할 수 없습니다. 실수로 중요한 권한을 삭제하면 전체 시스템에 영향을 줄 수 있으니 신중해야 합니다. 또 하나 팁이 있습니다. AWS 콘솔에서 글로벌 서비스를 사용할 때는 오른쪽 상단의 리전 선택이 "Global" 또는 비활성화됩니다. IAM 화면을 열어보면 리전을 선택할 수 없습니다. 이것이 글로벌 서비스라는 신호입니다. 김클라우드 씨가 정리합니다. "그러니까 사용자 인증 같은 보안 관련은 글로벌 서비스고, 실제 서버와 데이터는 리전 서비스군요. 이제 왜 IAM이 모든 리전에서 보였는지 이해됐어요!" 이클라우드 씨가 마지막 조언을 합니다. "아키텍처를 설계할 때 이 차이를 꼭 기억하세요. 글로벌 서비스는 한 번만 설정하면 되지만, 리전 서비스는 각 리전마다 구축해야 합니다. 이것을 놓치면 나중에 큰 일 납니다." 글로벌 서비스와 리전 서비스의 차이를 이해하면 AWS 아키텍처가 한눈에 들어옵니다. 무엇이 어디에 속하는지 명확히 알고, 그에 맞게 설계하세요. **실전 팁** 💡 - IAM, CloudFront, Route 53는 글로벌 서비스로 리전 선택이 불필요합니다 - EC2, RDS, Lambda는 리전 서비스로 각 리전마다 따로 관리됩니다 - S3 버킷 이름은 전역적으로 고유해야 하지만 버킷 자체는 특정 리전에 속합니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: JavaScript

태그: AWS, Console, Region, AZ, GlobalServices

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS 콘솔과 리전 완벽 가이드

목차

1. AWS 관리 콘솔 둘러보기

2. 서비스 검색과 즐겨찾기

3. 리전 Region 이란

4. 가용 영역 AZ 개념

5. 리전 선택 기준

6. 글로벌 vs 리전 서비스

댓글 (0)

함께 보면 좋은 카드 뉴스

서비스 메시 완벽 가이드

EFK 스택 로깅 완벽 가이드

Grafana 대시보드 완벽 가이드

분산 추적 완벽 가이드

보안 아키텍처 구성 완벽 가이드