1. 실습 1: EC2 인스턴스 생성 및 Git-Bash 원격 접속 (SSH)
1) 인스턴스 생성 및 정보 확인
- AWS 콘솔 설정: 리전을 서울로 변경 후 EC2 서비스/대시보드 진입 ▶️ [인스턴스 시작].
- 인스턴스 세부 설정:
- 이름 및 태그: [임의의 인스턴스명 입력]
- 애플리케이션 및 OS 이미지(AMI): Ubuntu (데비안 계열 리눅스 OS)
- 인스턴스 유형: t3 계열 중 원하는 사양 선택 (예: t3.micro 등)
- 키페어(로그인) 생성:
- 키페어 이름: [임의의 이름 입력]
- 키 페어 유형: RSA(비대칭키 암호화 방식)
- 프라이빗 키 파일 형식: .pem ▶️ 생성 시 PC에 .pem 파일 다운로드됨.
- 💡Tip! [키 페어 생성] 버튼을 누르면 PC에 .pem 파일이 자동으로 다운로드된다. 이 파일은 서버 접속 시 필수적이므로 안전한 곳에 보관 필수.
- 네트워크 및 스토리지 설정: 나머지는 기본값 그대로 유지다.
- 인스턴스 정보 확인: 인스턴스 대시보드 들어가기 (생성화면 그대로라면 [모든 인스턴스 보기] 클릭)
- 방금 만든 인스턴스를 선택한 후, 하단 탭에서 다음 주요 정보들을 확인할 수 있다.
- 세부 정보: 이후 원격 접속에 사용될 *퍼블릭 IPv4 주소를 확인하고 복사할 수 있음.
- 네트워킹: 적용된 보안 그룹과 네트워크 인터페이스 정보를 확인 가능.
- 모니터링: CPU 사용량 등 인스턴스의 상태 그래프를 볼 수 있음.
- 방금 만든 인스턴스를 선택한 후, 하단 탭에서 다음 주요 정보들을 확인할 수 있다.
✨ 퍼블릭 IP과 프라이빗 IP 설명
1) 퍼블릭 IP (공인 IP)
- 개념: 전 세계 인터넷망에서 유일하게 식별되는 실제 주소.
- 특징:
- 인터넷 서비스 제공업체(ISP)로부터 할당받으며, 외부에 공개되어 있기 때문에 전 세계 어디서나 이 주소를 통해 해당 서버나 기기에 접속할 수 있다.
- 예를 들어, 웹사이트를 서핑하거나 AWS EC2 인스턴스를 생성해서 외부에 서비스할 때 사용하는 주소가 바로 퍼블릭 IP.
2) 프라이빗 IP (사설 IP)
- 개념: 공유기 밑에 연결된 컴퓨터, 스마트폰처럼 특정 사설 네트워크(내부망) 안에서만 공유되는 가짜 주소.
- 특징:
- 외부 인터넷망에서는 이 프라이빗 IP로 직접 접근할 수 없다.
- 대신 사설망 내부의 기기들끼리 통신할 때(예: 회사 내부 프린터 연결, 공유기 내부 기기끼리의 통신) 사용된다.
- 덕분에 한정된 IP 주소를 절약하고 내부 보안을 강화할 수 있음.
💡 퍼블릭 IP 주소를 가진 서버와 '비대칭키'의 관계
퍼블릭 IP를 가진 EC2 서버에 Git-Bash로 원격 접속(SSH)을 할 때 이 비대칭키 암호화가 사용된다.
- 키페어 생성: EC2를 만들 때 [파일 이름].pem 같은 비대칭키(RSA 방식) 파일이 생성.
- 비밀번호 없는 인증: 이 .pem 파일 안에는 개인키(Private Key)가 들어있고, AWS 서버 안에는 공개키(Public Key)가 심어진다.
- 🔑 AWS SSH 접속과 암호화 원리:
- AWS에서 Ubuntu 인스턴스를 생성하면 SSH 접속을 위해 비대칭키 암호화 방식을 사용한다.
- 일반적인 비대칭키 구조: 다수가 퍼블릭키(공개키)를 가지고, 단 한 명만 프라이빗키(개인키)를 소유.
- AWS EC2 접속 관점: AWS가 퍼블릭키를 가지고 있으며, 사용자(개발자)가 프라이빗키(.pem 파일)를 로컬에 보관하고 접속을 요청하는 형태.
- 🔑 AWS SSH 접속과 암호화 원리:
- 안전한 접속: 원격 접속하는 ssh 명령어를 입력하면, 내 PC의 개인키와 서버의 공개키가 서로를 검증(비대칭키 암호화 매커니즘)하여 비밀번호 입력 없이도 해킹 위험 없는 안전한 암호화 터널을 만들어 접속하게 되는 것.
ℹ️ 퍼블릭/프라이빗 IP와의 차이점
퍼블릭/프라이빗 IP: 인터넷에서 찾아가기 위한 네트워크 주소
공개키(Public)/개인키(Private): 그 주소에 있는 서버와 안전하게 데이터를 주고받기 위한 암호화 도구(키)
2) 원격 접속 (Git-Bash)
- 다운로드된 .pem 파일이 있는 폴더에서 마우스 우클릭 ▶️ Open Git Bash Here.
- 명령어 입력: ssh -i ./[키 페어 이름].pem ubuntu@[인스턴스의 퍼블릭 IPv4 주소]
- 처음 접속 시 연결 확인 문구가 뜨면 yes 입력 후 진입.
- 이후 추가 실습할 명령어 목록은 여기서 참고.
$ ssh -i ./[키 페어 이름].pem ubuntu@[인스턴스의 퍼블릭 IPv4 주소]
ℹ️ 실습 내용 예시
1) vi 로 문서 편집
- touch [파일명.txt]: 빈 텍스트 파일 생성 명령어.
- ls -al: 숨김 파일을 포함한 현재 폴더의 모든 파일 목록 상세 출력
- vi ./[파일명.txt]: vi 편집기로 파일 열기 (현재 디렉토리)
- i 키: 입력(Insert) 모드 전환
- ESC 키: 입력 모드 종료 (명령 모드로 복귀)
- :wq 입력 후 엔터: 저장(write)하고 종료(quit)
- cat ./[파일명.txt]: 현재 디렉토리에서 파일 내용을 터미널 창에 출력
$ touch helloworld.txt
$ ls -al
$ vi ./helloworld.txt
...
$ cat ./helloworld.txt
2) ifconfig 실행
- sudo: 앞에 붙여 관리자(루트) 권한으로 실행
- apt: 패키지 매니저, 이것을 통해 우분투 저장소로부터 프로그램을 다운로드하고 설치.
- net-tools: 네트워크 관리 도구 모음인 net-tools 패키지
- ifconfig: 현재 서버(인스턴스)에 설정된 네트워크 인터페이스 정보를 확인하는 명령어. (net-tools 설치 필수)
- 현재 서버가 사용 중인 IP 주소(IPv4, IPv6), 서브넷 마스크, MAC 주소 및 네트워크 카드의 상태와 데이터 송수신 패킷 상태 등을 한눈에 파악할 수 있다.
- 💡 최신 우분투(Ubuntu) 등 일부 리눅스 배포판에서 기본으로 제공되지 않을 수 있으므로, 먼저 관련 패키지를 설치해야 한다.
$ sudo apt install net-tools
$ ifconfig
2. 실습 2: 네트워크 보안 및 인바운드/아웃바운드 설정
1) 보안 그룹 (Security Group)
- EC2 인스턴스의 앞단을 지키는 가상 방화벽.
- 인바운드(Inbound) 규칙: 외부에서 EC2 인스턴스로 들어오는 패킷을 통제한다. 화이트리스트 방식으로 기본은 다 막혀있으며 허용할 규칙만 지정한다.
- 아웃바운드(Outbound) 규칙: EC2 인스턴스에서 외부로 나가는 패킷을 통제힌다. 기본값으로 모든 트래픽 내보내기(0.0.0.0/0)가 허용되어 있다.
2) 인바운드 규칙 편집 (카프카 및 네트워크 테스트용)
인스턴스의 [보안] 탭 ▶️ 보안 그룹 선택 ▶️ [인바운드 규칙 편집]에서 진행. (추가 후 [규칙 저장] 필수)
- SSH (22번 포트 / 기본): 인스턴스 생성 시 기본 활성화되며, 위치 무관(0.0.0.0/0)으로 열려있어 Git-Bash 접속이 가능했던 것.
- 카프카(Kafka) 통신 포트 추가:
- 유형: 사용자 지정 TCP / 포트 범위: 9092 / 소스: Anywhere-IPv4 (0.0.0.0/0)
- 유형: 사용자 지정 TCP / 포트 범위: 9092 / 소스: Anywhere-IPv6 (::/0)
- 네트워크 연결 확인용 포트 추가 (ICMP):
- 유형: 모든 ICMP - IPv4 / 소스: Anywhere-IPv4
3) ICMP와 Ping 테스트
- ICMP(Internet Control Message Protocol): 네트워크 3계층(네트워크 계층) 프로토콜로, 데이터 전송이 아닌 서버가 살아있는지 동작 여부 및 오류를 확인하는 역할을 한다. (예: 구글 DNS 서버 8.8.8.8 등)
- 테스트: 로컬 PC의 cmd(명령 프롬프트) 창을 켜고 ping [EC2 퍼블릭 IP]를 입력한다.
- 보안 그룹에 ICMP 규칙이 있을 때: 정상적으로 응답 패킷이 돌아온다.
- 보안 그룹에서 ICMP 규칙을 삭제했을 때: 요청 시간이 만료되었다며 응답하지 않는다.
$ ping [EC2 퍼블릭 IP]
3. 실습 3: IAM 사용자 계정 추가 및 자격 증명(Credential) 관리
1) 루트 계정 vs IAM 계정
- 루트(Root) 계정: 이메일 주소로 로그인하는 최고 권한 계정 소유자.
- 결제 및 전체 권한을 가지므로 일상적인 작업 시에는 보안상 사용을 지양해야 한다.
- 콘솔창에 이름과 Account ID(숫자) 형태로 표시된다.
- IAM 계정: 관리자에게 권한을 부여받아 활동하는 개별 사용자 계정.
- 사용자명@계정ID(또는 별칭) 형태로 로그인하며, 개발 및 운영 업무 시 IAM 계정 사용이 강력히 권한 권장된다.
2) IAM 사용자 생성 및 권한 부여 실습
외부 프로그램(Spring Boot, Postman 등)이나 협업 개발자가 AWS 리소스에 접근할 수 있도록 권한이 제한된 개별 계정을 생성하는 과정.
AWS 콘솔 대시보드 좌측 메뉴 [사용자](또는 IAM 사용자) ▶️ 우측 상단 [사용자 생성]에서 진행. (혹은 검색 가능)
- 사용자 세부 정보 지정
- 사용자 이름: [임의의 사용자명 입력] (예: s3-developer)
- 💡 Tip: 프로그램 방식 액세스만 사용할 예정이라면 'AWS 관리 콘솔에 대한 사용자 액세스 권한 제공'은 체크하지 않아도 된다.
- 권한 설정 (직접 정책 연결)
- 권한 설정 방식 중 [직접 정책 연결]을 선택한 후, 유저에게 부여할 권한 정책을 검색하여 체크한다.
- AmazonEC2FullAccess: EC2 인스턴스를 생성, 수정, 삭제하고 관리할 수 있는 전체 권한.
- AmazonS3FullAccess: S3 버킷을 생성하고 파일을 업로드/다운로드하는 등 S3 스토리지에 접근할 수 있는 전체 권한. (Spring Boot에서 이미지 업로드 기능을 구현할 때 필수.)
- 권한 선택이 완료되면 [다음]을 클릭.
- 권한 설정 방식 중 [직접 정책 연결]을 선택한 후, 유저에게 부여할 권한 정책을 검색하여 체크한다.
- 검토 및 사용자 생성 완료
- 설정한 이름과 권한 정책이 맞는지 최종 확인한 후, [사용자 생성]을 클릭하여 완료한다.
⚠️ 다음 단계 주의사항: 사용자가 생성된 후 [보안 자격 증명] 탭에서 액세스 키(Access Key & Secret Key)를 반드시 발급받아야 한다. 이때 다운로드받는 .csv 파일은 다시 열람할 수 없으므로 안전한 곳에 보관해야 한다.
3) 콘솔 액세스 관리 및 IAM 계정 로그인
방금 생성한 IAM 사용자가 AWS 관리 콘솔(웹 화면)에 직접 로그인할 수 있도록 콘솔 접속 권한을 활성화하고 로그인하는 과정.
- 콘솔 액세스 관리 진입
- IAM 사용자 목록 대시보드에서 방금 생성한(혹은 임의의) 사용자를 선택한다.
- [보안 자격 증명] 탭으로 이동한 뒤, 콘솔 액세스 관리 항목에서 [콘솔 액세스 활성화]를 클릭.
- 비밀번호 설정 및 활성화
- 콘솔 액세스: '활성화'를 선택한다.
- 비밀번호 설정 유형 선택:
- 자동 생성된 암호: AWS에서 임의로 복잡한 비밀번호를 만들어줌.
- 사용자 지정 암호: 관리자가 고정된 비밀번호를 직접 지정.
- 💡 Tip: 사용자가 다음 로그인 시 새 암호를 생성하도록 강제하는 옵션은 상황에 따라 체크 여부를 선택한다.
- 자격 증명 .csv 파일 다운로드
- 설정이 완료되면 화면에 로그인 정보가 표시됨. 이때 [반드시 .csv 파일 다운로드] 버튼을 눌러 정보를 PC에 저장 필수. (비밀번호는 이 창을 닫으면 다시 확인할 수 없음.)
- IAM 계정으로 AWS 로그인하기
- 로그인 페이지 접속: 다운로드한 .csv 파일 내부에 적힌 콘솔 로그인 URL 주소로 접속한다.
- 또는 일반 AWS 로그인 창에서 'IAM 사용자'를 선택한 뒤, 메인 도메인 계정 ID인 '12자리 숫자'를 직접 복사해서 붙여넣기.
- 인증 정보 입력: .csv 파일에 명시된 해당 유저의 사용자 이름(Username)과 패스워드(Password)를 입력하면 AWS 로그인 및 콘솔 진입이 완료.
- 로그인 페이지 접속: 다운로드한 .csv 파일 내부에 적힌 콘솔 로그인 URL 주소로 접속한다.
- 부여된 권한 범위 정책(Policy) 내에서 AWS 서비스 및 리소스 관리 기능 수행 가능
4. 액세스 관리 및 애플리케이션(Spring Boot) 연동
1) 프로그램 방식 액세스 (Access Key & Secret Key)
AWS 콘솔 로그인용 ID/비밀번호와 달리, Spring Boot 소스 코드나 Postman 같은 외부 프로그램이 AWS 서비스(예: S3 파일 서버)에 접근할 수 있도록 인증할 때 사용한다.
- IAM 사용자 생성: 위 [3-2) IAM 사용자 생성 및 권한 부여 실습] 참고. 필요한 권한 정책을 직접 연결하여 생성한다.
- 액세스 키 발급: 생성된 IAM 유저의 [보안 자격 증명] 탭 ▶️ [액세스 키 만들기] 진행.
- ⚠️ 다시 한번 주의사항: 발급 시 나오는 Access Key ID와 Secret Access Key가 담긴 .csv 파일은 최초 1회만 다운로드 가능하므로 반드시 PC에 안전하게 보관해야 함.
🚨 AWS에서 IAM 사용자가 삭제되지 않는 원인과 해결책
AWS는 보안과 리소스 유실 방지를 위해, 특정 자격 증명이나 종속된 리소스가 남아있는 IAM 사용자는 삭제 명령을 내려도 거부(Fail)하도록 설계되어 있다.
1) 사용하지 않는 '프로그램 방식 액세스 키'가 남아있는 경우 (가장 흔한 원인)
- 원인: 해당 IAM 계정으로 발급해 둔 액세스 키(Access Key ID / Secret Access Key)가 여전히 활성화(Active) 상태로 존재하면 사용자가 삭제되지 않는다. (콘솔 액세스만 있는 경우는 삭제 가능)
- 해결 방법:
- IAM 사용자 상세 페이지의 [보안 자격 증명] 탭으로 이동.
- 하단의 '액세스 키' 목록에서 기존 키를 찾아 [비활성화(Inactive)]로 변경.
- 비활성화된 키를 [삭제(Delete)]하여 완전히 제거한 후, 다시 IAM 사용자 삭제를 시도해야 한다.
2) 인라인 정책(Inline Policy)이 직접 연결되어 있는 경우
- 원인: AWS 관리형 정책(예: AmazonS3FullAccess) 외에, 사용자가 직접 해당 계정에만 종속되도록 만든 '인라인 정책'이 복잡하게 얽혀 있으면 삭제가 막힐 수 있다.
- 해결 방법: 사용자의 [권한(Permissions)] 탭에서 인라인 정책을 먼저 제거(Detach)해야 한다.
3) MFA(멀티 팩터 인증) 디바이스가 연결되어 있는 경우
- 원인: 해당 IAM 계정에 가상 MFA(Google Authenticator 등)가 등록되어 있으면 계정 삭제 프로세스가 진행되지 않는다.
- 해결 방법: [보안 자격 증명] 탭에서 등록된 MFA 디바이스를 먼저 [제거(Remove)]해야 한다.
2) Spring Boot 프로젝트(application.yml) 연동 구조
NoticeBoard(게시판) 예제 등에서 이미지 업로드 기능을 구현할 때, 파일 저장을 위해 AWS S3 서버를 연동한다. 이때 아무나 접근하면 안 되므로 S3 전용 IAM 권한이 필요하다.
- 아래와 같이 다운로드받은 .csv 속 키값들을 application.yml에 작성해두면, 스프링 부트 애플리케이션이 구동되면서 해당 인증 정보를 가지고 AWS S3 파일 서버에 안전하게 접근하여 파일을 업로드/다운로드하게 된다.
# application.yml 예시 구조
cloud:
aws:
credentials:
access-key: AKIAIOSFODNN7EXAMPLE # csv 파일에서 확인한 Access Key ID
secret-key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY # csv 파일에서 확인한 Secret Access Key
s3:
bucket: my-noticeboard-bucket-name
region:
static: ap-northeast-2 # 서울 리전
⚠️ 실습 종료 후 필수 체크:
비용 과금 방지를 위해 실습이 끝나면 생성했던 EC2 인스턴스는 반드시 종료(삭제)하고, 연습용으로 만든 IAM 계정 및 그룹도 모두 삭제해야 안전하다. AWS 과금 정책에 대한 내용은 여기서.
'Tech Stack > Cloud & DevOps' 카테고리의 다른 글
| 🌐클라우드 개념과 핵심 서비스(EC2/S3/VPC) 요약 (0) | 2026.07.15 |
|---|