'aws 인프라 패턴'에 해당되는 글 2건

최근 AWS에 대해서 공부 중이며 내가 공부한 여러가지 디자인 패턴에 대해서 작성할려고 한다.

이번 글에서는 다소 복잡한 웹사이트의 예로 AWS를 사용한 기업 웹사이트 구축 패턴에 대해 공부한걸 작성해 보겠다.

기업 웹사이트 개요 :

1. 공개 웹사이트로 사용자는 거래처, 잠재거 고객, 입사지원자 등이다.
2. 정적 콘텐츠 중심이다. (CSS, HTML, 이미지 파일 등)
3. 서버를 다중화하여 장애에 대비한다.
4. 부하가 높아지면 서버를 추가할 수 있게 구성한다.
5. 장애 서버의 교체, 추가는 수동으로 조작한다.
6. 응답시간과 비용을 고려하여 구성한다.

인프라 핵심 :

1. 웹 서버 다중화 : 이벤트 사이트를 구동시킬 최적의 리전을 선택한다.
2. DB 서버 다중화 : 소규모 웹서버에 맞는 EC2 인스턴스를 설정한다.
3. CDN과 객체 저장소를 사용한 정적 콘텐츠 전송 : 웹 서버로의 접속을 줄여 운용 비용을 절감한다.

CDN(Content Delivery Network, 콘텐츠 전송 네트워크)은 지리적인 제약 없이 전 세계 사용자에게 빠르고 안전하게 컨텐츠를 전송할 수 있는 기술을 의미한다. 단순하게 얘기하자면 이미지 파일같은 용량이 큰 컨텐츠는 요청이 들어올때마다 서버에서 다운로드 받는것보다. 사용자의 위치에서 가까운 서버에서 캐싱된 컨텐츠를 가져와 빠르고 저렴하게 서비스를 제공해주는 것이다. AWS에서는 Cloudfront 서비스를 통해 제공 받을 수 있다.

기업 웹사이트 구성도

이전 패턴(이벤트 사이트)과 똑같이 서버를 구성하는 가장 기본적인 서비스는 가상 서버인 EC2(Amazon Elastic Computer Cloud)와 가상 스토리지 볼륨인 EBS(Amazon Elastic Block Store)로 구성한다.

웹서버는 로드 밸런서를 사용하여 다중으로 구성한다. 로드밸런서 기능을 제공하는 AWS 서비스는 ELB(Elastic Load Balancing)이다.

DB 서버는 RDB의 관리형 서비스인 RDS(Amazon Relational Database Service)로 구성한다. RDS는 이미 세팅이 완료된 RDBMS환경을 제공하는 서비스이며 설정만으로도 다중화가 가능핟.

정적 컨텐츠 전송에 이용하는 CDN 서비스는 위에서 잠깐 얘기한 클라우드프론트(Clouldfront)이고, 객체 저장소 서비스는 S3(Amazon Simple Storage Service)이다. CDN을 사용하면 전세계에 배치된 서버를 통해 웹 접속을 캐시하거나 분배할 수 있고, 또한 응답 속도를 높이거나 웹서버로의 접속을 줄여주어 비용 절감에 도움이 된다. S3 저장소는 객체 단위로 데이터를 다루는 스토리지로서 REST API를 사용하여 데이터의 입출력을 수행한다.

ELB를 이용하여 웹 서버 다중화

다중화를 위해서는 웹 서버를 여러 대를 구축해야한다.

이벤트 사이트에서 EC2 인스턴스를 구성하는 방법과 동일한 방법으로 인스턴스를 작성하고, 웹 서버 환경 구축하고, OS 환경을 셋업하고, 필요한 SW를 설치하는 것을 여러번 반복해도 되지만 이것은 시간이 오래 걸린다.

이를 해결하기 위해 있는것이 AMI(Amazon Machine Images)이다. 완성된 인스턴스의 이미지를 저장하는 방식으로 AMI를 만들고, 이 AMI를 이용하여 동일한 구성의 EC2 인스턴스를 여러개 만들 수 있다.

필요한 수의 웹 서버를 만든 후에는 ELB와 연계한 다중화 구성을 한다. ELB를 웹 트래픽의 입구로 사용하여 트래픽이 복수의 웹 서버에 분산되어 부하를 줄이도록 구성한다. 

ELB에 의한 부하 분산 설정(EC2 - ELB - 인터넷 연결 설정)은 다음과 같이 설정한다 :

우선 인터넷 접속 엔드포인트를 ELB로 지정한다. ELB는 IP 주소가 아닌 CNAME(대체 도메인명)을 지정하여 접속.

ELB의 IP 주소는 고정이 아니라 계속 변하기 때문이다. DNS 서버인 Route53을 이용하여 ELB의 CNAME과 사용할 도메인 이름을 연결한다. 이러한 설정에 의해 사용자는 도메인 이름을 통해 ELB에 접속할 수 있게 된다.

다음은 ELB와 웹 서버의 EC2 인스턴스를 연결시킨다. ELB 작성 페이지에 웹 서버를 선택하는 항목을 찾아서 이미 만들어진 웹 서버를 선택한다. 이것으로 ELB를 활용한 부하 분산 설정이 끝이다.

- ELB 설정 시 유의 사항

ELB 설정할 때 주의해야 할 다섯 가지 

1. ELB용과 웹 서버용으로 각각 다른 보안 그룹을 마련한다.

- ELB는 인터넷 어디에서라도 HTTP/HTTPS 접속을 허용하도록 설정되어 있다. 반면에 웹서버는 ELB로 부터 HTTP 요청만을 받아들이도록 트래픽 소스를 ELB가 속한 보안그룹으로 한정되어야 한다.

2. 세션 유지 기능의 유무 확인

- 최근 웹사이트는 세션 유지 기능을 이용해 복잡한 기능을 지닌 애플리케이션을 제공하는 경우가 있다. 그때 세션 정보를 웹 서버 간에 공유하는 구조를 마련하지 않으면 동일한 클라이언트 접속을 항상 같은 웹 서버에 유지시켜야만 한다. ELB는 ELB 자신이 작성하는 쿠키 저보를 바탕으로 동일한 서버로 접속을 유지시키는 세션 유지 기능을 제공한다. AWS 콘솔에서 설정할 수 있으므로 필요에 따라 사용해야한다.

3. HTTPS 처리

- HTTPS 통신은 클라이언트와 서버 간의 통신을 암호화 한다. ELB는 SSL 터미네이션이라고 하는 SSL 인증서 확인 및 암복호화 처리 기능을 제공한다. ELB 리스너 설정에서 로드밸런스 프로토콜을 HTTPS로 인스턴스의 프로토콜을 HTTP로 하면 자동적으로 적용된다. 웹 서버별로 SSL 인증서를 관리할 필요가 없어질 뿐만 아니라, SSL 복호화 처리에 걸리는 부하가 줄어들어 EC2 비용을 줄일 수 있다.

4. 헬스 체크

- 웹 서버가 정상적으로 동작하는지 감시하는 기능을 헬스 체크라 한다. 기본 설정에서는 간격이 30초, 타임 아웃이 5초, 비정상 상한치가 2회이다. 웹 서버에 장애가 발생하면 40초에서 70초 만에 감지하여 해당 서버를 분리한다. 너무 짧게 설정하면 웹 서버의 부하가 높아져 응담이 저하되는 상태를 고장으로 오판하여 서버가 분리되어 버린다. 반대로 너무 길면 오류가 발생하는 웹 서버에 요청 배분을 계속하게 된다. 기본 설정으로도 충분하지만 성능 시험이나 운영 시 검출 오작동이 발생한다면 수치를 조정하면 된다.

5. 타임아웃 설정

- 응답시간에 따른 타임아웃 설정을 한다. 웹 서버에 분산시킨 후 일정시간 응답이 없으면 ELB는 웹 서버와의 접속을 절단하고, 클라이언트에 HTTP 504를 반환한다. 타임 아웃 시간은 접속 설정의 타임아웃으로 설정하며, 초기 설정 값은 60초이다. DB 처리 등으로 시간이 오래 걸리더라도 결과를 반환하고 싶다면 시간을 길게 설정한다.

RDS를 이용하여 DB 서버 다중화

AWS에서 RDB를 구성하는 방법은 크게 두 가지이다. 

EC2인스턴스에 RDBMS를 설치하는 방법과, 관리형 서비스인 아마존 RDS를 이용하는 방법이다.

전자는 OS와 RDBMS를 자유롭게 선택하고 설정할 수 있는 반면, OS와 DB환경을 사용자가 직접 관리하지 않으면 안 된다. 후자는 패치 적용과 백업이 자동화되어 있기 때문에 운영의 번거로움이 줄어든다.

이용 목적에 맞는 방법을 선택하면 된다.

이번에는 RDS 이용을 전제로 한다. AWS에서 제공하는 RDS 엔징으로는 오라클, SQL Server, MySQL, PostgreSQL, Aurora등 다양한 엔진이 존재한다. 어떤 RDS를 사용해도 문제는 없지만, 예시로 MySQL를 사용한다. MySQL은 웹 애플리케이션과 함꼐 사용되는 경우가 많아 찾아 볼 수 있는 기술 정보가 많다.

DB 서버의 다중화는 'Active-Standby(활성-대기' 구성을 선택했다. DB 서버는 데이터의 일관성을 유지하고자 실행 서버를 시스템 안에서 하나로 구성하는 것이 일반적이다. RDS의 멀티-AZ 기능을 사용하면 활성 DB 서버(마스터)의 데이터를 대기 서버(스탠바이)에 동기화하는 복제 중복 구성을 쉽게 구축할 수 있다.

멀티-AZ 기능을 사용한 RDS 설정 방법은 다음과 같다.

매니지먼트 콘솔의 RDS 설정 화면에서 DB 서브넷 그룹을 작성한다. DB 서브넷은 두 가용 영역(AZ)에 각각 서브넷을 만들고 이것을 그룹화해서 만든다 (위의 그림처럼) . 두 AZ를 사용해 서브넷을 만드는 이유는 하나의 AZ가 예상치 못한 재해로 멈추더라도 또 다른 AZ에 설치된 서브넷에 서버가 계속 동작하도록 하기 위함이다.

다음은 RDS for MySQL의 인스턴스를 작성한다. 이때 멀티-AZ를 이용하는 옵션을 선택하고 방금 만든 DB 서브넷 그룹을 지정한다. 

이것으로 마스터와 스탠바이 2대 구성의 DB 서버(RDS 인스턴스)가 만들어 졌다. 마스터유저가 자동으로 생성되므로 이를 통해서 애플리케이션 사용자를 만들거나 객체, 그리고 데이터를 관리할 수 있다. 마스터와 스탠바이가 복제되어 있기 때문에 마스터에 장애가 발생해도 데이터는 손실되지 않으나, 2대의 RDS 인스턴스가 동시에 작동하기 때문에 2배의 비용이 발생한다.

마스터 DB 서버에 장애가 발생하면 스탠바이가 마스터로 승격되고 기존 마스터 서버가 사용하던 서브넷에 스탠바이 서버가 새롭게 만들어진다. 이러한 일련의 작업은 자동으로 이루어지기 때문에 별도의 작업은 필요 없으나, DB 접속은 장애 복구 이후 자동으로 연결되도록 사전에 설정해주어야 한다.

- RDS 사용 시 유의 사항

RDS 사용시 유의사항에 대해 적어본다.

첫 번째로 적절한 스냅샷을 생성해야 한다. RDS는 자동 백업과 수동 스냅샷 백업 방법을 지원한다. 자동 백업은 간편하지만 데이터 보존 기간에 제한이 있다. 기본 설정값은 1일, 최대로 35일이다. 시스템에 대한 백업을 영구적으로 저정하려면 스냅샷이 더 적합하다.

두 번째는 AWS에 의한 정기정검이다. RDS는 몇 달에 한 번꼴로 마이너 버전업이 자동으로 실행되어, 약 30분간 정지된다. 옵션으로 마이너 버전 자동 업그레이드를 비활성화하면 마이너 버전업은 수행이 되지 않는다. 하지만 취약점 대응 등에 위한 강제 업그레이드가 이루어지는 경우도 있으니 주의하자. 

마지막으로 멀티-AZ를 이용하면 데이터 갱신 처리에 드는 시간이 길어진다. 마스터에 업데이트한 데이터를 스탠바이에 동기화시키는 처리가 끝날 때까지 마스터는 다음의 처리를 실시할 수 없다. 이용 환경이나 처리내용에 따라 다르지만 대체로 20~50% 정도 업데이트 처리 시간이 길어진다.  

정적 콘텐츠를 낮은 비용으로 배포하기

방문자가 많은 시스템에서는 이미지와 동영상, 자바스크립트, HTML, CSS 등의 정적 콘텐츠 제공에 많은 비용이 들게 된다. 대량의 트래픽을 처리하려면 고성능 웹 서버가 여러 대 필요하게 되는데, 이렇게 되면 EC2에서 다운로드 통신량이 늘어나서 비용이 증가된다. 이때 정적 콘텐츠 전달 비용을 줄이려면 클라우드프론트와 S3를 사용하면 된다.

클라우드프론트는 위에서 말한거처럼 AWS에서 제공하는 CDN이다. 사용자가 요청한 콘텐츠가 캐싱되어 있으면 웹 서버와 DB 서버에 접속하지 않으므로 서버의 부하를 낮춰 비용을 절감할 수 있다. 

클라우드프론트뿐만 아니라 정적 콘텐츠를 S3에 두는 방법을 함께 사용하면 더욱 웹 서버의 부하를 줄일 수 있다. S3에 파일을 저정하면 파일 단위로 접속용 URL이 생성된다. 이것을 이용해 정적 콘텐츠 저장소로 사용한다. S3 요금 체계는 EC2 보다 낮게 설정되어 있기 때문에 정적 콘텐츠를 S3에 배치하는 것이 좋다.

자세한 설정 방법은 아래의 블로그를 참조하면 좋다.

https://bigco-growth-diary.tistory.com/6

기업 웹사이트에 적합한 인스턴스 설계

기업 웹사이트에 적합한 인스턴스는 다음과 같은 요구사항이 있다.

1. 안정적인 응답

2. 몇 년 단위로 장기 이용

요구사항 1에 대응하려면 성능이 안정된 EC2 인스턴스와 EBS 볼륨을 선택해야 한다. 

요구사항 2에 대응하려면 장기 이용을 약정하여 할인받을 수 있는 EC2 인스턴스가 적합하다.

성능의 안정성과 관련해서는 스토리지 I/O 대역폭에 주의해야한다. EC2 인스턴스와 EBS 볼륨 사이는 다른 사용자와 공유하는 네트워크로 연결되어 있다. 트래픽이 대역폭의 한계치에 이르게 되면 스토리지에서 데이터를 읽는 데 시간이 걸리고 응답도 불안정해진다. 다양한 네트워크 대역폭이 있지만, 운용 초기에는 성능이 낮은 인스턴스를 설정하고, 부족하면 서능이 높은 인스턴스 타입으로 변경하여 이용하면 좋다.

또한 안정을 중시하는 경우에는 다음의 두 가지 옵션의 사용을 고려해보면 좋다. 첫 번째는 EC2 인스턴스의 옵션인 'EBS 최적 인스턴스'이다. 이 옵션을 사용하면 EC2 인스턴스에서 EBs 볼륨까지 네트워크 대역폭을 보장받을 수 있다. 인스턴스 타입에 따라 이 옵션의 지원 여부가 달라진다. 

또 한 가지 옵션은 '프로비저닝된 IOPS'이다. 프로비저닝된 IOPS를 사용하는 경우, 안정적으로 1만 IOPS이상의 I/O를 보장 받을 수 있다. 

2023년 이후에 생성된 모든 io2볼륨은 프로비저닝된 IOPS를 제공한다. 

https://docs.aws.amazon.com/ko_kr/ebs/latest/userguide/provisioned-iops.html

성능을 안전시키려면 EBS 최적화를 이용하면 되고, 피크 시 성능을 높이려면 EBS 최적화와 프로비저닝된 IOPS를 모두 사용하면 된다.

요구사항 2에 대응하려면 장기 이용에 따른 할인 혜택을 받기 위해 예약 인스턴스(RI) 사용을 검토하면 된다. EC2 인스턴스 과금 체계 중에서 사용한 만큼 비용을 지불하는 온디맨드 인스턴스가 기본적으로 선택이 된다. 예약 인스턴스는 1년 또는 3년의 기간을 정하여 사용을 예약하면 된다. 

https://velog.io/@c17an/%EC%98%88%EC%95%BD-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EC%99%80-%EC%8A%A4%ED%8C%9F-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EB%A1%9C-EC2-%EB%B9%84%EC%9A%A9-%EC%A0%88%EA%B0%90%ED%95%98%EA%B8%B0

예약 인스턴스는 취소할 수 없으므로, 이용률이 낮아지면 온디맨드와 비교하여 오히려 비싸지게 되니. 잘 고려해서 선택해야한다.

최근 AWS에 대해서 공부 중이며 내가 공부한 여러가지 디자인 패턴에 대해서 작성할려고 한다.

이번 글에서는 사용자 수가 많지 않고 짧은 기간만 서비스하는 이벤트 사이트 패턴에 대해서 써 보겠다.

이벤트 사이트는 일반 소비자를 대상으로 일시적으로 운용할 소규모 웹 서버를 설계하는 걸 목표로 한다.

이벤트 사이트(소규모 웹 서버) 개요 :

1. 1개월 한정으로 이용한다.
2. 사이트의 사용자는 개인 사용자로서 인터넷으로 접속한다.
3. 접속자 수는 많지 않아 고사양 서버는 필요 없다.
4. 웹 서버로 LAMP(Linux, Apache, PHP, MySQL) 환경을 사용한다. (다른 환경도 가능하다.)
5. 비용을 우선하며 다중화나 백업은 고려하지 않는다. (일회성)

인프라 핵심 :

1. 리전 선택 : 이벤트 사이트를 구동시킬 최적의 리전을 선택한다.
2. EC2 인스턴스 설정 : 소규모 웹서버에 맞는 EC2 인스턴스를 설정한다.
3. 도메인을 통한 접속 : 고정 IP 주소로 접속한다. (CNAME을 설정해 도메인 이름으로도 가능하게 한다.)
4. 네트워크 구성 : 인터넷 접속을 위한 간단한 네트워크 구성을 설정한다.
5. OS 환경 설정 :  아마존 리눅스에서 LAMP 환경을 설정한다.

이벤트 사이트 구성도

서버를 구성하는 가장 기본적인 서비스는 가상 서버인 EC2(Amazon Elastic Computer Cloud)와 가상 스토리지 볼륨인 EBS(Amazon Elastic Block Store)로 구성한다.

네트워크에 필요한 서비스는 VPC(Virtual Private Cloud)와 같은 기본 서비스에 포함되어 있다. 예시로 VPC의 내부에 가상 라우터를 설치할 수 있고, Route53(Amazon Route 53)을 사용하면 도메인(호스트명)으로 DNS 기능도 제공할 수 있다.

리전 선택 및 네트워크 구성

- 리전에 따른 응답 속도와 비용차이

서비스 구축 시 가장 먼저 해야 하는 것은 바로 서버가 위치할 리전을 선택하는 것이다.

응답 속도는 AWS 데이터 센터와 일반 사용자가 지리적으로 가까울수록 빠르며 멀수록 느려진다.

국내에 거주하는 사용자를 대상으로 하는 이벤트 사이트의 경우 응답 속도를 빠르게 하고 싶다면 서울 리전을 선택하면 된다.

비용은 리전에 따라 다르게 책정된다. 예시로 EC2 타입 중 하나인 t2.micro의 경우

서울 리전의 온디맨드 비용이 시간당 0.0162 달러, 미국 서부 리전은 0.0156 달러로 차이가 나며 데이터 전송 요금도 차이가 난다.

응답 속도보다 비용이 중요하다면 더욱 싼 리전을 찾아보면 된다.

서비스를 시작하고 나면 리전 변경에 손이 많이 가기 때문에 신중해야한다.

- 네트워크 구성 

리전을 정했으면 VPC와 서브넷을 구성하는 가상 네트워크를 작성한다.

VPC는 논리적으로 격리된 사용자 전용 네트워크 구역을 의미한다. 복수의 가용 영역(AZ, Availability Zones)에 걸친 형태로 VPC 하나를 작성할 수 있다.

하지만 복수의 리전에 걸쳐서 작성할 수 없으니 주의한다.

 서브넷은 VPC를 논리적으로 분리한 서브네트워크로 AWS 환경 내의 네트워크 최소 단위이다.

서브넷은 단일 AZ 안에서만 작성된다. 

서브넷을 나누는 방법은 온프레미스 환경과 다른게 거의 없다. 논리적인 네트워크를 설게해서 AWS의 서브넷 구성에 대입시키면 된다. 예를 들어 인터넷으로 HTTP 수신이 가능한 웹 서버와, 웹 서버로부터 데이터베이스 접속만 허가하는 데이터베이스 서버는 필터링 정책이 다르기 때문에 서브넷을 분리해야 한다.

EC2 인스턴스 작성하기

VPC와 서브넷 설정을 완료하고 나서 이벤트 사이트의 웹 서버가 되는 EC2 인스턴스를 작성해야한다.

LAMP로 구성하기로 했으니 EC2 이미지중 Amazon Linux  AMI를 사용한다. 가상화 타입으로는 완전가상화인 HVM과 반가상화인 PV가 있는데, 보통은 HVM을 선택한다. (HVM 성능이 더 좋다)

인스턴스 유형은 서버 규모에 해당하며, CPU, 메모리, 스토리지, 네트워크 성능의 조합을 할 수 있다. 

하지만 메모리만 늘린다든지 세세한 사용자 정의는 할 수 없다.

그러므로 목적에 가장 가까운 인스턴스 유형을 선택해야 하는데, 작은 LAMP 환경이라면 OS에 약 1GB, MySQL 등의 미들웨어에 1GB정도만 있으면 된다.

네트워크 및 셧다운 동작 설정 주의 사항

인스턴스 유형을 정했다면 다음은 EC2 인스턴스 설정을 해야한다.

주요 포인트만 몇가지 적겠다.

네트워크는 VPC를 선택한다. (기본으로 설정된다)

퍼블릭 IP 주소를 자동할당은 비활성화 해준다. 활성화하면 동적 퍼블릭 IP 주소가 부여되면 EC2 인스턴스가 다시 시작할 때마다 자동으로 변경됨으로 IP주소나 DNS를 다시 지정해주어야만 한다. 

EC2 인스턴스를 정지하는 경우의 종료동작 설정도 해줘야한다. 셧다운 동작에는 중지(Stop)와 종료(Terminate)가 있다.

중지를 선택하면, 셧다운 시에 OS가 정지되며 OS 이미지가 보존되고 재시작하면 같은 상태로 시작한다.

종료를 선택하면 OS 정지와 동시에 EC2 인스턴스가 삭제된다. 고급설정에 종료동작을 설정할 수 있으니 확인해 준다.

 보안그룹 설정

EC2 설정의 마지막 단계는 보안 그룹 설정이다.

보안 그룹은 OS레벨에서 네트워크 통신 필터링 룰을 정하는 것으로 허가할 프로토콜을 설정한다.

보안그룹 Source의 초기 설정 값이 Anywhere(0.0.0.0/0) 되어 있는데. 이는 모든 IP 주소로부터의 SSH 접속을 허가한다는 의미이다. SSH의 Source값을 집 또는 회사의 퍼블릭 IP 로 설정한다.

이벤트 사이트의 웹 서버는 사용자로부터 HTTP/HTTPS 접속을 허가할 필요가 있다.

이때는 어떤 IP에서든 접속 할 수 있게 0.0.0.0/0으로 설정한다. 

고정 IP와 호스트명 설정

EC2 인스턴스를 생성했지만, 아직은 인터넷으로 EC2에 접속할 수 없다.

인터넷으로 접속하려면 고정된 퍼블릭 IP주소와 FQDN(호스트명)이 있어야 한다.

고정 퍼블릭 IP 주소를 AWS에서는 EIP(Elastic IP)라고 부른다.

EIP를 포함한 서비스 설정 변경과 추가는 매니지먼트 콘솔에서 한다. EIP 설정은 콘솔을 통해 EC2 서비스로 들어가 '네트워크 및 보안 > 탄력적 IP > 탄력적 IP 주소 할당' 을 클릭하여 설정한다.

자세한건 아래의 블로그를 참조하면 되겠다.

https://any-ting.tistory.com/71

고정 IP를 할당 받았다면 도메인을 설정할 차례이다.

AWS는 Route53이라는 DNS 서비스를 제공한다. 

도메인 취득 방법은 아래의 블로그를 참조하면 된다.

https://any-ting.tistory.com/84

이후 Route53과 EC2 연결은 아래의 블로그 글을 참고하면 된다.

https://dogfoottech.tistory.com/257

VPC 설정으로 인터넷 접속 설정

인터넷에 접속하려면 한가지 더 설정을 해야한다. AWS에서는 VPC 이용이 필수이다.

VPC는 AWS 데이터 센터 내부에 마련된 가상의 폐쇄 네트워크이며 외부와 통신할 수 있도록 설정해야 한다.

이벤트 사이트는 기본 설정에서 두 군데만 수정하면 된다.

첫 번째는 VPC와 DNS 관련 설정이다. VPC 설정 화면에서 DNS 관련 설정을 켜준다.

두 번쨰는 라우팅 설정이다. 라우팅 테이블에 인터넷 게이트웨이가 설정되어 있지 않으면 인터넷 접속이 불가능하다. VPC 설정화면에서 라우팅 테이블에서 0.0.0.0/0과 igw로 시작하는 인터넷 게이트가 없다면 생성해준다.

이 블로그 글을 보면 도움이 될 것이다.

https://velog.io/@chchaeun/AWS-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B5%AC%EC%B6%95-2-VPC-%EA%B5%AC%EC%B6%95%EC%84%9C%EB%B8%8C%EB%84%B7-%EB%9D%BC%EC%9A%B0%ED%8C%85-%ED%85%8C%EC%9D%B4%EB%B8%94-%EC%9D%B8%ED%84%B0%EB%84%B7-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4

OS 환경 설정

이 블로그 글을 참고하면 될거 같다.

https://strong-ming.tistory.com/3

마지막으로 이벤트 사이트의 사용기간이 끝났으면

EC2 인스턴스를 종료하여 삭제처리 해주어야 추가 비용이 청구되지 않는다.

EIP는 EC2와 연결되어 있을 때만 과금이 된다.

Route 53dms 존 단위로 월정액이 과금되니 사용하지 않는다면 삭제할 필요가 있다.

VPC는 유지 자체는 비용이 들지 않으니 제거할 필요 없다.