첫 실습 전에 해야 할 일
AWS 실습은 클릭 몇 번으로 서버, 데이터베이스, 네트워크를 만들 수 있다는 점이 매력입니다. 하지만 이 말은 반대로, 클릭 몇 번으로 외부에 열린 서버를 만들거나 예상하지 못한 비용을 만들 수도 있다는 뜻입니다. 그래서 AWS를 배우는 첫 단계는 EC2 서버를 만드는 일이 아니라 안전한 계정과 비용 방어선을 먼저 만드는 일입니다.
이번 장의 목표는 간단합니다. 앞으로 실습할 수 있는 AWS 계정을 준비하되, 루트 사용자를 함부로 쓰지 않고, 로그인 보안을 강화하며, 비용 알림을 미리 켜 두는 것입니다. 실습 환경을 집으로 비유하면, 서버를 들여놓기 전에 현관 자물쇠와 전기요금 알림부터 설치하는 셈입니다.
AI 생성 이미지
루트 사용자는 집주인 열쇠다
AWS 계정을 처음 만들 때 사용하는 이메일과 비밀번호는 루트 사용자에 해당합니다. 루트 사용자는 계정의 최상위 권한을 가진 사용자입니다. 결제 정보 변경, 계정 해지, 모든 서비스 접근처럼 매우 강한 작업을 할 수 있습니다.
이 권한은 편리하지만 위험합니다. 루트 사용자 정보가 노출되면 계정 전체가 위험해집니다. 그래서 루트 사용자는 평소 실습에 사용하지 않는 것이 원칙입니다. 루트 사용자는 계정 생성 직후 보안 설정을 할 때, 결제나 계정 자체와 관련된 꼭 필요한 작업을 할 때만 사용하고, 이후에는 일반 작업용 접근 방식을 따로 준비합니다. AWS도 루트 사용자는 꼭 필요한 작업에만 사용하고, 일상 작업에는 별도의 관리자 사용자나 역할을 사용하라고 권장합니다.1
일반 작업에는 IAM 사용자, IAM 역할, 또는 실무에서 여러 계정을 다룰 때 자주 쓰는 IAM Identity Center 사용자를 사용할 수 있습니다. IAM은 Identity and Access Management의 약자로, "누가 어떤 AWS 작업을 할 수 있는지" 정하는 권한 관리 서비스입니다. IAM과 역할은 다음 장에서 자세히 다루므로, 여기서는 한 가지만 기억하면 됩니다.
루트 사용자는 보관용 열쇠이고, 실습은 별도의 작업용 접근 방식으로 한다.
초보자는 처음에 루트 사용자로 계속 로그인하고 싶어집니다. 권한 오류가 덜 나기 때문입니다. 하지만 권한 오류는 배움의 일부입니다. 반대로 루트 사용자를 계속 쓰는 습관은 실제 운영 환경에서 큰 사고로 이어질 수 있습니다. 특히 루트 사용자용 액세스 키를 만들어 CLI나 프로그램에서 사용하는 일은 피해야 합니다. 루트 사용자 액세스 키는 계정 전체를 움직일 수 있는 만능 열쇠에 가깝기 때문입니다.
기본 보안 체크리스트
계정을 만든 직후에는 다음 설정을 먼저 확인합니다.
1. 루트 사용자에 MFA 설정하기
MFA는 Multi-Factor Authentication의 약자로, 비밀번호 외에 추가 인증을 한 번 더 요구하는 방식입니다. 예를 들어 로그인할 때 비밀번호를 입력한 뒤 휴대폰 인증 앱의 6자리 코드를 추가로 입력하거나, 보안 키 또는 패스키로 한 번 더 확인합니다.
비밀번호는 유출될 수 있습니다. 같은 비밀번호를 다른 사이트에서 썼다면 더 위험합니다. MFA를 켜 두면 비밀번호가 노출되더라도 공격자가 바로 로그인하기 어렵습니다. AWS 계정에서는 루트 사용자에 MFA를 반드시 설정한다고 생각해야 합니다. 가능하면 피싱에 강한 보안 키나 패스키를 사용하고, 여의치 않다면 인증 앱을 사용하는 것만으로도 큰 도움이 됩니다.
일반적인 흐름은 다음과 같습니다.
AWS Management Console에 루트 사용자로 로그인합니다.
오른쪽 위 계정 메뉴에서 Security credentials 또는 보안 자격 증명 화면으로 이동합니다.
Multi-factor authentication (MFA) 항목에서 MFA 장치를 등록합니다.
패스키, 보안 키, 인증 앱, 하드웨어 토큰 중 사용할 방식을 연결합니다.
등록이 끝나면 로그아웃 후 다시 로그인해 MFA가 요구되는지 확인합니다.
가능하면 루트 사용자뿐 아니라 앞으로 만들 관리자용 IAM 사용자에도 MFA를 적용합니다. 로컬 PC에서 AWS CLI를 사용할 때도 장기 액세스 키를 무심코 저장하기보다 MFA 기반 임시 자격 증명을 사용하는 편이 안전합니다. AWS CLI는 명령어로 AWS 리소스를 직접 만들고 삭제할 수 있으므로, 콘솔만큼이나 인증 관리가 중요합니다.
2. 강력한 비밀번호와 별도 보관
루트 사용자 비밀번호는 다른 서비스와 공유하지 않습니다. 길고 예측하기 어려운 비밀번호를 사용하고, 가능하면 비밀번호 관리 도구에 보관합니다. "회사명+연도+!"처럼 추측 가능한 패턴은 피해야 합니다.
또 하나 중요한 점은 복구 수단입니다. 루트 사용자 이메일과 계정에 등록된 전화번호에 접근할 수 있어야 합니다. MFA 장치를 잃어버렸을 때 계정을 복구하려면 이메일과 전화번호가 필요할 수 있기 때문입니다. 학습용 계정이라도 가입 후 연락처 정보가 맞는지 한 번 확인해 두는 것이 좋습니다.
IAM 사용자에도 비밀번호 정책을 적용할 수 있습니다. 비밀번호 길이, 복잡도, 만료 여부 같은 규칙을 정하는 기능입니다. 학습용 계정이라도 최소한 긴 비밀번호와 MFA는 기본으로 생각해야 합니다.
3. 루트 사용자 액세스 키 만들지 않기
AWS에는 콘솔 로그인용 비밀번호와 별개로, 프로그램이나 CLI에서 사용하는 액세스 키가 있습니다. 액세스 키는 자동화에 필요할 때가 있지만, 루트 사용자용 액세스 키는 만들지 않는 것이 원칙입니다. 루트 사용자 권한은 너무 강해서, 키가 유출되면 공격자가 거의 모든 리소스를 만들고 삭제할 수 있습니다.
실습 중 CLI가 필요하다면 루트 사용자 키를 만들기보다 IAM 사용자, IAM 역할, CloudShell, 임시 자격 증명 같은 안전한 방법을 사용합니다. 다음 장 이후에 권한을 나눠 쓰는 방법을 배우면 이 원칙이 더 자연스럽게 이해될 것입니다.
4. 계정 별칭 만들기
AWS 콘솔에서 IAM 사용자로 로그인할 때는 계정 ID가 들어간 로그인 주소를 사용할 수 있습니다. 계정 ID는 숫자로 되어 있어 외우기 어렵습니다. 계정 별칭을 만들면 IAM 사용자 로그인 주소를 더 읽기 쉬운 형태로 바꿀 수 있습니다.
예를 들어 my-study-account 같은 별칭을 만들면, 나중에 여러 계정을 구분할 때 도움이 됩니다. 실무에서는 개발용, 테스트용, 운영용 계정을 나누는 경우가 많습니다. 초보 단계에서도 계정 이름을 명확히 정하는 습관은 좋습니다.
단, 계정 별칭은 보안 기능이라기보다 식별을 돕는 기능입니다. 별칭을 만들었다고 계정이 안전해지는 것은 아닙니다. 또한 루트 사용자는 기본적으로 이메일 주소로 로그인하므로, 계정 별칭은 주로 IAM 사용자 로그인 주소를 보기 쉽게 만드는 설정이라고 이해하면 됩니다. 핵심은 여전히 MFA와 권한 관리입니다.
프리 티어는 무제한 무료가 아니다
AWS를 처음 배우는 사람은 "프리 티어니까 무료겠지"라고 생각하기 쉽습니다. 하지만 프리 티어는 정해진 조건 안에서만 무료입니다. 서비스마다 무료 범위, 기간, 사용량 기준이 다르고, 계정을 언제 만들었는지에 따라서도 적용 방식이 달라질 수 있습니다.
특히 2025년 7월 이후 새로 AWS 계정을 만드는 사용자는 가입 과정에서 무료 계정 플랜 또는 유료 계정 플랜을 선택할 수 있습니다. 무료 계정 플랜은 일정 기간과 크레딧 범위 안에서 AWS를 체험하도록 설계되어 있으며, 크레딧을 모두 쓰거나 무료 기간이 끝나면 계속 사용하기 위해 유료 플랜으로 전환해야 합니다. 반대로 유료 계정 플랜을 선택했거나, 기존 방식의 프리 티어가 적용되는 계정이거나, 이미 유료 플랜으로 업그레이드한 계정이라면 사용량과 서비스 조건에 따라 요금이 청구될 수 있습니다.2
정리하면, 프리 티어를 "아무거나 만들어도 절대 돈이 안 나가는 상태"로 이해하면 안 됩니다. 프리 티어는 초보자가 안전하게 시작하도록 돕는 장치이지만, 영구 무제한 이용권은 아닙니다. 콘솔의 결제 화면, 크레딧 화면, 프리 티어 사용량 화면에서 내 계정에 어떤 조건이 적용되는지 직접 확인하는 습관이 필요합니다.
비용이 발생하거나 크레딧이 빠르게 소진되는 대표 사례는 다음과 같습니다.
무료 범위를 넘겨 EC2 인스턴스를 오래 켜 둔 경우
프리 티어 또는 무료 플랜에서 허용하지 않는 인스턴스 유형을 선택한 경우
RDS 데이터베이스를 만들고 삭제하지 않은 경우
EBS 볼륨, 스냅샷, Elastic IP 같은 부가 리소스를 남겨 둔 경우
NAT Gateway, Load Balancer처럼 시간 단위 과금이 있는 서비스를 만든 경우
S3에 많은 파일을 저장하거나 요청 수가 늘어난 경우
다른 리전에서 만든 리소스를 잊고 방치한 경우
여기서 중요한 점은 "서버를 껐다"와 "비용이 완전히 멈췄다"가 항상 같지 않다는 것입니다. 예를 들어 EC2 인스턴스를 중지하면 컴퓨팅 비용은 멈출 수 있지만, 연결된 디스크인 EBS 볼륨 비용은 계속 발생할 수 있습니다. 스냅샷, 공인 IP 주소, 데이터베이스도 마찬가지입니다. 사용하지 않는 실습 리소스는 중지가 아니라 삭제까지 확인해야 합니다.
실습할 때는 한 리전을 정해 두는 것이 좋습니다. 예를 들어 서울 리전에서 실습하기로 했다면, 콘솔 오른쪽 위 리전 선택이 계속 서울인지 확인합니다. 리전을 바꿔 가며 실습하면 어디에 무엇을 만들었는지 놓치기 쉽습니다.
비용 알림은 실습 전 켜 둔다
비용 관리는 나중에 하는 일이 아닙니다. 첫 EC2를 만들기 전에 설정해야 합니다. AWS에는 예상치 못한 과금을 줄이기 위한 여러 도구가 있습니다. 초보자는 먼저 AWS Budgets를 설정하면 됩니다.
AWS Budgets는 한 달 예산을 정하고, 실제 비용이나 예상 비용이 기준에 가까워지면 이메일로 알려 주는 서비스입니다. 예를 들어 월 예산을 5달러 또는 10달러로 정하고, 50%, 80%, 100%에 도달할 때 알림을 받을 수 있습니다. 새 프리 티어 무료 계정 플랜을 쓰는 경우에도 크레딧과 무료 기간 알림을 확인해야 하고, 유료 플랜이나 기존 계정으로 실습한다면 Budgets는 더욱 중요합니다.
기본 설정 흐름은 다음과 같습니다.
AWS 콘솔 검색창에서 Budgets를 검색합니다.
Billing and Cost Management 영역의 Budgets로 이동합니다.
새 예산을 만들고, 처음에는 템플릿의 월별 비용 예산 또는 비용 예산(Cost budget)을 선택합니다.
기간은 월별, 예산 방식은 고정 금액으로 설정합니다.
학습용 계정에 맞는 작은 금액을 입력합니다.
실제 비용 또는 예상 비용 기준으로 50%, 80%, 100% 같은 알림 기준을 추가합니다.
이메일 주소를 입력하고, SNS 토픽을 연결했다면 구독 확인 메일이 필요한지 확인합니다.
예산 금액은 사람마다 다릅니다. 중요한 것은 금액 자체보다 "비용이 커지기 전에 알아차리는 구조"를 만드는 것입니다. 실습용 계정이라면 처음에는 낮은 금액으로 시작하는 편이 안전합니다.
다만 Budgets 알림은 브레이크가 아니라 경고등에 가깝습니다. 알림이 왔다고 해서 리소스가 자동으로 삭제되거나 모든 과금이 즉시 멈추는 것은 아닙니다. 알림을 받으면 바로 결제 대시보드와 각 리전의 리소스를 확인하고, 쓰지 않는 리소스를 정리해야 합니다.
또한 결제 화면에서 프리 티어 사용량, 크레딧 잔액, 결제 알림을 확인할 수 있는지 살펴봅니다. 일부 알림은 계정 유형이나 설정 방식에 따라 보이는 위치가 다를 수 있습니다. 메뉴 이름이 조금 달라도 당황하지 말고, Billing and Cost Management 안에서 Budgets, Credits, Free Tier, Billing preferences 같은 항목을 차례로 확인하면 됩니다.
콘솔, CLI, CloudShell은 역할이 다르다
AWS를 조작하는 방법은 여러 가지입니다. 처음부터 모두 익힐 필요는 없습니다. 역할을 구분하면 부담이 줄어듭니다.
AWS Management Console은 웹 브라우저에서 사용하는 화면입니다. 버튼과 메뉴로 서비스를 만들고 확인할 수 있어 초보자에게 가장 적합합니다. 처음에는 콘솔로 리소스가 어떻게 생겼는지 눈으로 확인하는 것이 좋습니다.
AWS CLI는 Command Line Interface의 약자로, 터미널에서 명령어로 AWS를 조작하는 도구입니다. 반복 작업과 자동화에 강합니다. 예를 들어 콘솔에서 여러 번 클릭해야 하는 작업을 명령어 한 줄로 실행할 수 있습니다. 하지만 로컬 PC에 자격 증명을 설정해야 하므로 보안 관리가 필요합니다. 액세스 키를 아무 파일에나 저장하거나 GitHub 같은 공개 저장소에 올리는 일은 절대 피해야 합니다. 특히 루트 사용자 액세스 키는 만들지 않는 것이 원칙입니다.
AWS CloudShell은 AWS 콘솔 안에서 바로 열 수 있는 브라우저 기반 터미널입니다. 로컬 PC에 CLI를 설치하지 않아도 AWS 명령어를 실행할 수 있습니다. 초보자가 CLI 맛을 보기 좋습니다. 다만 CloudShell도 권한은 로그인한 사용자 권한을 따릅니다. 관리자 권한으로 로그인했다면 CloudShell에서도 강한 작업을 할 수 있습니다.
추천 순서는 다음과 같습니다.
콘솔로 먼저 익힌다. 서비스의 화면, 이름, 리전 위치를 눈에 익힌다.
CloudShell로 간단한 조회 명령을 실행한다. 예를 들어 현재 계정 정보나 S3 버킷 목록을 확인한다.
CLI는 필요한 시점에 설치한다. 자동화나 인프라 코드 실습에 들어갈 때 차근차근 사용한다.
처음부터 CLI만 사용하면 AWS가 머릿속에 잘 그려지지 않을 수 있습니다. 반대로 콘솔만 사용하면 반복 작업이 번거로워집니다. 이 책에서는 먼저 콘솔로 구조를 이해하고, 필요한 곳에서 CloudShell과 CLI를 연결해 갈 것입니다.
실습용 계정 준비 순서
이 장의 내용을 실제 순서로 정리하면 다음과 같습니다.
AWS 계정을 만들고, 학습 목적이라면 무료 계정 플랜을 선택할 수 있는지 확인한다.
루트 사용자 이메일, 연락처, 결제 정보를 확인한다.
루트 사용자에 강력한 비밀번호를 설정한다.
루트 사용자에 MFA를 등록한다.
루트 사용자 액세스 키를 만들지 않는다. 이미 있다면 사용 여부를 확인하고 삭제를 검토한다.
필요하다면 계정 별칭을 만든다.
일상 작업용 IAM 사용자, IAM 역할, 또는 IAM Identity Center 기반 접근 방식을 준비한다.
관리자 권한이 필요하더라도 루트가 아닌 작업용 접근 방식으로 실습한다.
AWS Budgets로 낮은 월 예산과 이메일 알림을 설정한다.
프리 티어 사용량, 크레딧 잔액, 결제 알림을 확인한다.
실습 리전을 하나 정하고, 리소스를 만든 뒤 삭제하는 습관을 들인다.
이 준비가 끝나면 AWS를 배울 기본 안전장치가 마련됩니다. 완벽한 보안은 아니지만, 초보 단계에서 가장 흔한 사고를 줄이는 데 충분히 도움이 됩니다.
다음 장에서는 여기서 언급한 IAM을 본격적으로 다룹니다. 사용자를 만들고, 권한을 붙이고, "필요한 만큼만 허용한다"는 원칙을 실제 예시로 이해해 보겠습니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.