[AWS] AWS VPC 엔드포인트 설정 및 프라이빗 인스턴스에서 S3 접근

목표 아키텍처

이번 글에서는 VPC 엔드포인트를 활용하여 프라이빗 서브넷에서 S3에 접근하는 방법을 정리하겠습니다. 목표 아키텍처는 위 그림과 같습니다.

---

1. NAT 게이트웨이 제거 및 라우팅 테이블 수정

현재 myvpc의 라우팅 테이블에서 MyPrivRouting은 NAT 게이트웨이와 연결을 했습니다. 하지만 myvpc와 연결된 NAT 게이트를 삭제한 상태라 NAT 게이트웨이와 연결된 항목이 블랙홀 상태가 됩니다. 이를 해결하기 위해 프라이빗 라우팅 테이블을 편집하여 NAT 게이트웨이 항목을 제거하겠습니다.

VPC > 라우팅 테이블로 이동

기존 NAT 게이트웨이가 연결된 항목 확인 (블랙홀 상태 표시됨) > 라우팅 편집 클릭

NAT 게이트웨이 제거 후 변경 사항 저장

해당 라우팅 테이블에 NAT 게이트웨이가 삭제된 것을 볼 수 있습니다.

---

2. Bastion 인스턴스 생성 (퍼블릭 서브넷)

퍼블릭 서브넷에서 Bastion 인스턴스를 생성하여 이후 프라이빗 인스턴스로 접속할 수 있도록 합니다.

인스턴스>인스턴스 시작 클릭

이름: Bastion

• 인스턴스 유형: t2.micro
• 키 페어: mykey01.pem
• VPC: myvpc

• 서브넷: 첫 번째 퍼블릭 서브넷 선택
• 퍼블릭 IP 자동 할당: 활성화

• 보안 그룹: 기본값 (SSH 연결 허용)
• 스토리지 구성: 8GiB

설정 후 인스턴스를 시작하고 정상적으로 생성되었는지 확인합니다.

---

3. PrivateNode 인스턴스 생성 (프라이빗 서브넷)

이제 프라이빗 서브넷에 위치할 PrivateNode 인스턴스를 생성합니다.

이름: PrivateNode

• 인스턴스 유형: t2.micro
• 키 페어: mykey01.pem
• VPC: myvpc

• 서브넷: 첫 번째 프라이빗 서브넷 (10.0.3.0/24)
• 퍼블릭 IP 자동 할당: 비활성화 (프라이빗 서브넷이므로)

• 보안 그룹: 기본값 (SSH 연결 허용)
• 스토리지 구성: 8GiB (Bastion과 동일)

생성이 완료되면 인스턴스 목록에서 두 개의 인스턴스가 정상적으로 생성되었는지 확인합니다.

---

4. S3  버킷 생성 및 키 페어 업로드

PrivateNode에 접속하기 위해 S3를 통해 키 페어를 전달하겠습니다.

S3>버킷 생성

버킷 이: msjwa-bucket

 

업로드 클릭

 

• mykey01.pem 업로드
  • 파일 추가 클릭 후 업로드 진행

 

mykey01 키 페어 업로드 완료. 키 페어를 S3에 업로드하는 이유는 S3에 업로드된 키 페어를 통해 프라이빗 인스턴스에 접근하기 위해서다.

---

5. 퍼블릭 노드에서 SSH 연결 및 S3 접근

먼저 Bastion 인스턴스 선택하고 연결 클릭

인스턴스에 연결 정보 확인하고 연결 한 번 더 클릭

따로 bash 창에서 ssh 명령어로도 연결 가능하지만 이번에는 해당 기능을 사용하겠습니다.

bash 창에서 연결 명령어는 아래와 같습니다.

ssh -i mykey01.pem ec2-user@[Bastion 퍼블릭 IP]

연결 후에는 aws configure 명령어를 사용해서 AWS CLI 자격 증명을 위한 접근 키를 입력합니다. 위처럼 진행이 완료되면 aws s3 ls 명령어를 입력하여 위와 같이 S3에 접근이 가능한지 확인합니다. 현재는 퍼블릭 노드(Bastion 인스턴스)에서 S3에 접근이 가능한 상태로 변경되었습니다.

다음으로 아래 명령어를 입력하여 해당 버킷에 업로드한 키 페어 파일이 있는지 확인했습니다. 정상적으로 업로드한 파일이 있는 것을 확인했습니다.

aws s3 ls s3://msjwa-bucket

 

 아래 명령어를 사용해서 해당 버킷에 있는 키 페어 파일을 퍼블릭 노드에 저장합니다.

aws s3 cp s3://msjwa-bucket/mykey01.pem .

ls 명령어로 다운로드한 파일이 현재 노드(퍼블릭)에 존재하는지 확인했습니다.

프라이빗 노드에 SSH로 연결하기 위해 키 페어 파일의 권한을 변경했습니다. 명령어는 아래와 같습니다.

chmod 400 mykey01.pem

 

**파일 권한을 변경하는 이유
SSH는 보안 강화를 위해 키 파일의 권한을 더욱 엄격하게 설정하도록 요구하고 있습니다.
기본적으로 키 파일의 권한은 644이며, 이 상태에서 SSH 연결을 시도하면 보안상의 이유로 연결이 차단됩니다. 이는 몇 년 전부터 적용된 정책으로, SSH는 키 파일이 적절한 권한으로 보호되지 않으면 연결을 허용하지 않습니다.
따라서, SSH 연결 전에 chmod 400 mykey01.pem 명령어를 실행하여 키 파일의 권한을 400으로 변경해야 합니다. 이는 키 파일이 소유자만 읽을 수 있도록 제한하여, 키가 외부에 노출될 위험을 최소화하기 위한 조치입니다.

 

이제 퍼블릭 노드(Bastion)에서 프라이빗 노드(PrivateNode)에 연결하기 프라이빗 IPv4 주소를 확인합니다.

퍼블릭 노드에서 SSH를 사용해서 프라이빗 노드에 연결합니다. 명령어는 다음과 같습니다.

ssh -i mykey01.pem ec2-user@[PrivateNode으 프라이빗 IPv4 주소]

Bastion과 동일하게 PrivateNode에서 AWS CLI 설정 을 합니다.

 

설정 후에 S3 접근 시도(aws s3 ls)를 합니다. 하지만 엔드포인트가 없으므로 아직까진 정상적인 접근이 불가능합니다.

---

6. VPC 엔드포인트 생성 (S3 연결)

프라이빗 서브넷에서 S3에 접근하기 위해 VPC 엔드포인트를 생성해야 합니다.

VPC>엔드포인트>엔드포인트 생성

• 이름: my-endpoint-01
• 유형: AWS 서비스

• 서비스: S3 검색 후 게이트웨이 유형 선택
• 네트워크 설정: VPC는 myvpc 선택

라우팅 테이블: 프라이빗 라우팅 테이블 선택 후 엔드포인트 생성합니다.

엔드포인트(my-endpoint-01)가 생성된 것을 확인합니다.

엔드포인트가 생성되면 다시 프라이빗 노드에서 S3 접근을 시도합니다.

정상적으로 S3에 접근할 수 있음을 확인할 수 있습니다.

---

7. 마무리 (자원 삭제)

실습이 마무리 됐으므로 비용 과금을 방지하기 위해 사용 자원을 삭제합니다.

7.1. 엔드포인트 삭제

엔드포인트 삭제

7.2. S3 삭제

S3를 삭제하기 위해서는 해당 버킷에 객체 파일이 없어야 삭제가 가능합니다. 따라서 업로드한 파일을 먼저 삭제합니다.

버킷에 아무런 파일이 없으면 버킷 삭제를 진행합니다.

7.3. 인스턴스 삭제(종료)

마지막으로 생성한 2개의 인스턴스를 삭제합니다.

실습 정리

• NAT 게이트웨이를 제거한 후 라우팅 테이블을 수정
• 퍼블릭 서브넷에 Bastion 인스턴스를 생성
• 프라이빗 서브넷에 PrivateNode 인스턴스를 생성
• S3에 키 페어를 업로드하여 PrivateNode 접근 가능하도록 설정
• VPC 엔드포인트를 활용하여 프라이빗 서브넷에서도 S3 접근 가능하도록 구성

이번 실습을 통해 프라이빗 네트워크 환경에서도 AWS 리소스(S3)에 접근하는 방법을 익혔습니다. 이를 활용하면 네트워크 보안을 강화하면서도 필요한 AWS 서비스와 연결할 수 있습니다.