리전이 뭔지는 말로 설명할 수 있어야 한다.

AWS는 전 세계적으로 다양한 Region을 보유하고 있다. 그렇다고 모든 지역에서 다 가지고 있는 건 아니다.

나중에 여러 컴퓨터를 빌리게 될 것이다. 서버 종류를 다양하게 가질 수도 있다. 기능별로 서버를 나눌 수도 있고, 개발용 서버, 배포용 서버로 나눌 수도 있다.

일반적으로 인스턴스 이름은, EC2 인스턴스들끼리 각각 분리해서 어떤 건지 알 수 있게끔 식별할 수 있게 적으면 된다.

인스타그램 백엔드 서버를 개발한다고 하면 instagram-server 이 정도로 많이 짓는다.

EC2 컴퓨터에 아무나 접근하면 안 된다. 내가 컴퓨터를 빌렸는데 모르는 사용자가 접근하면 안 된다. EC2 컴퓨터에 접근할 때 사용하는 비밀번호라고 생각하면 된다.

키 페어가 유출된다면 다른 사람들도 내가 빌린 EC2에 접근할 수 있으니 잃어버리면 안 된다. 다만 우리는 이 키 페어를 쓰진 않을 것이고 다른 방법을 쓸 것이다.

이걸 새로 설정한 이유는 우리는 80번 포트로 들어오는 HTTP 요청에 대해선 EC2로 들어오게 만들 건데 왜냐하면 우린 백엔드 서버를 만들 거고 백엔드 서버를 80번 포트에 띄울 예정이기 때문이다. 그 서버에 요청이 들어와야 응답을 할 수 있으니깐 80번 포트는 인바운드 규칙에서 허용할 수 있게 열어 둔 거다.

gp2보다 gp3가 최근 것이고 좀 더 좋다. 그렇다고 비용이 더 나오진 않는다.

인스턴스는 이전에도 말했지만 EC2에서 빌려 온 컴퓨터 1대다.

'EC2 인스턴스 연결' 방식은 AWS 홈페이지 자체에서 컴퓨터에 원격 접속하는 방식이다.

생성한 EC2 인스턴스에 들어온 거다.

이게 우리가 선택한 우분투라는 OS 기반으로 깔려 있는 컴퓨터다. 이 컴퓨터에 원격 접속한 상태이다.

EC2 접속을 이렇게 하면 된다.

여기서도 리눅스 기본 명령어인 ls나 pwd, cd .. 등을 사용할 수 있다.

bin boot dev... 등등의 폴더들이나 파일들은 우분투 컴퓨터 살 때 세팅되어 있는 기본 파일들이다. 윈도우를 깔아도 기본적으로 깔려 있는 파일들이 있다. 그런 느낌이다.

왜 AWS는 처음부터 고정된 아이피를 발급하지 않았을까? 왜 굳이 우리가 탄력적 아이피를 설정하고 연결하는 작업을 거치게 만든 걸까?

아이피 개수가 전 세계적으로 부족해지고 있다. 그래서 안 쓰고 있는 인스턴스면 자동으로 반납해서 일단 다른 사람 주는 식으로 양보한다.

즉, 아이피 개수가 모자라다는 환경 때문에 이런 제도를 도입했다.

탄력적 IP 할당한 후에, 탄력적 IP 연결을 하자

./gradlew clean build: 기존 빌드된 파일을 삭제하고 새롭게 JAR로 빌드

clean을 빼면 그냥 빌드만 한다.

자동 갱신을 하면 해당 기간이 지나면 자동으로 결제가 된다. 체크 안 하면 기간이 지났을 때 삭제되는 듯

주로 도메인을 구성할 때 아래와 같이 많이 구성한다.

웹 사이트 주소: https://jscode-edu.co.kr

백엔드 API 서버 주소: https://api.jscode-edu.co.kr

도메인을 따로 2개 구매해야 할까? jscode-edu.co.kr 이 하나의 도메인만 구매하면 앞에 어떤 값을 붙일지는 자유롭게 선택해서 설정할 수 있다.

ELB도 하나의 컴퓨터다.

EC2에 대한 보안 그룹과 ELB에 대한 보안 그룹은 별개다.

로드 밸런서 주소를 통해 서버에 접속할 수 있다.

로드 밸런서는 아래가 주소다. IP가 없다.

instgram-server-elb-1847379545.ap-northeast-2.elb.amazonaws.com

이 도메인 주소를 가지고 접속할 수 있다. ELB의 주소이다. 사용자가 ELB의 주소로 요청을 보내면 트래픽을 EC2 인스턴스로 전달해서 응답 값을 다시 ELB가 받아서 사용자에게 전달한다.

접속하면 EC2 인스턴스에 떴었던
.env 테스트 : my_database
가 보인다.

http://instgram-server-elb-1847379545.ap-northeast-2.elb.amazonaws.com/health

여기에 들어가면 Success Heatlth Check가 보인다.

ChatGPT 답변)

구매한 도메인에 대한 호스팅 영역을 삭제한 후, 만약 이 도메인에 대한 호스팅 영역을 다시 수동으로 만드려고 한다면,

일단 호스팅 영역을 만든 후, 도메인 등록 정보의 NS를 새 Hosted Zone의 NS로 변경해야 한다.
호스팅 영역에서 수정하는 게 아니라 등록된 도메인에서 수정하면 된다.

현업에서는 인증서를 요청할 때 어떤 식으로 하는가?

api.jscode-test.net, temp.jscode-test.net, mail.jscode-test.net 등등 많다면, 각 도메인마다 인증서를 따로 발급해야 하는가?

https://inf.run/J7pq5

이번엔 EC2에 Nginx와 Certbot을 설정해서 HTTPS에 대한 접근을 가능하게 만들 거기 때문에, HTTP뿐만 아니라 HTTPS에 대해서도 EC2 보안 그룹을 추가한다.

레코드 등록 후엔 api.jscode-test.net:3000으로 접속해 보자

도메인 주소는 아이피만 가리키고 있기 때문에 포트 번호를 따로 입력해 줘야 한다. 입력을 안 하면 기본 값인 80번 포트로 통신한다. 하지만 우리는 80번 포트에 서버를 띄우지 않았다.

IP로 접속해도 이렇게 뜨지만

도메인으로 접속해도 뜨는 듯

Certbot의 역할은 HTTPS 인증서 발급이다.

지금은 HTTPS가 80번 포트에 적용됐다. 80번 포트 nginx가 잘 뜬다. HTTPS가 적용됐다.

그런데 우리가 실질적으로 적용시켜야 하는 것은 3000번 포트에 띄어 놓은 백엔드 서버에 HTTPS가 적용돼야 한다.

지금은 api.jscode-test.net:3000/에 들어가면 HTTPS가 적용이 안 돼 있다. 이걸 해결하기 위해 우리는 값을 조금 수정해 줘야 한다.

이 도메인으로 요청이 들어오면 3000번 포트로 이어서 연결시켜 주겠다는 리버스 프록시를 설정한 거다.

사용자로부터 EC2에서 요청을 받아서, EC2 내부의 백엔드 서버가 RDS에 요청을 보낼 수 있게 인프라를 구성할 것이다. EC2 앞에 ELB를 둬도 된다. 이렇게 현업에서 많이 사용한다.

RDS도 하나의 컴퓨터 서비스 위에서 데이터베이스를 실행시키는 거다 보니, 보안 그룹을 세팅해야 한다.

보안 그룹은 EC2 안으로 들어가서 보안 그룹을 클릭하고 만들면 된다.

아웃바운드 규칙은 그대로 두면 된다.

보안을 올리고 싶다면, 인바운드 규칙에서 접속 가능한 아이피를 제한할 수 있지만 지금은 그냥 모든 곳에서 가능하도록 하겠다.

MySQL에도 여러 가지 설정값들을 가지고 있다. RDS를 사용한다면 이런 MySQL의 설정값들을 파라미터 그룹을 통해 세팅할 수 있다.

time_zone은 데이터베이스 자체에서 데이터베이스 시간을 어떻게 표시할 건지에 대한 설정값이다. 이걸 설정 안 한다면 날짜에 대한 데이터 값을 DB에 넣으면 날짜가 우리나라 시간이 아니라 다른 나라 시간으로 찍힌다.

time_zone 바뀐 설정은 RDS 데이터베이스를 재부팅해야만 정상적으로 적용된다.

이 강의에선 컴퓨터에 있는 Express 서버에 RDS를 연결했다.

EC2에 배포는 어떻게 할까? 이거 그 자체로 배포하면 EC2에 있는 컴퓨터가 RDS랑 잘 연결해서 실제 배포된 서버에서도 RDS랑 연결을 잘 해서 이 서버를 운영할 수 있다.

이미지 조회 API일 수도 있고, 이런 거일 수도 있다. 인스타그램 게시글을 보면 이미지가 포함되어 있다. 게시글 조회를 할 때에도 DB에서 그 데이터(URL인 듯)를 불러온다.

모든 퍼블릭 액세스 차단을 해제해야 한다. 우리는 다른 사람들이 이미지를 조회, 다운로드할 수 있게 만들 것이기 때문이다.

퍼블릭 액세스를 허용했더라도 구체적으로 어떤 것들에 대해서 내가 허용할 건지를 정책으로 명시해야 한다.

ChatGPT 답변)

Q: AWS S3 버킷에서 퍼블릭 액세스를 모두 차단하면, 정책을 만들 필요가 없는가?

A: AWS S3에서 퍼블릭 액세스 차단 설정(Block Public Access)을 켜면, 정책을 '만들 수 없는' 것은 아니지만, 퍼블릭 액세스를 허용하는 정책이 적용되지 않게 됩니다. 즉, 정책은 여전히 작성할 수 있지만, 퍼블릭 액세스 차단이 우선 적용되어 외부에서 접근할 수 없게 됩니다.

"Principal": "*"
이건 모든 사람에게 이 권한을 허용한다는 것이다.

이전 강의에서 세팅한 것은 모든 사용자들이 파일을 다운로드하는 것에 대해서만 허용한 것이다.

하지만 파일을 업로드하는 것에 대해선 허용하지 않았다. 왜냐하면 모든 사용자들이 파일을 업로드하면 안 되기 때문이다.

업로드는 백엔드 서버만 파일을 업로드할 수 있게 권한을 부여하려고 한다.

이 권한을 부여하기 위해선 IAM이라는 곳에서 권한을 부여받아야 한다.

IAM은 S3에 대한 액세스뿐 아니라 여러 가지 액세스를 총괄해서 담당하는 서비스다.

직접 정책 연결은 AWS 자체에서 권한에 대한 걸 미리 여러 개 만들어서 가져다 쓰도록 한 거다.

AmazonS3FullAccess는 S3에 접근할 수 있는 모든 기능에 대한 권한을 얻도록 하는 거다.

액세스 키를 백엔드 서버가 써야 한다. 그래서 액세스 키는 AWS 외부에서 실행되는 애플리케이션, 즉 Express 서버나 Spring Boot 서버다.

AWS 외부에서 실행되는 애플리케이션

vs

AWS 컴퓨팅 서비스에서 실행되는 애플리케이션

https://inf.run/xPBsX

액세스 키란? S3에 접근하려면 아무나 접근하면 안 된다. 인증된 사용자만 접근해야 한다. 액세스 키와 비밀 액세스 키로 접근하면 된다.

백엔드 서버에 이 값을 넣을 것이다. S3에 접근할 수 있는 사용자라는 걸 증명하는 거다.

IAM에서 사용자를 만들었다는 건 출입증을 만든 거다.

ChatGPT)

Q: S3 버킷에 정책을 추가하지 않고도, IAM 사용자에서 AmazonS3FullAccess 권한을 부여하면 접근 가능한가?

A: S3 버킷에 별도의 정책을 추가하지 않아도, IAM 사용자에게 AmazonS3FullAccess 권한을 부여하면 그 사용자는 모든 버킷에 접근할 수 있음.

단, '버킷 정책에서 명시적으로 Deny'하거나, '퍼블릭 액세스 차단'이 적용된 경우엔 예외

ChatGpt 답변)

S3 정적 웹사이트 엔드포인트(http://bucket.s3-website-...)는 HTTPS를 지원하지 않지만, S3 REST API 엔드포인트(https://bucket.s3.amazonaws.com)는 기본적으로 HTTPS를 지원한다.

퍼블릭 액세스 차단을 풀어 줘야 한다.

이 페이지에 대한 정보를 다운로드하는 사용자들은 모두이다. 즉, 모두 이 페이지에 접속할 수 있어야 하니 퍼블릭 액세스 가능하게 만들 것이다.

사용자가 알아야 하는 주소는 S3 주소가 아니라 CloudFront의 주소다. 그 CloudFront 주소를 통해 접근해야 하는데, 그 주소가 아래와 같은 주소다.

CloudFront는 HTTPS를 적용하려면 인증서를 서울이 아니라 미국 동부(버지니아 북부)에서 발급받아야 한다.