AWS VPC 및 서브넷 설정 & EC2 외부 접근 허용

개발자가 AWS를 쓴다는 것은 (1) 서버를 구축하고 (2) 우리가 개발한 코드를 해당 서버에 배포하여 웹 서비스를 제공하는 것이다.

(1) 서버를 구축: Private/ Public 네트워크를 구성한 뒤, 그 위에 서버를 임대하여 구동시킨다.

(2) 우리가 개발한 코드를 해당 서버에 배포: 우리가 개발한 코드를 구축한 서버 위에서 빌드 및 배포

이번 블로그에서 담을 내용은 "1. 서버를 구축"에 해당하며 실습을 토대로 이어나갈 예정이다.

클라우드 컴퓨팅은 IT 리소스를 인터넷을 통하여사용한 만큼만 비용을 지불하는 것이다. (온디맨드)
AWS는 공개형 Public Cloud로 클라우드 사업자의 물리 서버를 사용하며 낮은 비용과 높은 확장성을 가진다.

[ VPC ]

: 사용한 IP 대역폭을 제공받고, 그 IP들을 서브넷으로 쪼개는 것이다.

Subnet: VPC로 제공받은 큰 네트워크를 몇개의 네트워크로 자른 것. 그렇기에 이름 그대로, 서브 네트워크.
서브넷은 어떠한 특성도 가지지 않는다. 우리가 Private Subnet, Public Subnet이라고 부르지만, Route Table에서 따로 설정을 해주어야만 특성을 가지게 된다. 단지 이름표에 불과하다.
일반적으로 1개의 VPC에 4개의 서브넷으로 구성한다. Private 서브넷 2개 + Public 서브넷 2개
- 이중화를 하는 이유는 다른 지역에 똑같이 구성해놓아서, 화재 혹은 네트워크 이슈 등이 발생했을 때 다른 한쪽의 AZ로 커버하기 위한 것이다. -> 매우 중요하다. 몇년 전 큰 이유가 되었던, 카카오 물리 서버의 화재로 인해 카카오톡이 먹통이 된 이유가 이중화를 제대로 안 해놨기 때문@@!!
- Private 서브넷 1번 → ap-northeast-2a
- Private 서브넷 2번 → ap-northeast-2b
- Public 서브넷 1번 → ap-northeast-2a
- Public 서브넷 2번 → ap-northeast-2b

1. AWS에서 VPC 생성하기

VPC의 정의가 Virtual "Private" Cloud 이듯이 아무것도 하지 않으면 인트라넷(Private Network)이다.

VPC : 인트라넷(Private)
VPC + IGW : 인터넷(Public)

2. Subnet 생성하기 (Private Subnet 2개 + Public Subnet 2개)

3. EC2 인스턴스 만들기 (Public Subnet)

4. IGW(Internet GateWay) 생성

[ IGW(Internet Gateway) ]

: VPC 내부 서버가 외부와 통신할 수 있게 해주며 인스턴스 단위로 외부 IP 할당을 한다. (외부 IP <-> 단일 내부 IP 주소 변환)

VPC가 할당 받은 Private IP이기 때문에 외부와 통신할 수 없다. 그렇게 때문에 VPC 내부 서버가 외부와 양방향으로 접근 가능하도록 열어주는 역할을 한다.

5. Route Table 설정

지금까지 VPC에 IGW를 연결하면 Public Subnet 내 EC2가 외부 접근이 가능할텐데 왜 아직도 안될까?
- VPC에 IGW 연결하여 Public화 하였고,
- EC2에게 자동 할당 퍼블릭 IP 활성화 + SG를 통해 SSH(22포트) 오픈도 했는데 왜 안 될까@!!
'VPC-IGW' 와 public IP를 가진 'EC2'가 연결되지 않았기 때문이다.
- Public Subnet(EC2)와 IGW가 연결되지 않았다. -> Route Table을 통해 연결이 필요하다.
Route Table (RT) 는 특정 IP 에 대한 요청이 들어오면 → 어디로 가라는 이정표(도로 표시판)
- 특정 IP 에 대한 요청이 들어오면 : Destination
- 어디로 가라는 이정표(도로 표시판) : Target
Route Table 정의 후 서브넷에 붙이면 해당 서브넷 내 발생하는 트래픽들을 원하는대로 이동
Route Table는 인바운드/ 아웃바운드에 적용된다.
- Private / Public 서브넷의 외부와 통신 가능 여부를 결정하는것이 이 Route Table

Route Table을 2개 생성하고, 각 서브넷에 할당한다.

Public Route Table에 모든 트래픽(0.0.0.0/0)을 IGW로 연결한다.

test-public-route-table -> 라우팅 -> 라우팅 편집 (0.0.0.0을 IGW와 라우트 설정) - 아웃바운드

Route Table을 각각 2개의 Subnet에 할당(서브넷을 정의할 때 Public, Private은 우리가 이름을 붙여준 것 뿐, 이 설정을 통해서 각각의 특성을 가지게 된 것)

6. VPC 내부 서버로 외부에서 통신할 수 있게: SSH Tunneling Bastion

Private 서브넷 내 위치한 서버에 인바운드 접근을 위해 외부 서버 Bastion 통해 단방향(인바운드) 연결

Private 서브넷이 외부와 통신을 어쩔 수 없이 해야하는 경우가 2가지

6-1. Public에서 Private Subnet으로 접속: Bation + Route Table

SSH Tunneling(Bastion), Private 서브넷에 외부 개발자 컴퓨터에서 SSH를 통해 접근이 가능해야할 때

인바운드: 이때는 SSH Tenneling(Bastion)을 통해 밖에서 안으로 들어올 문을 연다.

6-2. SSH Tunneling (= Port Forwarding) : Bastion

SSH Tunneling 을 Jump Box, Jump Host, Jump server이라고 부르는 이유는 외부에서 Private 서브넷 내 서버에 접근하기 위해 Public 서브 냇 내 서버를 디딤돌 삼아 점프를 하는 것 같기 때문이다.

Local -> Bastion (Public 서브넷 내 존재) -> Server (Private 서브넷 내 존재)

그림과 같이 Local에서 Private Server와 통신하기 위해서는 반드시 Bastion을 통해야 한다. 그 과정에서 local-to-bastion에 대한 키 페어 하나, local-to-server에 대한 키 페어 하나 총 두 쌍의 키페어가 필요하다.

AWS PEM 파일은 ~~Public Key가 아니라,~~ Private Key다. SSH 클라이언트는 Remote에 대한 접근을 위해 Key Pair 상의 Private Key 파일이 필요하다.

OpenSSL로 RSA Key Pair 생성 시 Public Key(.pub)와 Private Key(.pem)을 파일로 생성해준다.
AWS 콘솔을 통해 PEM 키를 생성하면, Public 키를 감추고 우리이겐 Private 키만 다운 받도록한다.
- AWS가 노출하지 않고 감춘 Public Key(.pub)는 EC2 인스턴스 생성 시 주입 설정
- 우리가 다운받은 Private Key(.pem)는 위 Public Key 가진 EC2에 접속 시 클라이언트에 설정

6-3. 키 페어 생성

7. EC2 생성(local-to-bastion) : public-bastion-instance

인스턴스 t2.micro 타입으로, Linux 아무거나 (예, Amazon Linux) 선택하여 생성
- 앞서 만들었던 Key Pair 설정 (Public Key)
- 인스턴스 생성 시 앞서 생성한 Public Subnet 중 하나에 할당
- Auto-assign public IP (자동 할당 퍼블릭 IP) 활성화
  - IGW 에 아무리 연결되었다해도 Public IP 가 없다면 무슨 소용인겨
  - 어자피, 본 옵션을 설정하지 않으면 “EC2 인스턴스 연결” 동작하지 않음 ..

7. EC2 생성(local-to-privateserver) : private-server-instance

인스턴스 t2.micro 타입으로, Linux 아무거나 (예, Amazon Linux) 선택하여 생성
- 앞서 만들었던 Key Pair 설정 (Public Key)
- 인스턴스 생성 시 앞서 생성한 Private Subnet 중 하나에 할당
  - 이중화를 했기때문에, 앞서 bastion instance와 맞는 subnet-0을 맞추어줘야한다.
- Security Group (SG) 에 앞서 만든 Bastion EC2 의 SG 를 설정
  - Source Type 을 Custom 으로 하고 Source 를 Bastion EC2 의 SG 로 설정
  - private이기 때문에 누구나 들어올 수 있는 게 아니고, bastion에 들어온 IP에 해당하는 것만 받기 위한 보안그룹 설정
    - sg를 Bastion의 sg로 설정
    - Description 은 다음과 같이 명시적으로 적으면 나중에 헷갈리지 않음
    - = “Allow SSH from the Bastion Host”
  - Security Group 에서 다른 Security Group 을 참조하는 경우
    - Bastion EC2 의 SG 를 사용하는 리소스(Bastion)를 통과한 호스트(Local)들만 통과

bastion-instance의 sg(wizard-7)에 대한 보안 규칙을 등록해준다.

8. Bastion EC2(public-bastion-instance)내 Private EC2(private-server-instance)에 SSH 접속

: key의 유효성 테스트 - 키를 통해서 접속이 가능한가

에디터 열기(파일명은 내가 정한 것. bastion-to-private)

Nano 사용법 : Ctrl + X = 파일 편집 후 종료 → Y 눌러서 저장 , chmod 400 bastion-to-private.pem 입력

9. NAT instance 생성

참조 : AWS 에서 NAT Instance 공식 지원을 접고 NAT Gateway 를 공식화. 하지만 NAT Gateway 는 비용이 진짜 너무 비싸서 가난한 개발자는 NAT Instance 만들어 쓰면 된다.

인스턴스 micro 타입으로, Linux 아무거나 (예, Amazon Linux) 선택하여 생성
- 인스턴스 타입은 마음대로 결정해도 되나, 일반적으로 t2.micro 제안
키페어 설정:local-to-bastion
AMI 검색을 통해 커뮤니티 버전으로 나온 NAT 를 위한 AMI 를 사용할것
- AWS 공식 NAT 인스턴스 AMI (Pre-configured Amazon Linux AMI) 는 이제 미지원
- : amzn-ami-vpc-nat-2018.03.0.20230807.0-x86_64-ebs
- IAM와 AMI가 헷갈릴 수 있지만, 완전 다른 것.
  - IAM: 권한관련 서비스
  - AMI: OS 이미지들을 모아놓음 (쓰고 싶은 os들을 가져가서 구동시키면 되는 것.)
Security Group (SG) 설정, SSH 과 HTTPS 열기
- SG 명칭은 nat-instance-sg 와 같이 쉽게 이해할 수 있는 이름으로
  - SSH, Source Type : Anywhere, Source : 0.0.0.0/0 (모든 트래픽)
  - HTTP, Source Type : Custom, Source : 10.0.0.0/16 (자신이 만든 VPC CIDR)
  - HTTPS, Source Type : Custom, Source : 10.0.0.0/16 (자신이 만든 VPC CIDR)
  - 모든 ICMP - IPv4, Source Type : Custom, Source : 10.0.0.0/16 (자신이 만든 VPC CIDR)
Network 설정에서 Source/Destination Check 옵션에서 STOP 체크 필요
- NAT (Network Address Translation) 의 정의에 따라 Src/Dst 는 수행하면 안된다
- NAT EC2 인스턴스 내 “소스/대상 확인” 삭제
- NAT EC2 인스턴스의 ENI 내 “소스/대상 확인” 비활성화 → 위 설정으로 안해도되는걸로 암