VPC, Subnet까지 생성했다면 서비스 배포를 위한 마지막 작업인
EC2, GateWay, FireWall 설정을 통해 배포 준비를 완료 해 보겠습니다.
먼저 EC2 생성을 통해 서비스가 실행 될 가상 인스턴스를 생성합니다.
인스턴스 생성을 통해
Ubuntu 18.04 LTS
t2.micro
VPC, Subnet: 이전에 만들었던 것
다음과 같이 설정하고, 인스턴에 직접 접근 하기 위해 ssh 키는 따로 저장해놓습니다.
(ssh 키는 재발급이 안되기 때문에 저장을 잘 해야함)
위와 같이 생성하면 우리가 만든 EC2가 생성되고 다음과 같은 cloud 환경을 만들었습니다.
- 여기서 public, private는 아직 개념만 생각한 상태입니다. public은 외부와 인터넷 연결이 됐을 때 public이라고 합니다.
여기까지 하고 나면 배포를 위한 준비는 끝났습니다. 하지만, 우리가 EC2에 직접 들어가서 서버를 돌리고 설정을 하기 위해서는 추가적인 과정이 필요합니다.
- 외부에서 접속 가능하게 public IP 할당. -> ssh를 통해 접속 가능.
- application이 특정 port를 필요로 한다면 방화벽 설정.
1. Public IP 할당, ssh 접속.
위의 상태는 VPC안에서 내부 통신을 위한 IP만 존재하고, 외부에서 접속 할 수 없습니다.
아직 public IP주소가 없기 때문에 elastic IP 서비스를 통해 고정적인 IP를 할당하고 접속해보겠습니다.
먼저 Internet GateWay를 만들어둔 vpc와 연결하여 외부와 통신 가능한 상태를 만들고,
고정 IP를 할당하면 다음과 같이 외부에서 접속할 수 있습니다.
- ssh를 통한 인스턴스 접속.
이렇게 모든 준비가 끝났습니다.
docker를 설치해서 container로 서비스를 실행해도 되고, ssh 파일 전송을 통해 파일을 실행해도 됩니다.
마지막으로 nginx를 실행하거나, spring을 실행하면 80 or 8080포트를 통해 실행하게 되는데, 현재 ssh접속을 위한 22 port밖에 열려있지 않습니다.
그러므로 필요한 port만 개방하여 사용하면 됩니다.
ex)
모든 port를 개방하는 방법은 보안적으로 매우 취약하기 때문에 특정 port만 열어두거나, 맨 앞에 서버를 80번 port로 연결한다음 뒤에 다른 서버와 통신하는 형태로 보안성을 높일 수 있습니다.
heroku를 통해 서버를 쉽게 구성 할 수 있지만, 네트워크 구성과 그 외 통제권을 더욱 이용하고 싶다면 AWS 서비스를 이용하는 것이 좋을 것 같습니다.
실제로 프로젝트를 진행하면서 인프라에 대한 확장성을 고려 할 때, heroku보다 설정하기 편했던 것 같습니다.
이상 서버 배포를 위한 기본적인 AWS 인프라 설계 였습니다. 추가 내용이나, 그 외 AWS 서비스를 이용하며 유용했던 것은 추가로 올리겠습니다!
+ 추가 할 내용이나 부족한 부분이 있다면, 댓글 작성 부탁드립니다! :)
