1. AWS란?
AWS(Amazon Web Service)는 클라우드 컴퓨팅 서비스를 제공하는 프로바이더 중 하나로서, 현재 전 세계에서 가장 많이 사용되고 있는 클라우드 컴퓨팅 서비스입니다. AWS는 단순 컴퓨팅 자원을 제공해주는 것 뿐만 아니라 이를 편리하게 관리할 수 있는 서비스, 서버리스 서비스 등 수많은 서비스를 확장성, 안정성, 높은 보안수준과 함께 제공해줍니다.
2. AWS S3
AWS의 S3서비스는 Simple Storage Service의 약자입니다. Storage라는 표현 그대로 특정한 파일을 저장하고 인터넷상으로 접근할 수 있게 해주는 서비스입니다. 보통 서비스에 필요한 이미지나 파일등을 저장해두는 용도로 사용하지만 정적인 파일들을 안정적으로 제공할 수 있다는 점을 이용해서 정적 웹사이트(파일의 내용이 변하지 않는) 호스팅에도 사용할 수 있습니다.
Create React App을 이용해서 만든 리액트 프로젝트의 경우 build 명령어를 실행하면 정적인 build 파일들이 생성되고 이를 브라우저에서 접근해서 실행하면 Client Side Rendering을 통해서 동작하는 특징을 이용해서 S3서비스를 통해서 배포를 할 수 있습니다.
👉 S3서비스를 통해서 배포 하는 방법
// cra 설치
npx create-react-app aws-deploy-cicd
npm run build
npx serve -s build // build한 파일 확인
1. aws 콘솔홈에 접속
2. 모든 서비스에서 스토리지의 S3에 접속
3. 버킷 만들기 접속
4. 버킷 만들기 구성
버킷의 "퍼블릭 액세스를 차단한다"는 것은 AWS S3 버킷을 외부의 공개적으로 액세스할 수 없도록 설정한다는 것을 의미합니다. 즉, S3 버킷의 내용을 누구나 인터넷을 통해 접근하거나 다운로드할 수 없게 만드는 것입니다. 이것은 보안과 개인 정보 보호 측면에서 중요한 조치 중 하나입니다. 하지만 여기서 우리는 허용을 해줍니다 왜냐하면 우리의 서비스를 모두가 접근 가능하게 해주기 위해서 퍼블릭 액세스 차단을 풀어줍니다.
5. build안에 있는 파일을 추가
build안에 있는 파일을 추가후 업로드를 해줍니다.
하지만 지금 상태로 링크를 눌러도 거부가 됨
6. 정적 웹 사이트 호스팅 활성화
정적 웹 사이트 호스팅 활성화 후 인덱스 문서에 index.html 입력
하지만 아직 여기서 링크를 눌러도 403에러(권한이 없음)가 뜹니다.
📚 401에러와 403에러의 차이 ⬇
401 에러와 403 에러는 웹 애플리케이션에서 사용자 인증 및 권한 부여와 관련된 HTTP 상태 코드입니다. 그러나 이 두 가지 에러는 서로 다른 상황을 나타냅니다:
- 401 Unauthorized (미승인):
- 이 상태 코드는 클라이언트가 요청한 리소스에 대한 인증(로그인)이 필요하다는 것을 나타냅니다.
- 클라이언트가 요청한 리소스에 액세스하기 위해서는 유효한 사용자 자격 증명 (예: 사용자 이름 및 암호 또는 토큰)을 제공해야 합니다.
- 일반적으로 웹 애플리케이션이 로그인이 필요한 페이지 또는 보호된 API 엔드포인트에 액세스하려고 할 때 발생합니다.
- 403 Forbidden (금지됨):
- 이 상태 코드는 클라이언트가 요청한 리소스에 대한 액세스 권한이 없다는 것을 나타냅니다.
- 클라이언트의 인증 자격 증명이 유효하더라도 요청한 리소스에 대한 권한이 없거나, 서버 측에서 액세스를 거부하는 다른 이유로 인해 발생할 수 있습니다.
- 예를 들어, 서버는 특정 사용자나 그룹에 대한 권한을 부여하지 않은 경우에 403 에러가 발생할 수 있습니다.
간단히 말해서, 401 에러는 인증 자격 증명을 제공해야 하지만 유효한 자격 증명을 제공하지 않았을 때 발생하며, 403 에러는 인증은 되었지만 액세스가 거부되었을 때 발생합니다. 이 두 가지 상태 코드는 웹 애플리케이션에서 보안 및 권한 부여를 관리하는 데 중요한 역할을 합니다.
7. 버킷에 저장된 객체에 대한 액세스 권한 설정
📚 CRA 배포용 S3 Bucket Policy
{ //정책 문서의 버전을 지정
"Version": "2012-10-17",
// 권한 부여 규칙을 정의하는 섹션입니다. 여기에서는 하나의 규칙만 정의
"Statement": [
{
//이 규칙의 식별자
"Sid": "PublicReadGetObject",
// 효과를 정의. ➡️ "Allow"로 설정되어 있으므로 해당 규칙을 적용하면 액세스가 허용
"Effect": "Allow",
// 액세스를 허용하는 주체. "*"를 사용하여 모든 주체에게 액세스를 허용합니다. 즉, 모든 사용자 및 역할이 액세스 할 수 있음.
"Principal": "*",
// 허용된 작업을 지정. "s3:GetObject"를 사용하여 객체(파일)를 읽을 수 있는 권한을 부여
"Action": "s3:GetObject",
// 권한을 부여하는 대상 리소스를 지정
"Resource": "arn:aws:s3:::<bucket-name>/*"
}
]
}
이렇게 권한을 설정해 주고 링크를 다시 열면 index.html을 가져올수있는 권한이 열렸기 때문에 더이상 403페이지가 열리지 않습니다.
6. 오류가 발생하면 반환될 오류 문서 설정
아직 build시 내보낸 파일에 signin 파일이 없으면 이런식으로 오류 페이지가 나옵니다.
정적 웹 사이트 호스팅 편집에서 오류 문서를 index.html로 설정을 해주면
signin경로로 들어갔을때 index.html을 잘 보여줍니다.
배포 완료! 😊
❗️만약에 수정후 다시 올리고 싶다면??
객체에서 올렸던 모든 파일을 영구 삭제 후 수정한 build안의 파일을 다시 업로드 하면
바뀐 웹사이트로 잘 보여집니다.
참고자료
✅ IAM의 정책 및 권한
✅ Amazon S3를 사용하여 정적 웹 사이트 호스팅
'원티드 프리온보딩' 카테고리의 다른 글
[원티드 프리온보딩] 클라우드 컴퓨팅의 구분 (0) | 2023.08.27 |
---|---|
[원티드 프리온보딩] 서버와 클라우드 컴퓨팅 (0) | 2023.08.27 |
[원티드 프리온보딩] husky로 git hook 관리 (0) | 2023.08.22 |