programmer.cwchoiit

 

Auto Scaling

Auto Scaling은 자동으로 EC2 인스턴스의 개수가 줄거나 늘거나 하는 기능을 말한다. Auto Scaling은 두 가지 경우로 나눌 수 있다.

• Scaling Up/Down: 인스턴스 타입의 크기를 크거나 작게 만드는 경우
• Scaling Out/In: 인스턴스의 개수를 늘리거나 줄이는 경우

Auto Scaling Group

이 Auto Scaling 기능을 이용하기 위해 Auto Scaling Group이 만들어져야 하는데 여기서 최소, 희망, 최대 인스턴스 개수를 설정할 수 있다.

 

그리고 사용자가 설정한 Auto Scaling 조정 정책, 즉 EC2가 감내할 수 있는 부하의 기준을 정하면 인스턴스 개수가 최대 최소의 인스턴스 내에서 자동으로 조절이 된다. 이런 설정을 하는 것이 Auto Scaling Group이라고 보면 된다.

 

 

Launch Template, Golden AMI

Launch Template은 인스턴스를 생성할 때 결정하는 네트워크 정보, 타입, 키페어, AMI(Amazon Machine Image)와 같은 설정값들에 대한 템플릿을 의미한다.

AMI는 인스턴스 생성할 때 지금까지 사용했던 Amazon Linux Image와 같은 그 이미지를 말한다.

 

Auto Scaling Group을 사용할 때 이 Launch Template을 사용해서 추가적으로 생성될 인스턴스를 만들 수 있게 구성할 수 있다. 이 때, Launch Template을 통해서 사용되는 이미지를 Golden AMI라고 한다. 이 Golden AMI는 OS를 포함해서 필요한 필수 패키지들이 설치되어 있는 표준 이미지를 말한다. Golden 이라는 단어의 의미는 딱히 중요하지 않다. 그냥 완성적이고 필수 패키지들이 잘 적용이 된 상태라서 Golden 이라는 이름이 붙어졌다. 이후에 직접 만들어보면서 더 이해를 하겠지만 직접 나만의 이미지를 만들어서 기존에 사용했던 동일한 인스턴스 상태와 환경을 구성할 수 있게 해준다. 그리고 이런 방식이 앞서 얘기한 Immutable Infra를 만들게 해준다.

 

 

Autoscaling Policy

위에서 Auto Scaling 조정 정책이라는 말을 했는데 그것을 알아보자. 이 조정 정책이란 사용자가 "이런 조건에 도달하면 Auto Scaling 기능을 활성화해줘!"라고 정의해놓은 정책을 말한다. 그리고 크게 3가지가 있다.

 

• 단순 조정 정책 (Simple Scaling)
  • Cloudwatch 경보 위반을 기준으로 사용
  • Cloudwatch 경보 발생 시 특정 인스턴스 개수만큼 스케일 인/아웃 설정이 가능
  • 또는 Cloudwatch 경보 발생 시 Auto Scaling Group의 퍼센티지(%)만큼 스케일 인/아웃
  • 단점은 확장에 대한 세분화된 제어를 제공하지 않음
• 대상 추적 조정 정책 (Target Tracking Scaling)
  • Auto Scaling Group이 항상 유지해야 하는 조정 지표 및 지표값을 지정한다. 예를 들어, CPU 80%로 설정하면 항상 그만큼을 유지하도록 자동 스케일 인/아웃 실행
  • 4가지 지표 선택이 가능
    1. ASG Average CPUUtilization: Auto Scaling Group의 평균 CPU 사용률
    2. ASG Average NetworkIn: Auto Scaling Group이 모든 네트워크 인터페이스에서 수신한 평균 바이트 수
    3. ASG Average NetworkOut: Auto Scaling Group이 모든 네트워크 인터페이스에서 보낸 평균 바이트 수
    4. ALB Request CountPerTarget: Auto Scaling Group이 ALB 대상 그룹과 연결된 경우 대상 그룹의 대상 당 완료된 요청 수
• 단계 조정 정책 (Step Scaling)
  • 위 단순 조정 정책의 단점인 세분화된 제어를 보완하기 위한 정책
  • Cloudwatch 경보 위반의 정도에 따라 인스턴스 개수를 단계적으로 조정하는 작업을 설정 가능
  • 단계적 조정을 통해 정책은 경보 위반 이벤트 도중에도 추가 경보에 계속 응답할 수 있게 된다.

 

 

 

Auto Scaling Group의 Lifecycle

Auto Scaling Group으로 인스턴스를 만들고 지울 때 인스턴스의 생명주기가 있다. 그림을 보자.

 

우선 Auto Scaling Group으로부터 인스턴스가 새로 생성되는 Scale Out일 때 인스턴스 상태는 'Pending'이다. Pending에서 인스턴스가 완전히 띄워졌을 때 'InService'상태가 된다. InService상태에서 Health Check가 실패하거나 Scale In이 될 때 'Terminating'상태가 된다. 이 Terminating에서 완전히 인스턴스가 제거된 상태는 'Terminated'이다.

 

그 외 InService상태에서 인스턴스를 떼어내면 'Detaching'상태가 되고 InService상태에서 인스턴스를 Standby로 설정하면 'EnteringStandby'상태가 된다. 

 

 

Auto Scaling 직접 사용해보기

이제 Auto Scaling 기능을 실제로 사용해보자. 우선 어떤 형태의 모습이 그려질지는 다음과 같다.

 

기존에 가지고 있는 EC2 인스턴스가 있고 그 인스턴스를 가지고 Auto Scaling Group을 만들어서 Launch Template을 만든다. 그리고 정책을 설정해서 정책 조건에 도달하면 자동으로 인스턴스가 늘어나는 모습을 확인할 예정. 앞단에는 LB를 붙여서 인스턴스가 3개가 만들어지면 부하 분산 처리가 잘 되는지도 확인해보자.

 

 

필요한 보안 그룹 생성

위 그림에서 LB가 있다. LB에 관련된 보안 그룹을 먼저 생성하자.

EC2 > Security Groups에서 보안 그룹 생성.

이름과 VPC를 설정하고, 인바운드 규칙에는 80에 모두(0.0.0.0/0)가 들어올 수 있게 설정한다. 이 상태로 생성.

 

이번엔 새로 만들 EC2에 대한 보안 그룹을 생성한다. 위 그림에서 총 3개의 EC2가 있는데 이들의 표본이 될 EC2 하나는 만들어야한다. 그래서 보안 그룹 하나를 더 생성.

 

하단에 보면 3개의 인바운드 규칙이 있다.

22는 우리가 항상 사용하던 OpenVPN으로 SSH 접속할 수 있게 설정

80도 역시 OpenVPN을 통해 접속할 수 있게 설정

80중 또다른 하나는 방금 막 만든 LB 보안 그룹으로 설정

 

 

표본 EC2 생성

위에서 말한 표본 EC2를 생성한다. Name 설정은 자유롭게하고 AMI는 Amazon Linux로 선택, 타입은 디폴트인 t2.micro, 키페어는 계속 사용해왔던 키페어로 선택, 네트워크 설정에서는 계속 사용했던 VPC, Private Subnet App A로 하고 보안 그룹은 방금 만든 보안 그룹을 선택하고 생성한다. (이제 EC2 만드는 건 이렇게 말로만 하겠다.)

 

이제 OpenVPN에 접속해서 이 방금 만든 EC2를 SSH로 접속하자. 접속했으면 여기에 필요한 패키지들을 설치해야 한다. 그것들을 정리한 README.md 파일 경로는 다음과 같다.

 

GitHub - chyoni/aws-ec2meta-webpage: Auto Scaling 공부용 EC2 웹 페이지

Auto Scaling 공부용 EC2 웹 페이지. Contribute to chyoni/aws-ec2meta-webpage development by creating an account on GitHub.

github.com

 

README.md에 적힌 필요 패키지들이다.

sudo -s
sudo yum -y install httpd php git
dnf -y localinstall https://dev.mysql.com/get/mysql80-community-release-el9-4.noarch.rpm
dnf -y install mysql mysql-community-client
sudo systemctl start httpd
sudo systemctl enable httpd
sudo cd /var/www/html/ && sudo git clone https://github.com/chyoni/aws-ec2meta-webpage.git

 

제일 마지막 소스를 내려받았으면 httpd를 restart해주자.

systemctl restart httpd

 

이제 EC2의 프라이빗 IP를 통해 Clone받은 웹 페이지가 잘 출력되는지 확인해보자.

http://ec2-private-ip/aws-ec2meta-webpage/index.php

 

다음과 같은 화면이 나오면 된다.

 

표본 EC2로 AMI 만들기

이제 우리가 만든 EC2로 필요 패키지들과 설정까지 다 끝냈으니 이 EC2로 AMI를 만들어보자.

표본 EC2를 선택한 후 Actions > Image and templates > Create image 선택

 

거의 다 기본값 설정으로 만드는데 이미지 이름과 설명은 작성해주고, No reboot에 Enable 체크를 해줘야한다. 이건 이 이미지를 만들 때 체크를 안하면 해당 EC2가 재부팅이 된다. 그것을 안하고자 체크하고 이미지 생성

 

이제 잘 만들어졌는지 확인해보자. EC2 > Images > AMIs 가보면 방금 만든 이미지가 생성중인 모습을 확인할 수 있다. 

 

 

만든 AMI로 Launch Template 생성

AMI를 가지고 Launch Template을 만들어보자.

EC2 > Instances > Launch Templates에서 'Create launch template' 클릭

 

Name, Description을 입력한다.

 

여기 부분이 중요한데, AMI를 선택할 때 My AMIs 탭을 선택하고 Owned by me를 클릭한다. 그리고 방금 만든 AMI를 선택

 

그 다음, 인스턴스 유형과 키페어는 다음과 같이 설정한다. 키페어는 기존에 사용했던 키페어를 계속 사용한다.

 

그 다음, 네트워크 설정이다. Subnet은 프라이빗 서브넷 App A에 그러니까 표본 EC2가 있는 같은 서브넷으로 선택하고 보안 그룹은 저 EC2와 같은 보안 그룹을 선택한다.

 

나머지는 기본값으로 설정한 후 만들어보자. 만들고 나면 리스트에 만든 Launch Template이 보여진다.

 

 

ALB 생성

이제 앞단에 쓰일 로드밸런서를 만든다. EC2 > Load Balancers에서 로드밸런서 하나를 만들자.

 

유형은 다음처럼 ALB를 선택한다.

 

Basic configuration은 다음과 같다.

 

네트워크 설정은 다음과 같다. AZ-a, AZ-c 두개를 사용한다.

 

보안 그룹은 앞에서 만든 ALB용 보안 그룹을 선택한다.

 

그리고 이 ALB를 만들기 전 대상 그룹을 먼저 만들어야 했는데 만들지 않았다. 그래서 Listerners and routing 섹션에 다음처럼 Create target group 링크를 클릭해서 만들자.

 

 

대상 그룹을 만들 때 유형은 인스턴스, 프로토콜과 포트는 HTTP:80용으로 한다.

 

그리고 VPC는 계속 사용했던 것을 선택하면 되고 Health check는 다음 경로로 설정한다.

 

다음으로 넘어가면 대상을 등록하면 된다. 위에 만든 Auto Scaling을 위한 EC2를 선택하고 'Includ as pending below' 클릭

 

그리고 만들면 이제 다시 로드밸런서 만들었던 화면으로 돌아가서 방금 만든 대상 그룹을 선택한다.

 

이렇게 설정하고 로드밸런서를 생성한다. 생성하면 리스트에 다음과 같이 노출된다.

 

이 만든 로드밸런서를 Route 53에 연결하자. Route 53 > Hosted zones로 가서 우리의 도메인을 선택하고 레코드 하나를 추가하자.

 

레코드를 다음과 같이 생성한다. subdomain은 autoscaling으로 설정했고 방금 만든 ALB에 붙인다.

 

 

 

이제 방금 만든 도메인으로 접속해보자. 그런데, HTTPS로 접속 가능하게 해보자. 우선 로드밸런서로 가서 규칙 하나를 추가해주자.

이렇게 설정하고 규칙하나를 추가해주자. 그리고 우리가 ALB에 적용한 보안 그룹 역시 443은 열려있지 않기 때문에 인바운드 규칙 하나를 추가해줘야 한다. 이 ALB에 적용한 보안 그룹으로 가서 인바운드 규칙 추가를 누르고 다음 443에 대해 설정해주자.

 

다 설정이 끝났으면 접속해보자. 잘 보여야 한다.

 

 

 

Auto Scaling Group 생성하기

이제 Auto Scaling Group을 만들어보자. EC2 > Auto Scaling > Auto Scaling Groups 로 들어가자.

 

생성하기를 누르고 이름을 지정해준다. 그리고 Launch template을 우리가 위에서 만든 것으로 지정한다. 버전은 그냥 Default로 하면 된다. 그리고 Next

 

VPC는 계속 사용하던 VPC로 설정하고 가용 영역과 서브넷은 A존 C존에 App용 서브넷을 선택한다. 그리고 Next

 

다음은 로드밸런서를 선택한다. 만든 로드밸런서를 선택하고 그에 맞게 설정한 대상 그룹을 지정한다.

 

Health Check 주기는 10초로 변경하자. 300초는 너무 길다. 그리고 Next

 

계속 Next로 넘어가고 태그를 만드는 화면에서 태그 하나를 생성하자. 태그의 키는 Name, Value는 적절한 값을 넣어서 태그 하나를 생성하고 Next

 

그러면 요약 부분이 나오고 확인 후 생성하면 된다. 생성하면 다음처럼 리스트에 잘 나온다.

 

들어가서 확인해보면 현재 Desired, Minimum, Maximum capacity가 전부 '1'로 되어 있다. 변경해보자. 우측 Edit 버튼 클릭

 

최대 용량을 3으로 변경해보자.

 

 

이제 Automatic scaling에서 정책을 생성해야 한다. Automatic scaling 탭에서 Dynamic scaling policies 섹션에 생성 버튼을 누른다.

 

정책 타입은 Target tracking scaling으로 하고 Metric type은 Average CPU utilization으로 선택하자. Target value는 70으로 설정하고 Instance warmup은 10초로 설정하고 만들어보자.

 

생성하면 다음과 같이 정책 하나가 추가됨을 확인할 수 있다.

 

정책은 정책이고 이렇게 Auto Scaling Group을 정상적으로 만들면 이 그룹에 의해 자동으로 인스턴스가 만들어진다. 확인해보자.

Auto Scaling Group의 Instance management 탭으로 가면 다음과 같이 인스턴스 하나가 'InService'상태인 것을 확인할 수 있다. 이는 Auto Scaling Group으로부터 자동으로 만들어진 인스턴스다.

 

실제로 인스턴스에 가서 리스트를 확인해보면 다음처럼 우리가 만든 표본 EC2가 있고 Auto Scaling Group이 만든 EC2가 둘 다 구동중이다.

 

Auto Scaling Group으로 만들어진 인스턴스들만 로드밸런서가 취급을 할 수 있도록 로드밸런서 쪽 대상 그룹에서 우리가 만든 표본 EC2는 날려주자. EC2 > Load Balancing > Target Groups에서 위에서 만든 로드밸런서에 적용할 대상 그룹에 들어가보면 다음과 같이 타겟이 두개다. 하나는 앞서 만든 표본 EC2, 하나는 Auto Scaling Group으로부터 만들어진 EC2. 표본 EC2를 대상 그룹에서 Deregister하자.

 

Deregister를 하면 다음처럼 상태가 Draining으로 변하고 이 대상 그룹에 타겟에서 빠진다.

 

 

Auto Scaling 확인하기

이제 우리가 만든 Auto Scaling Group의 정책에 따라 CPU 사용률이 70이 넘어가면 Scale Out이 발생하는지 확인해보자. 그러기 위해 Auto Scaling Group이 만들어준 EC2로 들어가서 스트레스를 부여하자.

 

우선 해당 EC2로 들어가야 한다. 해당 EC2의 프라이빗 IP를 확인해서 접속해보자. 내부로 들어오면 루트 유저로 변경하자.

sudo -s

 

이제 stress 패키지를 설치하자.

yum install stress

 

설치가 끝났으면 stress를 실행해보자.

stress -c 1& # 백그라운드로 stress 실행

 

잘 실행중인지 확인

ps -ef | grep stress

 

다음과 비슷하게 결과가 나올것.

root        4798    4279  0 01:08 pts/0    00:00:00 stress -c 1
root        4799    4798 98 01:08 pts/0    00:00:07 stress -c 1
root        4805    4279  0 01:08 pts/0    00:00:00 grep --color=auto stress

 

그리고 CPU 사용률을 확인해보자.

top

 

이러면 Auto Scaling Group에서 만든 정책 조건에 부합한다. 다음을 보자. 이 부분이 Auto Scaling Group에서 설정한 Dynamic scaling policies중 하나다. 저기 보면 'As required to maintain Average CPU utilization at 70' 이런 문장이 있는데 이게 CPU 평균 사용률을 70으로 유지하는데 필요한 경우이다. 우리가 99%까지 CPU 사용률을 높였기 때문에 이 조건에 따라 EC2가 늘어날 것이다.

CPU Policy
Target tracking scaling
Enabled
As required to maintain Average CPU utilization at 70
Add or remove capacity units as required
10 seconds to warm up before including in metric
Enabled

 

Activity 탭에서 이 부분을 유심히 봐보자.

 

당장 만들어지지 않을 수 있다. CPU 지표가 Cloudwatch로 전달이 되고 Cloudwatch에 있는 수치를 Auto Scaling Group에서 확인하는데까지 시간이 걸릴 수 있기 때문에 실시간 반영은 되지 않을 수 있다. 

 

조금 기다리면 다음과 같이 새로운 인스턴스가 Launching 된다는 활동 내역이 나온다. 

 

우리가 설정한 최대 3개까지 모두 만들어진 모습이다.

 

 

이렇게 3개까지 만들어지면 이제 로드밸런서는 이 세개의 인스턴스를 부하분산 처리해주면서 라운드로빈 방식으로 한번씩 돌아가면서 요청을 전달한다. 이렇게 Scale Out 현상을 잘 확인해보았다. 그럼 반대로 CPU 사용률에 대한 스트레스 프로세스를 죽였을 때 인스턴스가 하나씩 사라져야한다. Scale In. 그것을 확인해보자.

 

우선 stress 프로세스를 죽이자. 프로세스 ID를 확인해서 kill.

kill -9 stress-pID

 

스트레스 프로세스가 띄워져 있는지 확인

ps -ef | grep stress

 

 

자 이제 Auto Scaling Group으로 가서 인스턴스가 하나씩 종료되는지 확인하자. 다음처럼 하나씩 인스턴스가 종료된다고 나온다. 

 

 

이 인스턴스가 종료되는 방식은 Auto Scaling Group의 Details 탭에 가보면 Advanced configurations 섹션이 있다.

거기에 Termination policies가 Default인데, 이 Default는 가장 먼저 생성된 인스턴스를 가장 먼저 지우는 방식이다.

Edit 버튼을 눌러서 Terminate policies를 쭉 보면 다음과 같이 여러 방식이 있다.

이런 원리로 인스턴스가 종료된다는 것을 알아두면 된다.

 

 

VPC

VPC는 Virtual Private Cloud의 약자로 AWS에서 논리적으로 생성하는 독립적인 네트워크를 말한다. VPC안에 여러 서브넷을 만들 수 있는데 서브넷이라 함은 네트워크 내부의 네트워크이다. 서브넷은 네트워크를 보다 효율적으로 만드는데 서브넷을 통해 네트워크 트래픽은 불필요한 라우터를 통과하지 않고 더 짧은 거리를 이동하여 대상에 도달할 수 있다. 

 

VPC안에 구성할 수 있는 서브넷은 퍼블릭 서브넷과 프라이빗 서브넷이 있다. 

 

퍼블릭 서브넷

퍼블릭 서브넷은 외부와의 자유로운 통신이 가능한, 외부 인터넷 구간과 직접적으로 통신할 수 있는 공공 네트워크이다.

프라이빗 서브넷

프라이빗 서브넷은 외부에서 직접 접근할 수 없는 네트워크이다. 프라이빗 서브넷에 실제 서버가 동작하게끔 설정하고 외부에서 이곳으로 직접 접근이 불가능하게 한 후 퍼블릿 서브넷을 통해 외부에서 요청이 들어오면 퍼블릿 서브넷과 프라이빗 서브넷 사이에 연결을 하여 통신한 후 프라이빗 서브넷에서 필요한 요청 데이터를 NAT Gateway를 통해 요청에 응답하게 설계할 수 있다.

 

이 개념을 이해하려면 직접 VPC, Public Subnet, Private Subnet, NAT Gateway 등 만들어보기로 하자.

 

 

설계할 네트워크 전체 그림은 다음과 같다.

 

 

VPC 생성

AWS Console에 'VPC'를 검색해서 나오는 서비스를 클릭한다.

 

메인 화면 좌측 사이드바에 Virtual private cloud 섹션에 'Your VPCs'를 클릭해서 우측 상단 'Create VPC' 클릭

 

VPC Name tag와 CIDR을 설정 후 나머지는 기본값으로 설정한 다음 'Create VPC'를 클릭

 

생성한 VPC 확인

 

 

이렇게 VPC가 생성됐으면 VPC에서 사용될 서브넷을 총 6개를 만든다. 그중 2개는 Public 나머지 4개는 Private으로 설정한다.

가용영역을 둘로 나누어서 AZ1에는 Public Subnet 1개, Private Subnet 2개로 만들고 AZ2는 Public Subnet 1개, Private Subnet 2개로 하여 전체 VPC에 두 개의 가용영역이 있고 그 각각의 가용영역에 Public 1, Private 2 서브넷을 각각 가지는 그림으로 만든다. 

 

 

Subnet 생성

VPC 메인 화면에서 좌측 Subnets을 클릭하고 나온 화면의 우측 상단 'Create subnet' 클릭

 

서브넷 생성 화면에서 서브넷이 들어갈 VPC를 선택하는데 방금 만든 VPC를 선택

 

첫 번째 서브넷을 만들자. AZ-a에 public subnet을 만든다. 서브넷의 대역은 10.1.1.0/26으로 설정한다.

 

 

서브넷 추가를 위해 'Add new subnet'을 클릭해서 또 다른 서브넷을 만든다. AZ-C에 생성될 퍼블릭 서브넷이다. 대역은 10.1.1.64/26으로 설정한다.

 

지금까지가 퍼블릭 서브넷을 만드는 내용이었다. 각 AZ에 한 개씩 퍼블릭 서브넷이 있고 각 AZ에 이제 프라이빗 서브넷 2개씩을 할당할 것. 또 서브넷을 만들자. 

 

이제 프라이빗 서브넷이다. AZ-a에 10.1.1.128/27 대역으로 한 개를 생성한다.

 

AZ-c에 같은 APP용 프라이빗 서브넷을 만들자. 대역은 10.1.1.160/27이다.

 

AZ-a에 DB용 프라이빗 서브넷을 생성하자. 대역은 10.1.1.192/27이다.

 

마지막으로 AZ-c에 DB용 프라이빗 서브넷을 생성한다. 대역은 10.1.1.224/27이다.

 

이렇게 총 6개의 서브넷을 만들고 최종적으로 'Create subnet'을 클릭하자. 총 6개의 서브넷이 생성됨을 확인할 수 있다.

 

 

 

인터넷 게이트웨이 생성

이제 인터넷 게이트웨이를 생성해 보자. 인터넷 게이트웨이는 VPC가 인터넷과 통신할 수 있도록 해준다. 

인터넷 게이트웨이를 생성하려면 Virtual Private Cloud 섹션에 Internet gateways를 선택하자.

 

우측 상단 'Create internet gateway'를 클릭해서 만들자. Name tag를 입력하고 생성을 끝마치면 된다.

 

생성하고 나면 인터넷 게이트웨이 메인 화면에서 우측 상단 'Actions' 셀렉트 박스가 있다. 거기에 Attach to VPC를 클릭해서 만든 VPC와 인터넷 게이트웨이를 연결하자.

 

위에서 만든 VPC와 연결을 하면 된다.

 

 

라우팅 테이블 생성

라우팅 테이블은 VPC 내 서브넷들이 특정 IP로 향할 때 어디로 가야 하는지에 대한 정보를 저장하고 있는 것으로 생각하면 된다.

우선 만들면서 이해하면 더 빠를 것 같다.

 

마찬가지로 VPC > Virtual private cloud > Route tables로 이동하자. 우측 상단의 Create route table을 클릭해서 생성하면 된다.

Name과 VPC를 설정한 후 생성하면 끝난다. 지금 생성하는 라우트 테이블은 Public Subnets을 위한 라우트 테이블이다.

 

하나 더 생성한다. 이번엔 Private Subnets을 위한 라우트 테이블이다. 이름만 'my-private-route'로 달리 생성하자.

그렇게 되면 방금 만든 두 개의 라우트 테이블이 있다. 

public route는 public subnet을 위함이다. public subnet은 외부와 통신이 가능해야 한다. 그래서 외부와의 통신을 하기 위한 인터넷 게이트웨이를 만들었고, public route에게 해당 인터넷 게이트웨이를 알려줘야 한다. 그 작업을 위해 my-public-route 내부로 들어가자. 하단 Routes 탭에 Edit routes를 클릭하면 된다. 여기 설정된 기본 라우트 탭은 라우트 테이블을 만들면서 연결한 VPC가 기본으로 테이블에 등록되어 있다.

즉, 10.1.0.0/16은 로컬과의 통신을 하면 된다는 뜻이고 여기서 설정할 0.0.0.0/0은 외부로 나갈 인터넷 게이트웨이와 통신을 하게 설정하면 된다.

 

즉, 최종 public-route는 다음과 같은 설정값을 가진다.

이 뜻은 이 public route에 할당된 서브넷들은 VPC 내부(10.1.0.0/16)에서는 VPC 내부적으로 통신을 하고 그 외 모든 목적지(0.0.0.0/0)는 인터넷 게이트웨이와 통신을 할 것이라는 의미가 된다. 

 

private route는 VPC 내부와 밖에서는 안으로 들어오지 못하게 하고 안에서 밖으로는 나갈 수 있어야 하기 때문에 NAT Gateway가 필요하다. NAT Gateway는 내부에서 외부로 나가는 것만 허용한다. 그래서 private route에 등록할 NAT Gateway를 먼저 만들어보자.

 

NAT Gateway 생성

NAT Gateway란 무엇일까?

 

퍼블릭 서브넷과 프라이빗 서브넷이 공존할 때 프라이빗 서브넷은 인터넷과 통신이 불가능한 네트워크 공간이고 퍼블릭은 인터넷과 통신이 가능한 네트워크 공간이다. 이때 프라이빗 서브넷은 말 그대로 프라이빗하게 즉, 보안에 있어 취약하면 안 되는 민감한 데이터를 다루는 곳이어야 한다. 예를 들면 데이터베이스가 있는 곳. 자, 데이터베이스를 프라이빗 서브넷에 위치한 EC2에 설치해 보자. 여기서 의문이 생긴다.

근데 인터넷과 통신이 안되는데 어떻게 설치를 하지?

 

그렇다. 인터넷과 통신이 불가능한데 설치를 할 수 있을 리 없다. 즉, 이 프라이빗 서브넷일지라도 인터넷과의 통신이 필요한 경우가 더러 있는데 이럴 때 인터넷과 통신을 가능하게 해주는 녀석이 바로 NAT Gateway이다. 

 

위 그림에서 Private subnet App A에서 인터넷과 통신을 하고 싶으면 인터넷과 통신할 수 있는 Public subnet A에 있는 NAT Gateway에게 트래픽을 알려야 한다. 그래서 흐름은 다음과 같다.

중요!
1. Private subnet App A에서 인터넷(ex: 211.158.2.3)으로 요청을 보낸다.
2. Private subnet App A에 매핑된 route table을 보니 로컬로 등록된 IP가 아닌 IP들은 전부 NAT Gateway를 향한다.
3.  NAT Gateway로 트래픽을 보낸다.
4. NAT Gateway는 받은 트래픽을 실제 요청지를 저장한 후 다시 Router로 보낸다. Router는 Public subnet A에 매핑된 route table을 확인한다.
5. 확인해 보니 0.0.0.0/0은 Intenet Gateway로 향하고 있다. Internet Gateway로 트래픽을 보낸다.
6. 인터넷으로의 요청에 대한 응답을 Internet Gateway가 받았다. 받으면 이 응답을 Router가 받아서 route table을 확인한다. 응답받을 곳은 NAT Gateway 이므로 NAT Gateway로 향한다.
7. NAT Gateway로 응답을 받고 이 녀석이 저장해 둔 원래 요청지인 Private subnet App A로 다시 응답을 보낸다.
8. Router는 응답을 보낼 주소를 route table에서 찾는다. 찾아보니 Private subnet App A를 가르키고 있다. 해당하는 곳으로 응답을 보낸다.

이 흐름이 NAT Gateway를 통한 Private subnet이 인터넷과 통신하는 방법이다. 이 흐름을 보니 왜 NAT Gateway가 Public subnet에 존재하는지 더 명확하게 알 수 있었다. 인터넷과 통신을 하기 위해서는 Public subnet에 매핑된 route table을 참조해야하기 때문이다.

 

Public subnet에 매핑된 route table은 0.0.0.0/0이 Internet Gateway를 향하고 있고 Private subnet에 매핑된 route table은 0.0.0.0/0이 NAT Gateway를 향하고 있기 때문이다.

 

프라이빗 서브넷의 인스턴스가 다른 VPC, 온 프레미스 네트워크 또는 인터넷의 서비스에 연결하는 데 사용할 수 있는 가용성이 뛰어난 관리형 NAT(Network Address Translation) 서비스를 말한다.

 

NAT Gateway는 두 가지 유형이 있다.

• 퍼블릭: 프라이빗 서브넷의 인스턴스는 퍼블릭 NAT Gateway를 통해 인터넷에 연결할 수 있지만 인터넷으로부터 원치 않는 인바운드 연결을 수신할 수 없다. 
• 프라이빗: 프라이빗 서브넷의 인스턴스는 프라이빗 NAT 게이트웨이를 통해 다른 VPC 또는 온프레미스 네트워크에 연결할 수 있다.

 

NAT Gateway를 생성해 보자. VPC > Virtual private cloud > NAT gateways로 들어와서 'Create NAT gateway'를 클릭하자.

 

생성 화면에서 NAT gateway settings 섹션에 Name, Subnet을 설정한다. Subnet은 이 NAT Gateway가 어디에(어떤 Subnet) 위치할 것인지에 대한 설정이다. 생성한 퍼블릭 서브넷 A에 위치시킬 것이고 '탄력적 IP 할당' 버튼을 클릭해서 Elastic IP를 할당시킨다.

Elastic IP를 NAT gateway에 할당하면 NAT gateway의 이 Elastic IP를 소스 IP로 사용해서 인터넷 게이트웨이로 트래픽을 보낼 수 있고 VPC 외부로 내보낼 수 있게 된다.

 

이렇게 설정하고 하단 'Create NAT gateway' 버튼을 클릭해서 NAT gateway를 생성한다. 그러면 생성한 NAT gateway가 리스트에 노출됨을 확인한다. 

 

이제 이 NAT gateway를 프라이빗 라우트 테이블에 연결해 주자. 그러면 프라이빗 서브넷에서 외부로 나갈 수 있게 설정하는 것.

Route tables 화면에 생성한 'my-private-route'를 선택하고 Routes 탭에서 'Edit routes'를 클릭한다.

 

기본 설정인 10.1.0.0/16은 VPC 대역이다. 즉 VPC 대역은 로컬로 라우팅을 한다는 의미이고 그 외 모든 대역(0.0.0.0/0)은 NAT gateway로 타겟을 설정한다는 의미가 된다.

 

이제 이 설정대로 움직일 서브넷들을 각 라우트 테이블에 연결해 주면 된다. public route에는 퍼블릭 서브넷들을, private route에는 프라이빗 서브넷들을 연결해주면 된다.

 

'my-public-route'를 선택하고 하단 Subnet associations에 'Edit subnet associations'를 클릭한다.

 

서브넷 선택 화면에서 퍼블릭 서브넷들을 선택하고 저장한다.

 

다음은 my-private-route를 선택하고 서브넷을 연결한다. 여기에는 프라이빗 서브넷들은 선택하면 된다.

 

 

 

EC2 인스턴스 생성

이제 Public subnet A에 EC2 인스턴스를 만들어보자. 이 인스턴스는 Bastion(요새, 보루 즉 거쳐가는 곳을 의미) Host라는 개념으로 보면 된다. 여기를 통해서 AWS DevOps 유저가 직접 접근하여 Private subnet에 있는 EC2 인스턴스에 들어갈 수 있게 될 것.

 

 

Security group 생성

AWS Console에 EC2를 검색해서 EC2 Instances로 들어가자. 그래서 새로운 EC2 인스턴스를 만든다. 그러나 인스턴스를 만들기 전 한 가지 먼저 진행할 부분이 있는데 '보안 그룹' 생성을 먼저 하자. Security group을 생성해서 만들 EC2에 해당 보안 그룹을 적용할 것인데 이는 이 인스턴스에 SSH로 접속하는 인바운드 규칙을 만들기 위함이다. 위 큰 그림에서 볼 수 있듯 'AWS DevOps 유저는 Public subnet A에 있는 EC2에 직접 접근할 수 있어야 한다. 그것을 허용하게 하는 보안 그룹을 생성할 것이다.

 

EC2 > Network & Security > Security Groups에 들어가서 'Create security group'을 클릭하자.

 

생성하는 화면에서 Security group name, Description, VPC에 값을 지정한다. VPC는 위에서 만든 VPC를 선택한다.

하단 인바운드 규칙에서는 AWS DevOps 유저가 오로지 현재 본인 만이라고 가정하고 SSH 접속 허용 IP를 My IP로 할당하자.

 

그리고 생성하기를 누르면 리스트에 방금 만든 보안그룹이 보인다.

 

Bastion Host(EC2) 생성

이제 인스턴스를 생성해 보자. 생성 화면에서 인스턴스의 Name을 설정한다. 그리고 OS Image는 Amazon Linux를 사용한다.

 

Key pair는 새로 생성을 해도 되고 기존에 사용했던 key pair가 있으면 그대로 사용해도 된다. 지금은 새로 만들어 사용한다.

 

Network settings는 위에서 만든 VPC와 서브넷은 Public Subnet A로 설정하고 보안 그룹은 방금 막 만든 보안그룹으로 세팅한다.

 

나머지 값은 그대로 둔 채 생성을 한다. 인스턴스 리스트에 생성한 인스턴스가 잘 보인다.

 

Elastic IP를 생성한 EC2에 할당

이제 Elastic IP를 방금 생성한 EC2에 할당한다. Network & Security > Elastic IPs로 가서 우측 상단 Allocate Elastic IP address를 클릭한다.

 

모든 값은 기본값으로 두고 하단 'Allocate' 버튼을 누르면 방금 생성한 Elastic IP가 나오고 그 녀석을 선택해서 방금 만든 EC2에 할당한다.

 

EC2에 잘 할당됐는지 확인하기 위해 Instances로 가서 방금 만든 EC2에 저 Elastic IP가 잘 할당됐는지 확인해 보자. 생성한 EC2를 선택하면 하단에 정보가 나오는데 Public IPv4 주소를 보면 방금 생성한 Elastic IP가 잘 할당됐음을 확인할 수 있다.

 

 

Private Subnet App A의 인스턴스에 할당할 보안 그룹 생성

위 전체 네트워크 설계 그림에서 보면 Bastion Host(Public Subnet A의 EC2)에서 Private Subnet App A에 있는 인스턴스에 접속할 수 있는 상태이다. 이러기 위해서는 Private Subnet App A에 보안 그룹을 할당해서 Bastion Host로부터 SSH로 들어오는 인바운드 규칙을 할당해줘야 한다. 이 작업을 해주자.

 

EC2 > Network & Security > Security Groups > Create security group

 

Name, Description, VPC를 설정해 주고 (VPC는 위에서 만든 VPC) 인바운드 규칙에 SSH로 들어오는 것들 중 허용하는 소스는 위에서 Bastion Host에 할당한 보안 그룹만 할당한다. 즉 Bastion Host에 SSH로 접속 가능한 호스트는 이 Private Subnet App A의 인스턴스에도 SSH로 접속이 가능하다는 의미가 된다.

생성이 잘 됐으면 Private Subnet App A에 생성할 EC2를 만들자.

 

Private Subnet App A EC2 생성 

 

Name을 적절히 설정해주고 OS Image는 Amazon Linux, 그 외 다 기본값으로 설정하고 Key pair는 위에서 만든 EC2에 사용한 것을 그대로 사용한다.

 

Network settings는 VPC는 위에서 만든 VPC, Subnet은 Private Subnet App a, Security group은 방금 만든 보안 그룹을 선택하고 생성을 완료한다.

 

생성이 완료되면 인스턴스 리스트에 잘 보이면 된다.

 

 

Copy file over SSH

이렇게 생성이 다 됐으면 Bastion Host에서 Private EC2에 SSH로 접속이 가능해야 한다. 보안 그룹을 그렇게 세팅했으니까. 

근데 여기서 한 가지 더 해줄 작업이 있는데 보안 그룹은 Bastion Host로부터 SSH로 접속 가능하게 인바운드 규칙을 만들었는데 그때 사용할 Key pair는 그대로 같은 Key pair를 사용했기 때문에 Bastion Host에 접속할 키를 Bastion Host에도 저장해놔야 한다. 그러기 위해 로컬에서 SSH를 이용해서 다른 서버로 파일을 카피하는 명령어로 .pem키를 우선적으로 보내자.

scp -i <path-to-local-private-ssh-key> <path-to-local-file> <server-user@server-ip-address>:<path-to-destination-folder>

 

위 명령어로 로컬 파일을 SSH를 통해 다른 서버에 복사할 수 있다. 본인의 경우는 다음과 같이 실행했다.

scp -i my-ec2-keypair.pem ./my-ec2-keypair.pem ec2-user@43.200.54.122:/home/ec2-user

 

그리고 EC2(Bastion host)에 들어가서 확인

 

 

Connect 'Public Subnet A EC2' to 'Private Subnet App A EC2' via SSH

이제 진짜 Bastion host에서 private EC2에 접속해 보자. 우선 Private EC2의 Private IPv4 Address를 확인하자.

 

Bastion host에 들어간 후 다음 명령어로 private EC2에 들어가 보자. 당연히 다음처럼 명령어를 사용하려면 .pem 파일이 있는 경로에서 실행해야 한다.

ssh -i my-ec2-keypair.pem ec2-user@10.1.1.156

 

그러면 이와 같이 정상적으로 접속이 됐음을 확인할 수 있다.

 

들어와서 한 가지 더 확인할 게 있다. 바로 NAT gateway를 통해 내부에서 외부로 통신이 가능한지를 확인하는 것. 다음 명령어를 통해 외부 인터넷으로 통신이 가능한지 확인해 보자.

curl -v www.google.com

 

결과는 다음처럼 200 OK가 나와야 한다. 

 

 

OpenVPN을 이용해 Bastion Host 대신 Private Subnet EC2에 접속해 보기

위 전체 네트워크 설계 그림에서 변경되는 부분이다.

 

Public subnet A에는 OpenVPN용 EC2가 만들어질 예정이다. 그리고 그 OpenVPN을 통해서 Private EC2에 접속해 보자.

 

 

OpenVPN EC2 만들기

Name은 my-openvpn-ec2로 설정한다.

 

OS Image는 'openvpn'으로 검색

 

보이는 화면에서 AWS Marketplace AMIs에 가장 상위에 있는 OpenVPN Access Server 이미지를 선택한다.

 

나머지 설정은 그대로 하고 Key pair는 위에서 사용한 그대로 사용한다. 

 

이제 Network settings은 VPC는 위에 만든 VPC, Subnet은 public subnet A, 보안 그룹은 기본으로 설정된 보안 그룹 그대로 가져가되, 아래 규칙은 모두 My IP로만 가능하게 변경하자. 아래 사진 말고 더 있다. 나오는 거 전부 My IP로 선택.

 

 

이렇게 설정한 다음 생성해서 EC2를 만든다. 이렇게 만들었으면 Elastic IP를 이 EC2에 할당해줘야 한다. Elastic IP는 생성하고 할당하는 것까지 위에서 해봤으니 그대로 하면 된다. 할당했으면 EC2에 그 할당된 IP를 확인하여 SSH로 접속한다. 본인의 경우 Elastic IP는 다음과 같다. 접속 유저명은 'openvpnas'로 한다.

ssh -i my-ec2-keypair.pem openvpnas@3.34.163.7

 

접속하면 이러한 OpenVPN 설정 화면이 노출된다.

 

모두 기본값 설정으로 적용하고 설정이 완료되면 다음처럼 Admin URL이 보인다.

 

이 경로로 접속해 보자. 접속하면 다음처럼 경고 화면이 나오는데 '안전하지 않음'으로 접속하면 된다.

 

그러하면 드디어 이러한 화면이 나온다.

 

로그인하기 위해 유저 정보를 가져와야 하는데 기본값은 최초 OpenVPN 설정하는 부분에서 알려준다.

 

유저명은 'openvpn' 패스워드는 'aPlXOBiWw0RL'로 되어있다. 이렇게 로그인해 보자.

이렇게 로그인이 잘 되고 'Agree'를 클릭

로그인이 되면 좌측 USER MANAGEMENT > User Permissions에 들어가서 유저를 새로 만들어보자.

 

자동 로그인 설정과 패스워드를 입력하고 저장하자.

 

 

이제 이 유저로 로그인이 잘 되는지 Admin 패널이 아닌 일반 URL로 들어가서 로그인해 보자.

 

Sign In을 클릭하면 다음 화면이 나온다.

 

위 화면에서 OpenVPN Connect for all Platforms 섹션에서 본인의 OS에 맞게 설치를 하자.

본인의 경우 macOS라 다음처럼 보인다. 활성화 버튼을 토글 하면 Connect가 된다.

 

이제 OpenVPN으로 Public Subnet의 EC2에 접속이 되어 있는 상태이므로 로컬에서 Private Subnet App A의 EC2 인스턴스로 SSH로 바로 접속이 되는지 확인해 보자. 그러나 그전에, 위에서는 설정 안 한 게 있는데 OpenVPN EC2는 Bastion host랑은 다른 EC2이기 때문에 이 OpenVPN EC2를 생성했을 때 적용한 보안 그룹 또한 Private EC2에 인바운드 규칙으로 할당해줘야 한다.

 

Security Groups > my-private-ec2-sg에서 인바운드 규칙에 다음처럼 OpenVPN EC2를 생성했을 때 만든 보안 그룹을 추가한다. 

 

 

이제 접속해 보자.

EC2 > Instances에서 my-private-ec2의 private IP를 복사한 후 ssh로 접속해 보자.

ssh -i my-ec2-keypair.pem ec2-user@10.1.1.156

 

OpenVPN Connect를 하고 나면 로컬에서 다이렉트로 접근이 가능해진다.

 

당연히 위에서 테스트 한 Private EC2라서 NAT gateway를 통해 외부로 통신이 가능하다.

 

 

VPC Peering

이제 한 발 더 나아가서 Region이 다른 VPC간 Peering을 통해 서로 통신이 가능하도록 만들어보자.

그림은 다음과 같다.

서울과 도쿄에 있는 VPC간 Peering을 해서 서로 통신이 가능하게 해보자.

 

 

도쿄에서 VPC 생성

우선 Region을 Tokyo로 변경하자.

우측 상단 Region을 선택해서 원하는 Region으로 변경할 수 있다. 그리고 VPC를 만들어보자. 

 

생성 화면에서 VPC settings에 'VPC and more'를 선택하면 좀 더 템플릿 느낌으로 VPC와 그 외 Subnet, Network, Route tables등을 만들어준다.

 

여기서 추가 설정을 해주자. 우선 VPC IPv4 CIDR을 192.168.10.0/24로 설정한다.

 

그 다음 AZ는 2개, Public subnets 2개, Private subnets 2개, NAT gateway는 생성하지 않고, VPC endpoint도 생성하지 않는다.

 

그 외 나머지는 전부 기본 설정으로 하고 생성을 마친다. 생성이 끝나면 리스트에서 확인할 수 있다.

 

도쿄에서 EC2 인스턴스 생성

이제 EC2 인스턴스를 생성해보자. Name은 my-tokyo-private-ec2로 설정하고 Amazon Linux 이미지를 사용한다.

 

여기서는 서버에 직접 접근하지는 않을거니까 Key pair 생성도 생략한다.

 

네트워크는 방금 만든 도쿄의 VPC와 private subnet-1을 선택하면 된다.

 

그리고 생성 버튼을 누르면 키페어 없이 생성하는게 맞냐는 안내 팝업이 뜨는데 맞다고 해주고 생성을 진행하자.

 

 

보안 그룹 인바운드 규칙 수정

이제 생성된 인스턴스에 적용된 보안 그룹을 수정해야 한다. 서울에서 들어올 수 있게 서울 대역을 허용해주자.

 

 

VPC Peering connection

이제 도쿄 VPC에 피어링을 걸어보자. VPC > Virtual private cloud > Peering connections에서 우측 상단 'Create peering connection'을 클릭

 

Peering connection settings에서 로컬 VPC는 도쿄니까 도쿄의 VPC를 선택하고 연결할 VPC는 일단 내 계정의 다른 지역을 선택해서 서울을 선택하고 서울의 내가 가지고 있는 특정 VPC ID를 입력해주면 된다. 그리고 생성하자.

 

생성하고 나면 다음처럼 상단에 서울 지역으로 가서 이 요청을 수락해야한다라는 안내 토스트가 나온다.

 

서울의 피어링 연결로 가서 요청 대기중인 녀석을 수락해주자.

 

이제 거의 끝났다. 이제 확인만 해보면 되는데 SSH로 서울의 EC2 인스턴스 내부로 들어가자. 그러나 그 전에, 서울의 라우트 테이블에서 프라이빗 용 라우트 테이블에 도쿄 IP를 추가해줘야한다. 반대로도 마찬가지.

 

 

 

서울에서 도쿄로 Ping 날려보기

이제 모든 준비가 끝났다. 위에서 OpenVPN을 커넥트하면 로컬에서 바로 프라이빗 EC2 인스턴스에 SSH로 접속이 가능하다. 접속한 후 도쿄의 EC2 인스턴스 Private IPv4 Address로 핑 명령어를 입력하자.

ping 192.168.10.134

이처럼 핑을 날려서 잘 받으면 된다. 

 

 

결론 

VPC를 최초 생성해 보는것에 시작해서 AZ별 서브넷을 구축하고 퍼블릭 서브넷과 프라이빗 서브넷을 각각의 가용영역에 만들어서 퍼블릭 서브넷은 인터넷 게이트웨이에 프라이빗 서브넷은 NAT 게이트웨이에 연결하여 외부로 통신할 수 있게 하고 그 정의를 라우트 테이블에 해보았다. 더 나아가서 퍼블릭 서브넷에 EC2 인스턴스(Bastion host)를 만들어서 로컬에서 이 곳으로 접근하고 이 곳에서 프라이빗 서브넷에 있는 EC2에 접근하는것을 해보았고 그 과정에서 필요했던 보안 그룹 설정도 만들어보았다. 더 나아가서 Bastion Host에 접근해서 또 다른 EC2에 접근하는 게 아닌 OpenVPN EC2 인스턴스를 만들어서 이 인스턴스가 프라이빗 EC2에 연결할 수 있게 설정하고 로컬에서 OpenVPN을 이용해서 다이렉트로 프라이빗 서브넷의 EC2 인스턴스에 접속할 수 있게도 해보았다. 더 나아가서 서로 다른 Region에 VPC끼리 Peering을 해서 서울에서 도쿄로 통신하는 것까지. 

이제 EC2 인스턴스를 생성하고 해당 인스턴스에 접근해보자. 참고로 EC2에 대한 설명은 다음 포스팅에 있다. 

 

Part 3. AWS 주요 서비스

AWS에서 제공하는 주요 서비스들을 알아보자. AWS에는 무수히 많은 서비스가 있고 위 그림만 봐도 각 카테고리 별 주요 서비스들이 있다. 차근차근 알아보자. EC2 (Compute) Elastic Compute Cloud의 약자이

cwchoiit.tistory.com

EC2 인스턴스 생성

우선, AWS Console로 들어가서 'EC2'를 검색해보자. 

결과에 'EC2'가 나온다 선택해보자. 선택하면 EC2 메인 화면이 나오는데 좌측 사이드바에 'Instances'를 클릭하자.

그러면 우측 상단 'Launch Instances'가 나온다. 이 버튼을 클릭하자.

 

상단부터 인스턴스의 이름을 입력하면 된다. 원하는 이름을 입력하자.

그 다음은 OS 이미지를 선택하면 된다. 나는 Amazon Linux를 선택했다.

 

인스턴스 타입은 기본으로 설정된 t2.micro를 그대로 사용한다.

 

Key pair는 외부에서 원격으로 접속하기 위해 만들어주자. 우측에 'Create new key pair'를 클릭하자.

 

Key pair name을 입력하고 type은 'RSA' format은 .pem으로 선택 후 'Create'

 

네트워크 세팅은 기본으로 설정된 값 그대로 사용하고 보안 그룹같은 경우 있으면 기존에 있는것을 그대로 사용하던지 새로 만들면 된다.

새로 만들 땐 이건 단순 테스트니까 'Allow SSH traffic from'은 'My IP'로 선택하고 'Allow HTTP traffic from the internet'은 체크하자.

 

Configure Storage는 기본 설정값 그대로 사용하면 된다.

근데, 한가지 확인할 게 있는데 'Advanced'를 클릭해서 EBS 설정이 Delete on termination이 'Yes'인지 확인해야 한다. 이 옵션은 인스턴스가 종료되면 EBS도 같이 삭제되는 옵션이다.

 

이렇게 설정을 하고 우측 'Launch Instance' 클릭하면 인스턴스가 생성된다.

이 인스턴스를 SSH를 이용해서 접속해보고 Nginx를 설치해서 기동시켜보자.

 

SSH로 EC2 인스턴스 접속하기

인스턴스를 생성하면서 .pem키를 생성했었다. 해당 경로에 가서 그 키 파일의 권한을 변경한 다음 키를 이용해서 ssh 접속을 해보자.

chmod 600 yourkeyname.pem

이렇게 파일 권한을 변경한 후 해당 키를 가지고 EC2 인스턴스에 들어가보자.

ssh -i yourkeyname.pem ec2-user@ec2publicipaddress

 

정상적으로 접속된다면 아래처럼 보일것이다.

[ec2-user@ip-XXXX]$

 

안으로 들어왔으니 이제 nginx를 설치해보자.

 

우선 첫번째로, 패키지들을 업데이트 한 후 ngnix를 설치해야 한다.

sudo yum update -y #패키지들을 업데이트
sudo yum install nginx #nginx를 설치

 

nginx를 설치한 후 활성화 시켜준 다음 실행한다.

sudo systemctl enable nginx #nginx 활성화
sudo systemctl start nginx #nginx 실행

 

nginx 실행 상태를 확인한다.

sudo systemctl status nginx

위 사진처럼 Active 상태가 active(running)이면 된다. 이렇게 nginx를 실행해 놓으면 된다. 

위에 EC2 인스턴스를 만들면서 HTTP 연결을 가능하게 했었다. EC2의 퍼블릭 IP로 접속하면 Nginx 화면이 노출되어야 한다.

 

http://ec2-public-ip 접속해보자.

이처럼 화면이 노출되면 성공이다. 

 

정리

EC2 인스턴스를 직접 만들어서 SSH를 이용해 외부에서 원격으로 접속한 후 Nginx를 설치하고 설치한 Nginx가 정상적으로 실행되는지를 EC2 인스턴스의 퍼블릭 IP로 접속하여 확인해보았다. 이제 만든 EC2 인스턴스를 삭제해보자. 

 

 

EC2 인스턴스 삭제하기

삭제하고자 하는 인스턴스를 선택한 후 우측 상단 Instance state 버튼을 클릭하면 'Terminate instance'가 있다.

 

이 버튼을 클릭하면 인스턴스가 종료된다. 이러면 인스턴스는 삭제된 것. 그리고 인스턴스를 Terminate하면 EBS도 삭제되는 옵션을 체크했으니 이 옵션이 정상적으로 동작하는지 좌측 사이드바 Elastic Block Store의 Volumes을 클릭해보자.

위 사진처럼 아무것도 없으면 된다.