[AWS] HTTPS로 서버 배포하기 1편 (session manager 방식으로 private EC2 접근하기)

https://growth-coder.tistory.com/170

[AWS] public subnet에 EC2, private subnet에 RDS 인스턴스 생성하기 (2)

 

이전에 private subnet에 RDS 인스턴스를 두고 public subnet에 EC2 인스턴스에서만 접근할 수 있도록 구성해봤다.

 

<이전 아키텍처>

 

RDS를 private subnet에 둠으로써 어느정도 보안은 강화했지만 EC2 인스턴스가 public subnet에 있기 때문에 여전히 보안상 위험하다.

 

또한 EC2 인스턴스에 직접 탄력적 IP를 할당하여 http 통신을 하였는데 이번에는 인증서를 발급받아서 https 통신을 해 볼 예정이다.

 

<아키텍처>

위와 같이 private subnet에 EC2 인스턴스가 존재한다면 외부와 직접적인 통신이 불가능하다.

 

그렇기 때문에 ALB(Application Load Balancer)를 사용한다.

 

이 ALB를 public subnet에 둔 다음 private subnet의 EC2를 타겟으로 둔다면 외부에서 EC2 서버로 요청을 보내고 응답을 받을 수 있다.

 

기본적으로 load balancer는 트래픽을 분산해주는 역할을 하기 때문에 고가용성으로 구성하는 것이 일반적이지만 목적이 private subnet에 EC2를 두고 https 통신을 구성하는 것이기 때문에 EC2를 단일 인스턴스로 구성하려고 한다.

 

또한 만약 EC2가 외부 인터넷을 이용해야 한다면(외부 api 사용 등등...) NAT gateway를 public subnet에 구성해야한다.

 

단계별로 나눠서 진행할 예정이고 이번 포스팅에서는 private subnet에 EC2 인스턴스를 생성하고 접속해보려고 한다.

 

EC2 인스턴스를 시작하기 전에 private subnet에 존재하는 EC2 인스턴스에 접근하는 방법에 대해서 알아보려고 한다.

 

이전에 public subnet에 존재하는 EC2 인스턴스에 접근할 때는 ssh 방식을 통해 접근을 했었다.

 

그런데 private subnet은 외부와 직접적인 통신이 불가능하기 때문에 ssh를 통해 바로 접속할 수가 없다.

 

먼저 자주 사용되는 방식은 bastion host 방식이다.

 

1. Bastion Host

https://dev.classmethod.jp/articles/access-private-subnet-ec2-via-ec2-bastion-host/

public subnet에 EC2 bastion host를 두고 이를 통해서 접속하는 방식이다.

 

이 방식을 사용하면 ssh 방식으로 접근을 할 수 있으나 EC2 인스턴스가 두 개가 필요하다.

 

프리티어를 사용하는 입장에서는 부담이 될 수가 있다.

 

EC2 인스턴스 두 개를 돌린다면 금세 프리티어 사용 제한을 넘어서기 때문이다.

 

그래서 이 방식을 사용하지 않을 예정이다.

 

이 Bastion Host 대신 선택한 방식이 바로 session manager 방식이다.

 

2. session manager

session manager를 사용한다면 private subnet에 존재하는 EC2 인스턴스에 바로 접근할 수 있다.

 

이번 포스팅에서는 private subnet에 EC2 인스턴스를 두고 session manager 방식을 통해 EC2 인스턴스에 접근해보려고 한다.

 

이번에도 VPC부터 직접 생성해서 구성해보려고 한다.

 

1. VPC 생성

VPC를 생성한다.

방금 만든 VPC에 들어가서 작업 -> VPC 설정 편집에 들어간다.

DNS 확인 활성화와 DNS 호스트 이름 활성화를 선택하고 저장한다.

 

2. private subnet 생성

 

VPC -> 서브넷 -> 서브넷 생성에 들어간다.

 

방금 만든 VPC를 선택하고

이름, 가용 영역, CIDR 블록을 선택하고 서브넷을 생성한다.

3. EC2 인스턴스 생성

먼저 EC2 -> 인스턴스 -> 인스턴스 시작에 들어간다.

 

이름을 지어주고 AMI를 선택해야한다.

 

그런데 주의할 점이 ssm agent가 설치되어있는 AMI를 선택하도록 하자.

 

ssm agent가 설치되어있는 AMI는 아래에서 확인할 수 있다.

https://docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/ami-preinstalled-agent.html

Amazon Machine Images(AMIs), SSM Agent 사전 설치 - AWS Systems Manager

나는 기본으로 설정되어있던 Amazon Linux 2023 AMI를 선택했다.

 

프리티어로 사용가능한 인스턴스 유형을 선택하고 키 페어를 선택하거나 새로 생성한다.

우리가 만든 vpc와 서브넷을 선택하고 public ip 할당 비활성화, 보안 그룹의 경우 인바운드 규칙을 추가하지 않는다.

나머지 설정은 그대로 두고 인스턴스를 시작한다.

 

4. IAM Role 생성

IAM -> 역할 -> 역할 만들기에 들어간다.

 

AWS 서비스, EC2를 선택하고 다음으로 넘어간다.

AmazonEC2RoleforSSM을 선택한다.

역할 이름을 적어주고

나머지는 그대로 둔 상태로 역할을 생성한다.

역할을 생성하고나면 우리가 생성한 EC2 인스턴스로 들어간다.

 

작엄 -> 보안 -> IAM 역할 수정에 들어간다.

방금 생성한 역할을 선택하고 IAM 역할을 업데이트한다.

5. VPC 엔드포인트 생성

VPC 엔드포인트를 생성하기 전에 VPC 엔드포인트의 보안 그룹부터 생성한다.

 

HTTPS 트래픽을 허용하면 된다.

 

VPC -> 보안 그룹 -> 보안 그룹 생성

다시 VPC -> 엔드포인트 -> 엔드포인트 생성을 한다.

 

ssm 서비스를 선택하고 VPC를 선택한다.

서브넷을 선택하고 방금 만든 보안 그룹을 선택한다.

전체 액세스를 선택하고 엔드포인트를 생성한다.

ssm만 생성하였는데 ssmmessages, ec2messages도 같은 방식으로 생성해준다.

엔드포인트 3개 모두 사용 가능 상태가 되었다면 우리가 만든 private EC2에 들어가서 연결에 들어가면 session manager  연결 버튼이 활성화되어있다.

연결이 성공적으로 되었다.

 

정리

1. VPC의 DNS 확인과 DNS 호스트 이름을 활성화.
2. EC2를 생성할 때 ssm agent가 존재하는 AMI 선택.
3. EC2 보안 그룹의 인바운드 규칙에는 아무것도 추가 x
4. AmazonEC2RoleforSSM 역할 생성 후 EC2와 연결.
5. VPC 엔드포인트의 보안 그룹에 HTTPS 인바운드 규칙 추가.
6. ssm, ssmmessages, ec2messages 엔드포인트들을 VPC와 연결하여 생성

 

한번 ping 8.8.8.8 명령어를 입력해보자.

 

이 명령어는 구글 DNS 서버에 패킷을 보내는 명령어이다.

 

만약 인터넷에 연결이 되어있다면 응답이 올 것이다.

 

그런데 지금 상황에서는 응답이 오지 않는다.

 

private subnet에 EC2 인스턴스가 존재하기 때문이다. 이제 다음 포스팅에서는 NAT gateway를 통해 외부 인터넷과 통신을 해보려고 한다.