AWS는 전 세계 여러 Region에 리소스를 배치한다. 리전 선택에 따라 생성·조회되는 리소스가 달라진다. 서울 리전(ap-northeast-2)에서 생성한 EC2 인스턴스는 오하이오(us-east-2)에서 조회되지 않는다.
리전 변경 방법
콘솔 상단 우측의 리전 이름을 클릭 → 드롭다운에서 원하는 리전 선택.
리전 목록
언어 설정
콘솔이 영어로 보이면 우측 상단 ⚙️ 아이콘 → 언어를 한국어로 변경.
대시보드 활용
각 서비스별로 제공되는 현황판(요약 UI)이다.
대시보드
설명
EC2
인스턴스 상태, 시작/중지, 모니터링 지표
S3
버킷 리스트, 버전 관리, 접근 설정
IAM
사용자, 그룹, 역할, 정책 현황
Billing
월별 사용량, 서비스별 비용, 추세 그래프
3. EC2 서비스 탐색 (콘솔 데모)
EC2(Elastic Compute Cloud)는 AWS의 가상 머신 서비스다.
EC2 인스턴스 = 가상 머신 한 대.
이번 데모에서는 콘솔에서 EC2의 개략적인 메뉴를 살펴봤다. (상세 생성 방법은 차후 강의에서 배운다)
데모 절차
EC2 인스턴스 생성
생성한 인스턴스의 상태 모니터링
인스턴스 정보 확인
인스턴스 종료
인스턴스 시작키 페어 없이 (보안 없이) 진행
인스턴스 생성 완료인스턴트 상세 정보
이제 인스턴스를 종료(삭제)해보자.
인스턴스 삭제 (중지가 아님!!)삭제 완료!
💡 실습 중 느낀 점
인스턴스를 생성할 때 "중지(Stop)"와 "종료(Terminate)"의 차이가 헷갈렸다. Stop은 일시 정지(EBS 볼륨 유지, 재시작 가능)이고, Terminate는 완전 삭제(기본적으로 EBS 볼륨도 함께 삭제)다. 실수로 Terminate를 누르면 복구가 안 되므로 주의가 필요하다.
인스턴스 생성 직후 상태가 pending → running으로 바뀌는 데 약간의 시간이 걸린다. 처음엔 생성이 안 된 줄 알고 새로고침을 반복했는데, 상태 전환 중이었다.
리전을 서울(ap-northeast-2)로 설정하고 인스턴스를 생성했는데, 다른 리전으로 전환하니 인스턴스 목록이 비어 있었다. 리전별로 리소스가 완전히 분리된다는 점을 직접 체감했다.
4. S3 서비스 탐색 (콘솔 데모)
S3(Simple Storage Service)는 AWS의 클라우드 스토리지 서비스다.
버킷을 생성하고, 버킷에 파일(객체)을 저장하는 구조.
Simple — 간편한 인터페이스
Storage — 클라우드 저장 공간
Service — 웹 서비스 형태
데모 절차
S3 버킷 생성
생성한 버킷 정보 조회
S3 버킷 삭제
EC2처럼 검색 후 만들기퍼블릭 엑세스를 일부러 해제하고 생성해본다.생성 완료 후 속성에서 ARN을 확인할 수 있다.퍼블릭 엑세스를 차단하지 않았다
사진 객체 업로드
업로드 후, 객체 URL에 접근하려고 했으나 권한이 없어 접근이 제한된다.
즉, 퍼블릭 엑세스를 허용한다고 해서 누구나 접근할 수 있다는 것이 아니다.
버킷 정책에서 접근 권한을 편집 할 수 있다.
위와 같이 작성한 후 변경사항 저장이후 접근 성공!!
삭제는 버킷 내의 모든 객체를 지운 후 버킷을 삭제해야한다.
삭제 완료
💡 실습 중 느낀 점
S3 버킷 이름은 전 세계적으로 고유(globally unique)해야 한다. 흔한 이름(예: test-bucket)으로 시도하면 이미 누군가 사용 중이라 생성이 거부된다. 팁: 자기 이름이나 날짜를 조합하면 중복을 피할 수 있다.
버킷을 삭제하려면 버킷 안의 모든 객체를 먼저 비워야 한다. 객체가 남아 있는 상태에서 삭제를 시도하면 오류가 발생한다. 콘솔에서 "버킷 비우기(Empty)" → "버킷 삭제(Delete)" 순서로 진행해야 한다.
EC2와 달리 S3는 리전을 선택해도 콘솔에서는 전체 버킷이 보인다. 다만 버킷 자체는 생성 시 지정한 리전에 물리적으로 저장된다. 글로벌 서비스처럼 보이지만 실제 데이터는 특정 리전에 귀속되는 구조다.
퍼블릭 엑세스를 차단하지 않은것은 누구나 사용할수 있는 권한을 주었다는게 아니라, 누구나 사용할 수 있는 권한을 부여받을 수 있다는 것이므로 헷갈리지 않아야한다.
5. IAM 서비스 탐색 (콘솔 데모)
IAM(Identity and Access Management)은 AWS 리소스에 대한 접근 권한을 제어하는 서비스다.
데모 절차
IAM User 정보 조회
IAM Group과 IAM Role 조회
IAM Policy 조회
아직 아무 유저도 없다.
유저가 없으니 당연히 그룹도 없다. 역할과 정책을 조회해보자.
몇 개 기본적인 역할이 조회됐다.
역할은 정책을 가지고있는 "모자"같은 느낌으로, 유저에게 "씌워준다"
정책을 조회해보자.
많은 양의 정책이 조회됐다.
💡 실습 중 느낀 점
IAM은 리전에 종속되지 않는 글로벌 서비스다. 리전을 변경해도 동일한 User, Group, Role, Policy가 보인다. EC2처럼 리전별로 분리되는 서비스와 구분해서 이해해야 한다.
Root User와 IAM User의 차이가 중요하다. Root User는 모든 권한을 가진 계정 소유자이고, IAM User는 필요한 권한만 부여받는 하위 사용자다. 보안 관점에서 일상 작업에는 Root User를 쓰지 말고 IAM User를 생성해서 사용하는 것이 best practice다.
Policy 목록을 보니 AWS에서 기본 제공하는 managed policy가 수백 개 있었다. AmazonS3ReadOnlyAccess, AmazonEC2FullAccess 같은 식으로 이름만 봐도 어떤 권한인지 직관적으로 파악할 수 있다.
6. AWS CLI와 CloudShell
AWS CLI란?
AWS 리소스를 명령어로 제어하는 CLI 도구다. 콘솔(GUI) 없이 터미널에서 직접 리소스를 생성, 관리, 모니터링할 수 있다.
스크립트 자동화, 반복 작업, 대규모 리소스 관리에 유리하다.
AWS CloudShell
브라우저에서 직접 실행할 수 있는 AWS CLI 전용 터미널 환경이다.
별도 설치 없이 콘솔 상단의 CloudShell 아이콘을 클릭하면 바로 사용 가능.
터미널 실행
7. AWS CLI 데모 — S3, EC2, IAM 조회
S3 버킷 조회
# 전체 버킷 목록
aws s3 ls
# 특정 버킷 내 객체 목록
aws s3 ls s3://버킷이름
# 하위 디렉터리까지 조회
aws s3 ls s3://버킷이름/folder-name/
# 버킷의 리전 조회
aws s3api get-bucket-location --bucket 버킷이름
당연히 ec2인스턴스도 조회가 되지 않을 줄 알았는데, 아까 삭제했던 인스턴스가 조회되었다.
너무 긴 json 코드가 나오길래, id만 조회해보았다.
짧고 굵게 나온다!
IAM 정보 조회
aws iam list-users # User 목록
aws iam list-groups # Group 목록
aws iam list-roles # Role 목록
aws iam list-policies # Policy 목록
마찬가지로 아무것도 안뜸
역할과 정책 대한 json 코드가 마구마구;;
조회된 코드가 너무 많아서 일부만 가져왔다.
💡 실습 중 느낀 점
aws ec2 describe-instances를 옵션 없이 실행하면 JSON이 수백 줄 쏟아진다. --query와 --output text 조합이 필수다. 실무에서는 jq를 파이프로 연결해서 파싱하는 경우도 많다.
CloudShell은 콘솔에 로그인한 사용자의 권한을 그대로 상속한다. 별도로 aws configure를 할 필요가 없어서 편하다. 반면 로컬 CLI는 Access Key를 직접 설정해야 하므로 보안 리스크가 있다.
aws ec2 describe-instances --region us-east-1처럼 --region 플래그를 붙이면 CloudShell의 기본 리전과 다른 리전의 리소스도 조회할 수 있다. 콘솔에서는 리전 드롭다운을 바꿔야 하는 반면, CLI는 한 줄로 여러 리전을 순회할 수 있어서 자동화에 유리하다.
aws s3 ls와 aws s3api list-buckets는 비슷한 결과를 주지만, s3 커맨드는 고수준(파일 복사, 동기화 등), s3api는 저수준(API 직접 호출) 인터페이스다. 상황에 따라 구분해서 쓴다.
