영암사는 승경이네

1. NAT Gateway란?

 네트워크 주소 변환 서비스를 말하며, 프라이빗 서브넷의 인스턴스이 외부 인터넷망으로 나갈 수 있도록 함과 동시에 Public IP를 부여하는 역할을 한다.

NAT (Network Address Translation)
 네트워크 주소 변환의 줄임말인 NAT는 IP패킷의 TCP/UDP 포트 숫자와 출발지 및 목적지의 IP 주소 등을 재기록하면서 라우터를 통해 네트워크 트래픽을 주고 받는 기술을 뜻한다. IP 를 변환하겠다는 뜻이다.
 NAT를 이용하는 이유는 대개 사설 private Network에 속한 여러개의 호스트가 하나의 공인 IP를 사용하여 인터넷에 접속하기 위함이다.

2. 인터넷 게이트웨이랑 똑같은데요??

 인터넷 게이트웨이는 서브넷을 인터넷 망과 직접적으로 연결시켜 외부로 나갈수도, 외부에서 접근할 수도 있는 구조이다. 이에 반에 NAT GateWay는 서브넷 내의 인스턴스가 외부, 즉 인터넷망으로 나갈 순 있지만, 외부에서 내부 즉, 해당 인스턴스로의 접근은 불가능하다. 이유는 외부 인터넷망으로 나갈 때에만 Public IP를 부여하기 때문이다.

3. AWS NAT Gateway 설정 방법

1) 퍼블릭 서브넷에서 NAT 게이트웨이 생성

 프라이빗 서브넷의 인스턴스는 퍼블릭 서브넷에 위치한 NAT 게이트웨이를 통해 인터넷에 연결할 수 있다. 퍼블릭 서브넷에서 NAT 게이트웨이를 생성하자. 인터넷 망으로 나갈 때 설정할 공인 IP가 필요하기에 탄력적 IP 를 새로 할당하거나, 기존에 있는 탄력적 IP를 사용해야한다.

2) 프라이빗 서브넷 라우팅 테이블에 NAT Gateway 추가

 NAT Gateway 생성이 완료되면, 프라이빗 서브넷의 라우팅 테이블에 NAT Gateway를 추가해주자. 외부로 나갈 때 NAT Gateway로 라우팅되어야 하므로 대상을 0.0.0.0/0으로 설정한다.

3) 테스트

 이제 프라이빗 서브넷의 인스턴스에 SSH 접속 후 아래 명령어를 입력하여 외부와 통신이 되는지 확인하자.

curl https://tlatmsrud.tistory.com

통신이 된다면 NAT Gateway를 통해 외부로 나간것임을 알 수 있다.

서브넷이 뭔가요?

서브넷은 서브 네트워크를 말하며, 기존 네트워크 영역을 분할해 더 작은 크기의 네트워크 영역으로 쪼갠 네트워크이다. (말 그대로 서브 네트워크...) AWS에서의 서브넷은 VPC 내에 생성하는데, VPC 가 가진 CIDR 블록(기존 네트워크 영역) 내에서 더 작은 CIDR 블록(더 작은 크기의 네트워크 영역) 로 쪼갠 네트워크 영역을 말한다.

아래와 같이 VPC를 10.0.0.0/16 으로 CIDR 대역을 설정한 후 10.0.10.0/25, 10.0.20.0/25 CIDR 블럭을 갖는서브넷을 각각 생성하였다. 즉, A 서브넷은 10.0.10.0 ... 10.0.10.127 IP 대역을, B 서브넷은 10.0.20.0 ... 10.0.20.127의 IP 대역을 갖게 되는것이다.

퍼블릭 서브넷, 프라이빗 서브넷??

서브넷 유형을 말하며, 이 두 유형은 서브넷을 생성할 때 지정하는게 아니라 서브넷에 할당된 라우팅 테이블에 의해 지정된다. 퍼블릭의 의미는 인터넷 망, 정확히 말하면 인터넷 게이트웨이와 직접 연결되어 있는 것을 말한다.

다시말하면 퍼블릭 서브넷은 라우터에 의해 인터넷 게이트웨이와 직접 연결되는 서브넷이고, 프라이빗 서브넷은 인터넷 게이트웨이와 직접 연결되지 않은 서브넷이다. 라우팅 테이블 설정에 따라 퍼블릿 서브넷이 프라이빗 서브넷이 될수도, 그 반대가 될수도 있다.

인터넷 게이트웨이가 뭔가요?

인터넷 게이트웨이란 VPC와 인터넷 간에 통신할 수 있게 해주는 VPC 구성요소를 말한다. 줄여서 IGW라고 부른다.

라우팅 테이블에 IGW만 추가하면 외부와 통신이 가능한건가요?

IGW에 대한 라우팅 정보를 추가하기만 하면 해당 서브넷 내 리소스들이 인터넷 망으로 나갈 수 있을까? 그렇지 않다. 서브넷 내에 퍼블릭 IP를 가진 리소스가 존재하지 않기 때문이다.

 인터넷 게이트웨이를 설정했다면, NAT 게이트웨이를 설정하거나, 서브넷 상의 리소스에 퍼블릭 IP를 할당해야만이 인터넷 게이트웨이를 통해 인터넷에 연결할 수 있다.

AWS VPC 설명서 기반으로 스터디한 내용입니다.

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/what-is-amazon-vpc.html

개요

 예전 AWS 로 인프라를 구성한 적이 있는데, 구성 당시에는 누군가 만들어놓은 메뉴얼을 따라하기만 했지, 각각의 리소스들이 왜 필요한지, AWS 내에서 어떤 역할을 하는지에대한 고민은 하지 않았다. 그래서 이번 기회에 AWS 구조와 용어에 대해 이해하고 싶었고, 가장 기본인 VPC부터 공부하게 되었다.

Amazon VPC가 뭔가요?

아마존(Amazon) 에서 제공하는 격리된(Private) 가상(Virtual) 클라우드(Cloud) 서비스를 말한다. 조금 더 풀어 말하면, 아마존과 같은 퍼블릭 클라우드 환경 내 일부분을 고객 전용으로 프라이핏하게 사용할 수 있는 가상 네트워크를 말한다. 가상 네트워크라는 말이 알쏭달쏭한데, 글을 읽다보면 이해할 수 있을것이다.

"VPC는 리전의 모든 가용 영역에 적용됩니다." ??

Amazon VPC 사용 설명서의 첫 시작 문구이다. 첫 시작부터 발걸음을 돌리고 싶게 만드는 알쏭달쏭한 문구인데, 첫 문구인만큼 이 의미를 이해하는 것이 중요하다고 생각했다. 먼저 리전과 가용 영역에 대해 알아보자.

리전(Region)과 가용영역(Availability Zone)

리전 (Region)

리전이란 전 세계에서 데이터 센터를 클리스터링하는 지리적 위치를 말한다. 여기서 지리적 위치라고 표현한 이유는 실제 물리적인 위치보다 더 넓은 범위를 표현하는 용어이기 때문이다. 누군가 "너 어디살아?" 라고 물었을때 "나 서울시 xx구 xx아파트 203동 101호에 살아" 라고 하지 않고 "나 서울살아" 라고 하는것과 같다고 생각하면 된다.

데이터 센터
용어만 들으면 데이터가 저장된 센터? DB를 말하는건가? 라고 착각이 들 수 있다. 클라우드 컴퓨팅에서의 데이터 센터란 컴퓨팅 시스템 및 하드웨어 장비가 저장된 물리적 위치를 말한다. 즉, 클라우딩 관련 장비가 저장된 센터를 말한다.

위 그림을 보면 알 수 있듯이 클라우드 서비스를 제공하기 위한 데이터 센터의 지리적 위치는 미국 동부, 서부, 서울, 도쿄 등 지역별로 고루 퍼져있다.

가용영역 (Availability Zone)

 리전별로 하나의 데이터 센터만을 운용하고 있을까? 아니다. 최소 2개 이상의 데이터 센터를 가져야 리전으로써의 조건이 성립된다. 즉, 서울 리전에는 실제로 2개 이상의 데이터 센터들이 어딘가에서 운용되고 있는 것이다. 그리고 이렇게 퍼져있는 데이터 센터들을 논리적으로 묶어놓은 것을 가용영역이라 한다.

위 그림은 리전과, 가용영역, 그리고 실제 데이터 센터를 도식화 한것이다.

"VPC는 리전의 모든 가용 영역에 적용됩니다." !!

다시 돌아가서 이 문구의 의미는 뭔지 생각해보자. 해석하면 "VPC라는 가상 네트워크는 리전 내에 있는 모든 가용영역에 위치시킬 수 있다는 뜻이고 이 말은 하나의 VPC 내에 생성되는 리소스들을 여러 데이터 센터에 위치시킬 수 있다는 뜻이다."

아래 그림과 같이 말이다. VPC가 가상의 네트워크이기 때문에 여러 가용영역을 공유 사용할 수 있는것이다.

VPC 에는 자체 IP가 없고 IP 대역(CIDR) 을 설정하던데...

 VPC를 생성한다고 해서 VPC 자체에 대한 IP가 할당되지 않는다. 말 그대로 "가상의 네트워크"이기 때문이다. 대신 VPC 내에 실제 리소스를 생성할 때에는 해당 리소스에 IP가 할당되는데, 이때 할당되는 IP의 범위, 즉 CIDR를 VPC 생성 시 설정해야 한다. VPC를 생성할 때 IP 프로토콜과 CIDR를 설정하는 이유가 바로 이것이다.

IPv4 프로토콜을 사용할 경우 CIDR 블록 크기 설정 시 RFC1918 규격과 AWS 자체 VPC CIDR 블럭 규칙에 따라 CIDR를 설정해야 한다. 이를 준수하는 CIDR 블록 크기는 아래로 한정된다. 

10.0.0.0/16 ~ /28

172.16.0.0/16 ~ /28

192.168.0.0/16 ~ /28

RFC 1918
프라이빗 IP의 국제 규격으로 아래 대역 범위를 갖는다.

달랑 VPC 만 생성해주지 않아요~

VPC를 생성하면 VPC만 생성되는게 아니라 기본 리소스인 기본 DHCP 옵션 세트, 기본 네트워크 ACL, 기본 보안그룹, 기본 라우팅 테이블도 함께 생성된다. 각각에 대해 알아보자.

첫째, 기본 DHCP 옵션 세트

DHCP가 뭔가요?

 Dynamic Host Configuration Protocol의 약자로 네트워크에 위치한 컴퓨터 및 기타 장치에 IP 주소와 같은 네트워크 정보를 자동으로 할당하기 위한 프로토콜을 말한다. 네트워크 설정을 DHCP 서버가 중앙 집중식으로 관리하는 클라이언트/서버 모델인 것이다.

 이전에는 네트워크에 위치한 컴퓨터 및 기타 장치의 IP 주소를 수동으로 할당했지만, 오늘날에는 DHCP를 사용해 동적으로 할당하고 있다. 생소하게 느껴질 수 있지만 사실 대부분의 컴퓨터 사용자들이 이 프로토콜을 사용하여 네트워크 설정을 자동화했을 것이다. 필자의 맥북또한 마찬가지인데, 네트워크 탭의 IPv4의 구성 방식이 DHCP를 사용하도록 설정되어 있어 IP, DNS서버, 게이트웨이 주소 등을 따로 설정하지 않아도 자동으로 할당되는 것을 확인할 수 있다.

DHCP를 사용하면 뭐가 좋나요?

네트워크 설정을 자동화할 수 있고, 수동 IP 할당 시 발생할 수 있는 IP 충돌 문제를 예방할 수 있다.

DHCP 옵션 세트가 뭔가요?

EC2 인스턴스가 실행될 때 DHCP를 통해 자동으로 네트워크 설정이 되도록 DHCP 서버로 요청하는데, 이 DHCP 관련 설정이 담긴 세트이다. 각 리전마다 각기 다른 기본 DHCP 옵션 세트를 갖고 있다.

DHCP 옵션 세트가 AWS에서 어떻게 쓰이는지 알려주세요

VPC 내 EC2와 같은 리소스가 실행되면 IP, DNS 서버와 같은 네트워크 설정을 위해 Amazon DHCP 서버로 요청하게 된다. 그럼 DHCP 서버는 VPC 내 설정된 DHCP 옵션 세트를 로드하게 되는데, 이 옵션 세트에 따라 IP 주소와 DNS 서버와 같은 네트워크 설정을 해당 리소스에 할당하게 된다.

 참고로 리소스에 네트워크 설정이 정상적으로 할당된 경우 해당 리소스는 자신에게 할당된 IP 정보를 자동으로 라우팅 테이블에 등록하게 되는데, 이러한 과정으로 인해 내부 리소스간의 네트워킹이 가능한 것이다.

그래서 기본 DHCP 옵션 세트는 뭐라고요?

기본 DHCP 옵션 세트란 리소스의 네트워킹 설정을 위해 DHCP 서버가 참조하는 기본옵션들을 말한다. VPC 라는 가상 네트워크 환경에 설정한 CIDR 대역에 맞는 IP로 할당되어야 하지 않겠는가? 이러한 외부 정보가 없다면 어떤 IP를 할당해야하는지에 대한 기준이 잡히지 않을 것이다. (이건 필자의 지극히 주관적인 생각입니다.)

둘째, 기본 네트워크 ACL

네트워크 ACL이 뭔가요?

네트워크 ACL이란 Network Access Control List의 약자로 '서브넷 수준'에서 특정 인바운드 또는 아웃바운드 트래픽에 대한 접근 제어 리스트를 말한다. 아래는 서브넷이 2개인 VPC 내에서 네트워크 ACL의 역할을 알려주는 그림이다.

트래픽이 VPC로 들어오면 라우터에서 라우팅 테이블을 확인해 트래픽을 타겟으로 보낸다. 이때 네트워크 ACL로 하여금 해당 트래픽이 서브넷으로 들어가고 나갈 수 있는지를 제어하는 것이다. 네트워크 레벨에서의 방화벽인 셈이다.

그래서 기본 네트워크 ACL은요?

AWS에서 기본으로 제공하는 네트워크 ACL로, VPC 내 서브넷을 생성할 경우 네트워크 ACL을 설정해야 하는데, 설정하지 않을 경우 자동으로 할당되는 네트워크 ACL이다. 기본 네트워크 ACL의 정책은 모든 인바운드 및 아운바운드에 대한 IPv4, IPv6 트래픽을 허용한다.

셋째, 기본 보안그룹

보안그룹이 뭔가요?

보안 그룹은 VPC 내 리소스에 대한 접근을 제어하는 그룹을 말한다. 예를 들어 특정 IP 에 대한 인바운드를 차단하는 보안 그룹을 만들고, 2개의 EC2 인스턴스의 보안 그룹에 이를 적용한다면, 특정 IP가 두 EC2 인스턴스로 접근하지 못하도록 차단한다.

네트워크 ACL과 같은거 아닌가요?

인바운드, 아운바운드에 대한 접근을 제어한다는 점에서 비슷하지만, 적용 레벨이 다르다. 네트워크 ACL은 서브넷 레벨에서, 보안그룹은 리소스 레벨에 적용된다.

그래서 기본 보안그룹은요?

VPC를 생성할 경우 기본으로 제공되는 보안그룹이다. 모든 트래픽에 대해 인바운드와 아웃바운드를 허용하도록 정책이 설정되어 있다

위 그림은 VPC 내 위치한 두 개의 EC2가 기본 보안 그룹을 적용한 상황이다. 기본 보안그룹 설정했으니 모든 포트 및 IP로부터 오는 트래픽을 받을 수 있게 된다. 단, 기본 보안그룹은 인터넷 게이트웨이 또는 NAT 게이트웨이로부터 오는 트래픽을 거부하도록 설정되어 있다. 만약 NAT 게이트웨이나 인터넷 게이트웨이를 사용한다면 커스텀 시큐리티 그룹을 만들어 각 인스턴스에 적용하면 된다.

기본 라우팅 테이블

라우터부터 알고가자

라우터란 네트워크 간 데이터 전송을 위해 최적 경로를 선택한 후 네트워크간 통신할 수 있도록 도와주는 인터넷 장비이다.

그렇다면 라우터는 어떻게 '최적의 경로'를 찾아낼 수 있는걸까? 그건 바로 라우터가 가진 '라우팅 테이블'을 참고했기 때문이다.

라우팅 테이블이 뭐에요?

라우팅 테이블이란 네트워크에서 목적지 주소를 통해 물리적 목적지에 도달하기 위한 경로들이 저장된 테이블이다. 라우터로 하여금 최적의 경로를 선택하도록 도와주는 역할을 한다. 각 라우터가 가진 라우팅 테이블은 목적지에 도달하기 위해 거쳐야할 다음 라우터의 정보를 가지고 있다.

라우팅 테이블은 누가 작성하는 건가요?

관리자가 수동으로 작성할 수도 있지만, 일반적으로 라우팅 프로토콜을 통해 자동으로 라우팅 테이블이 만들어진다. 라우팅 프로토콜(Routing Protocol)이란 라우터끼리 경로 정보를 교환하는 프로토콜로 RIP, BGP, OSPF 프로토콜이 있다.

그래서 기본 라우팅 테이블은요?

VPC를 만들면 기본으로 적용되는 라우팅 테이블이다. 서브넷을 생성할 때 라우팅 테이블을 명시적으로 할당해야하는데, 이를 하지 않을 경우 이 기본 라우팅 테이블이 서브넷에 할당되게 된다.

 기본 라우팅 테이블에는 로컬 라우팅만 포함된다. 그런데 VPC 내에 NAT 게이트웨이를 생성하면 VPC가 기본 라우팅 테이블에 0.0.0.0/0 트래픽에 대한 타겟 경로를 NAT 게이트웨이로 자동 추가한다. 외부로 나갈때 NAT 게이트웨이를 통해 자동으로 IP가 변경하도록 하기 위함이다. 이를 암시적 서브넷 연결이라고 한다.

NAT
Network Address Translation(네트워크 주소 변환)의 약자로 네트워크 주소인 IP를 변환하는 용어이다.

NAT 게이트웨이
IP를 변환시켜주는 장비를 말하며, 일반적으로 사설 네트워크에 속한 호스트가 하나의 공인 IP 주소를 사용하여 인터넷망에 접속하기 위해 사용한다.

 이 라우팅 테이블에 설정된 타겟에 따라 서브넷의 유형이 결정된다. 서브넷에 할당된 라우팅 테이블에 인터넷 게이트웨이가 추가되어 있을 경우 퍼블릿 서브넷, 인터넷 게이트웨이가 없다면 프라이빗 서브넷으로 구분된다. 이 내용은 아래 게시글을 참고해보면 좋다.

https://tlatmsrud.tistory.com/172#comment14007882

1. 개요

• AWS 서버에 스프링 부트 프로젝트를 jar파일 배포한다.

2. 준비

• Amazon Linux 2 서버
• Spring Boot + gradle 프로젝트
• JDK 설치
• Git 설치 및 Source Clone

3. JDK 설치

• 프로젝트를 배포하기 전 AWS 서버에 JDK를 설치해야합니다. SpringBoot의 build.gradle 파일의 sourceCompatibility를 확인해봅시다. sourceCompatibility는 현재 프로젝트에 호환된 Java 버전을 의미합니다.

• 필자의 경우 java 1.8 이므로 aws서버에 openJDK 1.8 버전을 설치를 위해 다음 명령어를 입력하겠습니다.

 sudo yum install -y java-1.8.0-openjdk-devel.x86_64

• 설치가 완료되었다면 인스턴스의 Java 버전을 8로 변경해야합니다. 다음 명령어를 입력 후 인스턴스에 적용할 java 버전의 번호를 입력합니다.

sudo /usr/sbin/alternatives --config java

• 필자의 경우 방금 설치한 java 버전만 있고, Selelction이 1로 지정되어 있으므로 입력창에 1을 입력합니다.
• 설정이 완료되면 서버의 java 버전을 확인합니다.

java -version

• 설정한 Java 버전이 조회된다면 스프링 부트 jar 배포에 대한 기본적인 준비는 끝났습니다.이제 배포를 해봅시다!

4. Git 설치 및 Clone

• 프로젝트 파일이나 빌드된 파일을 AWS 서버로 전송 해야합니다. 이 과정에 대해 채택할 수 있는 방법은 FTP가 될수도 있지만 필자의 경우 Git Clone을 통해 프로젝트 파일을 AWS 서버에서 받은 후 서버 내에서 빌드를 하는 방식을 채택했습니다.
• 다음 명령어를 입력해 AWS 서버에 git을 설치 및 확인합니다.

sudo yum install git // git 설치
git --version //git 설치(버전) 확인

• 설치가 완료되면 clone 될 디렉토리를 생성한다. 필자의 경우 홈 디렉토리 기준으로 "app" 폴더를 생성하여 그 안에 git에서 clone한 소스를 넣겠습니다.

mkdir ~/app  //app 폴더생성

• 폴더 생성이 완료되면 본인의 깃허브 웹페이지에서 주소를 복사합니다.

• AWS 서버에 다음 명령을 입력하여 clone을 진행합니다.

git clone 복사한 주소

• clone이 정상적으로 완료되면 app 폴더 안에 프로젝트 소스들이 들어갔을겁니다. 이제 배포를 진행할 차례입니다.

5. 배포

• 프로젝트 경로로 들어가 다음 명령어를 입력해 jar 빌드합니다.

./gradlew bootjar

• build가 완료되면 자동적으로 build/libs 폴더 내에 "프로젝트 명/버전.jar" 형식으로 파일이 생성됩니다. 배포는 간단합니다. 이 파일을 실행시켜주면 됩니다. 스프링 부트는 jar 파일 빌드 시 tomcat 서버가 내포된 형태로 빌드되기 때문에 별도의 tomcat 서버가 필요없습니다.

java -jar jar파일 명

• 배포가 완료되었습니다. 배포된 서버로 접속하기 위해 '퍼블릭 DNS:포트'를 입력해봅시다.
• 퍼블릭 DNS는 AWS 인스턴스 상세정보로 들어가면 확인할 수 있으며 포트는 배포 로그의 마지막 부분에서 확인할 수 있습니다.

• 짜잔~ 다음과 같이 정상적으로 접속이 되었습니다.

• 만약 접속이 되지 않으신다면 AWS내에 설정한 보안 그룹에 해당 포트가 오픈되어있는지 확인해봅시다. 필자의 경우 해당 포트가 열려있지 않아 최초에 접속이 되지 않았습니다.
• 인스턴스 세부정보 > 보안 > 인바운드 규칙에 8090포트를 추가해줍시다.

  

6. 마치며...

• Git 연동 및 클론, 빌드, AWS 배포를 해보았습니다. 되게 간소하게(?) 진행했지만 AWS 서버에 배포를 해본건 처음이라 감회가 새로웠다. 다음 목표는 Jenkins를 연동하여 git commit이 있을 때 자동으로 AWS 서버에 수정된 코드가 배포되도록 하는 것이다. 이 작업이 끝나면 본격적인 서버 로직을 작업할것이다

1. 개요

 - 프리티어 계정으로 EC2 서버를 생성한다.

 - 생성된 EC2 서버에 접속한다.

2. 환경

 - Window 10

 - AWS 계정 생성 완료

3. EC2 란?

 - Elastic Compute Cloud의 약자로 AWS에서 제공하는 사양, 용량 등을 유동적으로 사용 가능한 서버를 말합니다.

 - 프리티어 계정은 이 중 t2.micro(CPU 1, 메모리 1GB, 용량 최대 30GB)라는 서버를 1년동안 무료로 사용 가능합니다. 

 - 프리티어 기준으로 월 750 시간의 제한이 있으며 초과하면 과금이 발생합니다. 하지만 24*31은 744 시간이므로 한대의 프리티어 서버를 운용한다면 과금은 발생하지 않습니다.

4. EC2 t2.micro 서버 생성

 4.1. 검색창에 ec2 검색 및 선택

 4.2. 인스턴스 시작 버튼 선택

  - 화면 진입 시 상단에 위치한 인스턴스 시작 버튼을 선택합니다.

 4.3. OS 선택

  - 프리티어로 사용 가능한 Amazon Linux 2 AMI 64비트를 선택합니다.

 4.4. EC2 유형 선택

  - 프리티어로 사용 가능한 t2.micro 를 선택합니다.

 4.5. 인스턴스 세부 정보 구성

  - 이 부분에서 딱히 설정해야할 부분은 없습니다. 넘어갑시다.

 4.6. 스토리지 설정

  - t2.micro 에서 지원 가능한 최대 스토리지 용량인 30GB를 입력합니다.

 4.7. 태그 추가

  - Name 이라는 Key를 생성하고 값(ex. 프로젝트 명)을 입력해줍니다.

 4.8. 보안 그룹 추가

 - [SSH, 내 IP] : SSH를 통해 서버에 접근할 수 있도록 추가합니다. '나'만 접근 가능하도록 하기 위해 '내 IP'로 설정하였습니다. 만약, 서버에 접근해야할 동료가 있다면 SSH 유형을 하나 더 만들어 추가해줍시다.

 - [사용자 지정 TCP, 8080] : 8080 포트로 모든 IP가 접근 가능하도록 설정하였습니다.

 - [HTTPS, 443] : 443 포트로 모든 IP가 접근 가능하도록 설정하였습니다.

 4.9. 검토

  - 다음 항목을 검토 후 이상이 없다면 시작버튼을 클릭합니다.

   - OS : Amazon Linux 2

   - 인스턴스 유형 : t2.micro

   - 보안그룹

   - 스토리지 : 30GB

 4.10 키페어 설정

 - 키 페어 설정을 하게 되면 서버 접근 시 접근자의 개인키와 서버의 공개키를 체크합니다. 보안그룹을 설정했지만 키페어 설정도 꼭 필요합니다.

  - 현재 보안 그룹 설정을 했기 때문에 마스터 서버로의 접근은 '내 IP'에서만 가능합니다. 악의적인 사용자가 '나'의 서버 접근 정보를 알고있다고 하더라도 IP가 달라 접근이 불가능합니다. 하지만 극단적인 예로, 내 옆집에 사는 사람이라면 제 공인 IP로 접근이 가능할 수 있고, 그렇게 되면 제 서버로의 접근도 가능할 수 있습니다. 만약, 사내 프로젝트를 위해 EC2 서버를 생성하고 보안그룹을 '내 IP'로 설정하였습니다. 그렇게되면 같은 사내망을 사용하는 모든 사람들이 접근 가능하게 됩니다.

  - 이런 유형의 접근을 막기 위해 필요한 것이 바로 키페어입니다. 키페어를 설정하면 서버의 공개키와 대응되는 개인키를 발급받게 되고, 실제 접근 시 이 키파일을 서버로 제공해야합니다.

 - RSA 유형으로 키 페어 생성 선택 후 키 페어 이름에 프로젝트 명을 넣습니다. 그 후 키 페어 다운로드를 클릭합니다.

 - pem 확장자의 개인키 파일 다운로드가 확인되면 인스턴스 시작 버튼을 클릭합니다.

 4.11. EC2 인스턴스 생성 완료

  - 다음과 같은 화면이 나올 경우 EC2 인스턴스가 생성 완료된것입니다.

  - 이제 개인키 파일을 통해 내가 만든 EC2 서버에 접속해볼 차례입니다.

5. EC2 서버 접속

 - 서버에 접근하기 위해서는 몇가지 과정이 필요합니다. 차근차근 밟아봅시다.

 5.1. putty, puttygen 설치

  - putty : SSH를 통한 서버 접속에 사용합니다.

    * 설치 url : https://putty.softonic.kr/

  - puttygen : 서버로 접근하기 위해서는 개인키 파일(.pem)을 .ppk 확장자로 변환해야 하며, 이 변환에 사용합니다. 

    * 설치 url : https://www.puttygen.com/download-putty

 5.2. puttygen 실행

  - puttygen.exe 실행 후 Conversions > import key 를 선택합니다.

 5.3. 개인키 파일 임포트

  - 아까 발급받은 개인키 파일을 선택합니다.

 5.4. ppk 파일 생성

  - 다음과 같은 화면이 조회되면 Save private Key 버튼을 선택하여 ppk 파일을 생성합니다.

  - 알림 메시지가 하나 뜨는데 무시하고 예를 누릅니다.

  - 파일이 생성되었다면 이제 서버로 접속할 차례입니다.

 5.5. putty 실행

  - putty를 실행한 후 HostName에 ec2-user@[퍼블릭 DNS]를 입력합니다.

  - ec2-user는 Amazon Linux 2 생성 시 자동 생성되는 ID 입니다. 다른 OS를 선택했다면 헤매지 말고 구글링!

  - 만약, 퍼블릭 DNS를 모르겠다면 EC2 콘솔에 접속해 인스턴스 상세보기로 확인할 수 있습니다.

 5.6. Auth 설정

  - putty 카테고리의 Connection > SSH > Auth를 선택 후 Browse 버튼을 선택하여 생성한 ppk 파일을 로드합니다.

 5.7. Open!

  - 모든 설정이 끝났습니다. 이제 Open 버튼을 눌러 서버에 접속해봅시다!

  - 다음과 같은 화면이 뜬다면 성공입니다!

  - 만약 에러가 뜨신다면 다음을 확인해보세요.

    1) 서버에 대한 개인키가 맞는지

    2) OS에 대한 ID (ex. amazon linux = ec2-user)가 맞는지

    3) HOST NAME에 퍼블릭 DNS가 정확하게 입력됐는지

  - 저의 경우 2번과 3번이 잘못되어 시간이 걸렸답니다 ㅠㅠ.

6. 마치며

 - 예전에 책을 보며 무작정 따라한 적이 있는데, 이게 무슨 설정이고, 왜 하는지도 이해가 가지 않았었던것 같아요. 용어의 의미와 역할을 이해하려고 노력하며 다시 책을 따라해보세요! 훨씬 의미있고 기억에 남을거에요!