Beelog

현재 S3에 프론트엔드의 빌드된 파일이 저장되어 있고 CloudFront를 통해 서비스를 하고 있습니다. 하지만 CloudFront의 배포 도메인 이름을 통해 접속하는 경우 403(또는 404) 에러가 발생하며, 반드시 뒤에 /index.html을 붙여야 정상적으로 동작합니다. 이번 글에서는 CloudFront에서 접속하는 S3의 엔드포인트 종류에 대해 알아보고 CloudFront의 배포 도메인만 입력했을 경우에도 정상적인 동작이 가능하도록 수정해보겠습니다. S3 엔드포인트 종류 1. S3 웹사이트 엔드포인트 - S3의 웹호스팅 기능을 활성화 하면 생성되는 웹사이트 주소 DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com 2. S3 REST API 엔드포인트 ..

이전 글에서 Public Subnet에 있던 EC2를 Private Subnet으로 이전하였습니다. 이제 Private Subnet으로 옮겨간 EC2에 자동으로 백엔드 소스를 배포하고 서버를 실행하는 방법을 알아보겠습니다. 먼저, 알아둘 것은 CodeDeploy를 통해 자동 배포를 진행하려면 EC2 인스턴스에 설치된 codedeploy-agent에서 CodeDeploy와 S3 엔드포인트에 접속할 수 있어야 합니다. 이를 위해 NAT 게이트웨이가 필요합니다. 기존에 NAT 게이트웨이를 생성하여 정상적인 웹 서비스 응답이 가능하도록 구성하였지만, 혹시라도 Private Subnet에 EC2가 있는데 NAT 게이트웨이를 생성하지 않은 경우에는 먼저 NAT 게이트웨이를 생성해야 합니다. NAT 게이트웨이 생성 ..

이전 글에서 Public Subnet에 있던 백엔드 서버 EC2를 Private Subnet으로 옮기는 작업을 수행하였습니다. 하지만 새로 생성한 EC2에 서버가 실행되지 않아서 정상적으로 동작하지 않았습니다. 따라서 이번 글에서는 Private Subnet에 생성된 EC2에 ssh로 접속하여 직접 서버를 실행시켜 보도록 하겠습니다. 1. Public Subnet에 생성할 EC2의 보안 그룹 생성 EC2를 생성하기 전 먼저 보안 그룹을 생성합니다. 해당 보안 그룹은 ssh 접속만 허용합니다. 2. Public Subnet에 EC2 생성 기존 Public Subnet 중 하나에 새로운 EC2를 생성합니다. 이때 퍼블릭 IP를 활성화하고 위에서 생성한 보안 그룹을 지정합니다. (EC2 생성 방법은 기존에도 ..

이전 구성에서는 백엔드 소스와 노드를 실행하는 EC2가 Public Subnet에 생성되어 있었습니다. 이는 보안상 좋지 않은 구성이기 때문에 EC2를 Private Subnet으로 옮기는 작업을 수행해 보겠습니다. 이번 작업에서는 단순히 기존에 만들었던 리소스들을 수정해서 새롭게 구성을 할 수 없는 경우가 대부분이라 새로 생성하는 것들이 많았습니다... 실제 아키텍처를 구성할 때는 미리 구조를 잡고 리소스들을 만드는 것이 좋을 것 같습니다...ㅠ 1. EC2를 옮길 Private Subnet 생성 새로운 백엔드 서버를 실행할 EC2를 생성하기 전 해당 EC2들이 설치될 Private Subnet을 먼저 생성합니다. 2. Private Subnet을 위한 라우팅 테이블 생성 Private Subnet으로..

이전 글에서 Front-end 소스를 수정하고 CodeCommit Repository로 push하는 경우 CodePipeline을 통해 자동으로 빌드한 뒤, S3에 빌드된 소스를 저장하였습니다. 하지만 CloudFront에 캐시가 남아있어서 바로 적용되지 못해 AWS Management Console에서 CloudFront로 들어가 직접 무효화를 해줘야 하는 번거로움이 있었습니다. 이번 글에서는 CloudFront의 캐시를 지우는 내용을 Lambda로 작성하여 CodePipeline에 연결하여 자동화해 보도록 하겠습니다. 1. 람다 Role 생성하기 람다 함수를 사용하기 전 먼저 람다 역할을 생성합니다. 이번 람다에서는 CloudFront에 접근할 것이기 때문에 관련 정책을 추가합니다. 또한, 로그 정보..