AWS Free Tier(프리티어)를 활용해 AWS 배포하기 - 2. EC2

이전 포스트에서 VPC를 생성했었습니다.

 

AWS Free Tier(프리티어)를 활용해 AWS 배포하기 - 1. VPC

 

 

 

두 번째 과정을 생성된 VPC의 Public Subnet에 EC2를 위치시키고, 인터넷에서 접속을 해보도록 하겠습니다.

 

EC2에 대한 상세 내용은 다른 블로그의 좋은 자료들이 많으니 지금 글에서는 EC2 설명을 제외하고 하겠습니다.

 

이번 포스트에서는 아래와 같이 진행해 보도록 하겠습니다.

 

1. EC2 생성 및 SSH 접속

2. 인터넷에서 EC2의 Public IP로 접속해 보기

 

---

 

1. EC2 생성 및 SSH 접속

 

AWS에서 EC2 생성을 눌러줍시다.

 

저는 아마존 리눅스(Amazon Linux 2023 AMI)를 사용할 예정입니다. Amazon Linux 2023 AMI는 mysql이 설치가 바로 안 되는 문제가 있지만, 해당 과정은 다음 RDS에서 하나하나 해보도록 하겠습니다. 

 

인스턴스 유형은 t2.micro

 

 

키페어도 하나 생성해서 선택해 줍시다.

 

 

1. 네트워크는 기본적으로 default VPC와 연결되어 있기 때문에, 편집을 눌러 이전에 생성한 VPC를 선택해 줍시다.(jutest03-vpc)

2. 현재 생성되는 jutest03-ec2-webserver는 이후에 SpringBoot JAR 파일이 실행될 예정이고, 해당 어플리케이션에 여러 사용자들이 접속해야 하기 때문에, 인터넷 게이트웨이가 존재하는 public subnet에 연결해 주자.

3. public IP도 인터넷과의 연결을 위해 필요하기 때문에 할당해 주고,

4. 보안 그룹은 jutest03-vpc가 생성될 때 default 보안 그룹이 생성되었기 때문에 일단 이전에 생성되었던 보안 그룹을 선택합니다.

5. 고급 네트워크 구성은 PASS!!

 

 

스토리지 구성은 EBS를 설정하는 것입니다. EBS(Elastic Block Store)는 프리티어를 이용할 때 최대 30GB까지 무료로 지원을 해줍니다. 그래서 30GB로 설정을 합시다.

 

 

EBS(Elastic Block Store)는 AWS에서 제공하는 블록 스토리지 서비스입니다. EC2 인스턴스에 연결해 사용할 수 있으며, 다음과 같은 특징이 있습니다.

주요 특징:
    고가용성: 데이터는 여러 가용 영역(AZ)에 자동으로 복제되어 높은 내구성을 보장합니다.
    유연성: 필요에 따라 스토리지 용량을 동적으로 확장할 수 있습니다.
    유형: 성능에 따라 SSD 기반(일반 목적, 고성능 IOPS)과 HDD 기반(처리량 최적화, 저비용 아카이브) 스토리지 중 선택 가능
    백업: EBS 스냅샷을 통해 데이터를 손쉽게 백업하고 복원할 수 있습니다.
    용도: 데이터베이스 및 파일 시스템과 같은 영구 저장소로 사용됩니다.

EBS는 EC2 인스턴스가 종료되어도 데이터를 보존할 수 있어 클라우드 인프라에서 중요한 역할을 합니다.

 

다른 작업은 건드리지 않고 인스턴스 시작을 눌러줍시다.

 

 

인스턴스가 생성되고 있습니다. 상태 검사가 2/2로 완료되면 접속이 가능해집니다!! 새로고침을 눌러보면서 기다려봅시다 ㅎㅎ

기다리는 동안 제가 생성한 인스턴스가 제대로 생성됐는지 확인해 봅시다.

 

1. 인스턴스 유형: t2.micro

2. 가용 영역: ap-northeast-2a

3. Public IPv4 주소 할당 여부: true

4. 보안 그룹(sg: Security Group) 이름: default(jutest03-vpc의 default sg)

5. 키 이름: jutest03-key

 

 

이제 검사를 통과했으니 상단의 연결을 눌러 인스턴스에 연결해 봅시다.

 

하지만 오류가 발생합니다...ㅜㅜ

 

 

 

먼저 지금까지의 과정을 되돌아봅시다.

 

EC2 인스턴스를 생성하여 VPC의 Public Subnet에 위치시켰습니다.

 

 

제가 User일 때 EC2에 접속하려면 몇 가지 요소를 고려해야 합니다. 

1. EC2 상태 확인

2. 퍼블릭 라우팅 테이블에 인터넷 게이트웨이로 트래픽 전달이 가능하도록 0.0.0.0/0 경로가 추가되어 있는지 확인

3. 보안 그룹 확인

 

1번과 2번은 이미 완료된 것을 확인할 수 있었고, 그럼 남은 것은 "3. 보안 그룹 확인"입니다.

 

저희가 설정한 보안 그룹은 jutest03-vpc의 "default" Security Group(SG)입니다.(아래 사진의 Name은 원래 없지만 제가 임의로 작성해 준 것입니다.) VPC ID를 통해 이전 포스트에서 만들었던 default SG를 찾아봅시다.

 

 

보안 그룹(sg: Security Group)

보안 그룹은 AWS의 네트워크 트래픽을 제어하는 데 사용되며 인바운드 규칙(Inbound Rules) / 아웃바운드 규칙(Outbound Rules)이 존재합니다.

 

1. 인바운드 규칙 (Inbound Rules):

• EC2 인스턴스로 들어오는 트래픽을 제어합니다.
• 예: SSH(22번 포트)를 허용해 외부에서 EC2에 접근하도록 설정하거나, 특정 IP만 허용하여 보안을 강화할 수 있습니다.

 

2. 아웃바운드 규칙 (Outbound Rules):

• EC2 인스턴스에서 나가는 트래픽을 제어합니다.
• 기본적으로 AWS에서는 모든 아웃바운드 트래픽이 허용되지만, 필요에 따라 제한할 수 있습니다.

 

jutest03-vpc-sg의 인바운드 규칙에는 아래와 같이 설정되어 있습니다.

 

유형: 모든 트래픽

프로토콜: 전체

포트 범위: 전체

소스: sg-028762a2422e2a9f7 / default

 

 

인바운드 규칙에 현재 sg 자기 자신이 소스로 등록되어 있습니다.

 

AWS에서 VPC를 생성할 때 기본적으로 생성되는 **보안 그룹(Security Group)**에 자기 자신을 소스로 등록하는 이유는 내부 자원 간 통신을 허용하기 위해서입니다.

 

예를 들어, 같은 보안 그룹에 속한 EC2 인스턴스들이 서로 통신할 수 있도록 설정합니다. 이는 분산 시스템에서 같은 애플리케이션이나 데이터베이스 서버 간에 트래픽을 허용하기 위한 기본 설정입니다. 이렇게 설정되면, 같은 보안 그룹 내에서의 통신은 허용되고, 외부에서는 차단됩니다.

 

이러한 이유 때문에 현재 외부 트래픽은 모두 차단되어 있고, 내부에서만 자원 간 통신이 허용되어 있습니다.

 

22번 포트를 보안 그룹에서 설정해 줘야 하므로 인바운드 규칙을 편집하여 현재 제가 사용하고 있는 IP를 SSH 22 포트로 등록해 주도록 하겠습니다.

 

 

 

그래도 동일하게 접속이 안 되는 문제가 발생했습니다.

 

일단 먼저 터미널로 접속을 해보도록 하겠습니다. 아까 만들었던 키페어를 이용해 접속해 봅시다.

 

 

 

chmod 400 "jutest03-key.pem" 명령어를 통해 jutest03-key.pem 파일에 소유자(owner)에게 읽기(Read) 권한을 추가해 줍니다. 

그리고 ssh 연결 명령어를 통해 EC2에 접속합니다.

 

 

접속이 잘 이루어진 것을 확인할 수 있습니다!!

 

 

근데 왜 AWS에서는 접속을 하지 못했는지에 대해서 이제 생각해 봐야 합니다.

 

 

왜 AWS에서 접속을 바로 못했을까?

 

내 로컬 컴퓨터에서 EC2에 접속하는 것은 잘 이루어졌습니다. 보안 그룹에 내 IP, SSH 22번 포트를 허용해 주었기 때문입니다. 

다만, 해당 작업은 내 로컬 컴퓨터의 IP를 보안 그룹 인바운드 규칙에 등록했기 때문입니다. 

 

아래 사진을 자세히 보면, 13.209.1.56/29 리전의 포트 22를 등록해 주는 것이 좋다고 이야기하고 있습니다. 

 

 

해당 IP에 대해서 알아보니

13.209.1.56/29는 AWS EC2 Instance Connect 서비스에서 사용하는 IP 주소 범위입니다. 이 IP 범위는 AWS의 EC2 Instance Connect가 SSH로 EC2 인스턴스에 접속할 때 사용하는 서버의 IP 범위를 나타냅니다.

 

이를 보안 그룹에 추가하지 않으면, EC2 Instance Connect를 통해 AWS 콘솔에서 인스턴스에 연결할 수 없습니다. 따라서, 보안 그룹의 인바운드 규칙에 해당 IP 범위(13.209.1.56/29)를 추가하여 포트 22에서 허용해 주면 문제가 해결될 것입니다.

 

다시 보안 그룹의 인바운드 규칙 편집을 통해 새로 등록해 주고 나면...

 

 

 

잘 접속이 되는걸 확인할 수 있습니다!!!

 

AWS EC2 Instance Connect 서비스는 AWS 콘솔에서 SSH 접속을 제공하는 기능으로, EC2 인스턴스에 접근할 때 특정 IP 주소 범위를 사용해 통신합니다. VPC는 격리된 네트워크 공간이기 때문에, 외부 트래픽이 모두 차단되어 있어서 AWS EC2 Instance Connect 서비스에서도 VPC 보안 그룹의 인바운드 규칙에 필터링되어 접속하지 못했던 것입니다. 

 

휴 해결 완료🥲

 

 

 

2. 인터넷에서 EC2의 Public IP로 접속해 보기

 

이제 EC2의 Public IP를 이용해서 인터넷 브라우저에서 EC2에 접속을 시도해 보도록 하겠습니다.

 

하지만 조금 전에 AWS EC2 Instance Connect 서비스의 IP도 보안 그룹 인바운드 규칙에 추가해 줬어야 접속이 가능했으니, 아마 인터넷 브라우저에서 EC2 Public IP로 접속을 시도했을 때 접속이 불가능할 것이라는 것을 예상할 수 있습니다.

 

일단 먼저 시도해 봅시다.

 

 

 

제 EC2의 퍼블릭 IPv4 주소는 "43.203.243.223"입니다.

 

 

당연하게도 접속이 되지 않습니다. ㅎㅎ 

 

인터넷 브라우저에서 EC2 public IP로 접속하는 것이 안 되는 이유는 http 프로토콜을 사용하여 80 포트로 접근하는 것이기 때문입니다. SG에 HTTP 80이 등록되어 있지 않기 때문에 접속이 안될 테니 보안 그룹에 허용을 시켜주고 오도록 하겠습니다.

 

 

이제 다시 접속해 보면..!!

 

 

왜 페이지가 안 나올까.. 하고 생각했더니 Nginx와 같은 웹서버를 설치하지 않았기 때문입니다!!

 

왜 웹서버가 필요한가 하면

웹서버는 클라이언트(사용자)로부터 오는 HTTP/HTTPS 요청을 처리하고, 웹 페이지를 제공하는 역할을 합니다. EC2 인스턴스는 기본적으로 운영체제만 제공되기 때문에, 웹 서버(Apache, Nginx 등)가 설치되어 있어야만 인터넷을 통해 들어오는 요청을 처리하고, 해당 요청에 대한 응답(HTML 페이지, 애플리케이션 등)을 클라이언트에게 보낼 수 있습니다.

 

따라서, 웹 서버가 없으면 EC2 인스턴스는 HTTP 요청을 처리할 수 없고, 결과적으로 브라우저에서 웹 페이지가 표시되지 않습니다.

 

이제 EC2에 웹서버인 Nginx를 설치하고 실행시켜 봅시다.

 

EC2에 접속해서 명령어를 실행해 봅시다

 

sudo yum install nginx
sudo systemctl start nginx
sudo systemctl status nginx

 

 

Active: activate (running)이 나오면 정상적으로 실행되고 있는 것이고

이제 웹 브라우저에서 다시 EC2의 퍼블릭 IP로 접속해 봅시다.

 

 

정상적으로 동작했습니다!!!

 

현재 VPC에 접속 가능한 IP를 "내 IP"만 허용해 주었기 때문에 다른 사람의 컴퓨터로는 접속이 불가능할 것입니다.

모두가 접속을 가능하게 하기 위해선 보안 그룹의 인바운드 규칙에 HTTP 80 포트 모든 트래픽 0.0.0.0/0을 허용해 주면 됩니다!!

 

이상 EC2 생성 끝!!

 

여기까지 완성~~