이번 글은 목차대로 원하는 곳에 가서 보는 방식의 구성을 하기가 조금 어려웠다. 결국 이번엔 위를 수행해야 아래를 수행할 수 있는 실습 방식으로 글을 썼다.
VPC 생성
EC2 인스턴스들이 그냥 서로 막 연결되고 인터넷에 연결만 되는 요구사항이라면 VPC 생성할 필요가 없다.
그런데 이런식으로 망을 구성하면 (구성도 아니고 그냥 인스턴스만 생성한 것이다) 시스템의 복잡성도 올라가고 하나의 인스턴스가 추가되면 그에 대해 누구랑 연결해야 할지 누구랑은 연결이 되면 안될지 구성하는 데 시간이 많이 걸린다.
vpc를 적용하면 vpc별로 네트워크를 구성할 수 있다. 하지만 내가 하는 프로젝트는 가장 작은 규모의 프로젝트이기 때문에 하나의 VPC만을 생성하면 된다.
1. aws VPC 들어가서 VPC 생성 클릭
2. 이름태그 기억할 수 있게 이름을 정하고 IPV4 CIDR을 정한다. 본인같은 경우 호스트가 많이 필요없기 때문에 C클래스로 정했다.
3. VPC 에서 사용하는 대역은 총 3가지 10.0.0.0 ~ 10.255.255.255 / 172.16.0.0 ~ 172.31.255.255 / 192.168.0.0 ~ 192.168.255.255 이 있는데 아무거나 상관 없지만 추후에 수정은 불가능하다.
4. VPC 생성
이제 내가 컨트롤 할 수 있는 호스트는 8비트 = 256개의 호스트인데 그중 0과 255의 대역은 빼야 하니 총 254개를 잘 나누면 된다.
서브넷 구성
254개를 한 네트워크에 넣으면 정말 아깝다. 그래서 VPC내에서도 네트워크를 여러개 쪼갤 수가 있다. 그리고 나한테는 256개는 정말 많다. 그래도 이들을 잘 활용해야하니 먼저 이중화 작업을 한다.
Multiple AZ 구성 + 서브넷팅
DB서버의 고가용성과 장애 조치 기능을 위해 Multi-AZ라는 기능을 사용해서 예비 복제본을 프로비저닝하고 유지하여 데이터 이중화를 제공한다. 작은 프로젝트에서 굳이(?)라는 생각이 많이 들기는 한데 연습겸 해본다.
그에 앞서서 서브네팅을 해야한다. 서브네팅을 하기 위해 나는 딱 절반 나눠서 MultpleAZ에 이용할 거고 또 절반 나눠서 한 네트워크는 외부망 대역 다른 한 네트워크는 내부망 대역으로 나눌 생각이다. 아래와 같이 외부망 대역에 64개씩 2개의 서브넷 구성을 하고 내부망 대역에 32개씩 2개의 서브넷을 구성하였다.
C클래스 서브넷마스크 테이블을 보면 64개의 주소를 갖기 위해서는 192.168.0.0/26 의 서브넷팅. 그다음 다른 외부망 대역 역시 64개의 주소를 가져야 하므로 192.168.0.64/26. 내부망은 32개의 주소를 가져야하므로 192.168.0.128/27. 그다음 다른 내부망 대역 역시 32개의 주소를 가져야하므로 192.168.0.160/27.
이제 위 그림처럼 실제 aws 구성을 해보자.
1. 서브넷 페이지 접속
2. 서브넷 생성 > VPC 선택(아까 만들었던 VPC)
3. 4개의 서브넷 만들기
가용영역 둘 때 주의할 점
EC2 인스턴스를 시작할 때 "Your requested instance type is not supported in your requested Availability Zone(요청한 인스턴스 유형이 요청된 가용 영역에서 지원되지 않습니다)" 오류가 표시되는 이유는 해당 EC2 인스턴스 타입이 선택한 가용영역을 지원하지 않기 때문입니다.
하단 에러는 t2.micro 인스턴스 타입으로 ap-northeast-2(Seoul) 리전 안에서 가용영역 ap-northeast-2c를 선택하여 발생하는 에러입니다. 현재 t2.micro 인스턴스 타입은 ap-northeast-2a, ap-northeast-2c만 지원하고 있습니다.
Error: creating EC2 Instance: Unsupported: Your requested instance type (t2.micro) is not supported in your requested Availability Zone (ap-northeast
인터넷 게이트웨이를 통해 외부망 인터넷 구간과 연결
외부망이 인터넷 구간과 통신을 하려면 IGW가 필요하다.
2. 이름 정하고 인터넷게이트웨이 생성
3. VPC에 연결
라우팅 테이블에 IGW 연결
이제 이 인터넷 게이트웨이는 라우팅 테이블에 연결해놓아야 라우팅 테이블이 VPC 내에 있던 외부망이 게이트웨이까지 최적의 경로로 패킷을 전달할 것이다.
1. 라우팅 테이블 접속 > 이름 편집(퍼블릭에서 사용할 라우팅 테이블이기 때문에 public- 이라고 짓는다)
2. 라우팅 편집에 들어가서 전역 대역이 인터넷게이트웨이로 보내줄수 있도록 대상을 추가한다.
public 대역에 쓰일 EC2 생성
1. 인스턴스 시작 이동
2. 인스턴스 이름 작성 > AMI (본인은 우분투 선택)선택 > AMI중 우분투 서버 22.04 LTS가 프리티어이니 선택
3. 인스턴스 유형 등록 > t2.micro(1CPU/1GiB 메모리)가 현재 프리티어로 사용 가능
4. 키페어 등록
5. 네트워크 설정 > VPC 설정 > 서브넷 설정 > 퍼블릭 IP 자동 할당
퍼블릭 IP는 인터넷과 통신함에 있어서 퍼블릭 EC2는 무조건 할당해야한다. 이때 고정할당(Elastic IP)을 할지 자동할당을 할지 고민이 되었는데 Elastic IP는 한 계정에 최대 5개만 사용이 가능하고 설계상 좋은 구조가 나오기 힘들다고 한다. 그래서 자동할당을 했다(단 인스턴스를 껏다키면 IP가 바뀌는 단점이 있다.)
6. 외부망에 시큐리티 그룹 설정
인터넷에서 접속할 수 있는 망이니 시큐리티 그룹을 설정해준다.
7. 인바운드 보안 그룹 규칙 설정
22번 포트는 내 IP만 접근 가능하도록 설정한다. ssh는 기본 포트로 22번 포트를 사용하는데 만약 인스턴스의 22번 포트를 열어두면 해커가 22번포트를 통해 내가 만든 서버를 접속하기가 매우 쉽다. 따라서 내 IP에서만 ssh를 통해 서버에 접속할 수 있도록 설정한다. 만약 다른 곳에서 접속할 일이 생기면 VPN으로 접속하는 방법이 있다고 한다. 물론 접속하는 환경이 집,사무실,카페 많을텐데 그때마다 정책을 추가해주면 해결 가능하다.
ping 테스트를 할때 ICMP 프로토콜을 사용하는데 전체 대역대에서 사용할 수 있도록 정책을 추가한다.
8. 인스턴스 시작
9. ping 테스트 : ping [인스턴스 public IP주소]
내부망에서만 인터넷 접속이 가능하도록 NAT 게이트웨이 구성
내부망은 보통 개인정보 보호를 위해 구성한다. 하지만 도커이미지를 띄울려면 인터넷을 통해 도커라이브러리를 받아야하는데 (물론 다른 방법이 있지만 굉장히 번거롭다) 같은 AZ그룹의 외부망에 NAT GW를 만들어서 내부망이 해당 게이트웨이를 통해 public ip로 변환되어 필요한 라이브러리를 받기 위해 구성을 해볼 것이다.
1. 내부망에 EC2 인스턴스 생성 (스팩은 동일하게)
2. 네트워크 설정
퍼블릭 IP 자동 할당은 비활성화 하고 이따가 Elastic IP를 부여할 예정이다.
3. 인바운드 그룹 정책 아까와 동일하게 SSH와 ICMP 정책 추가
4. 탄력적 IP 주소 할당
5. 이 탄력적 IP 주소 연결
연결하고 저 주소로 Ping 테스트를 하면 인터넷에서 내부망으로 연결이 된다. 라우팅 테이블에 정책 설정이 필요하다.
6. 라우팅 테이블 정책 설정 > 서브넷 연결 편집
지금 라우터의 서브넷은 외부망만 연결되도록 연결을 편집한다.
7. 새로운 라우팅 테이블 생성 (인터넷 게이트웨이 없는 것) > 서브넷 연결 편집에서 내부망만 설정
8. 다시 핑테스트를 해보며 연결이 되지 않는 지 확인
9. 먼저 아까 public 인스턴스를 SSH를 통해 접속 한다
ssh -i [pem키] ubuntu@[IP주소]
10. Port 테스트 (외부망에서 내부망으로 SSH 접속가능한지 포트 테스트)
telnet [내부망 인스턴스 private IP주소] 22
당연히 되지 않는다. 아까 internal EC2 인스턴스의 보안 정책 그룹을 설정했을 때 22번포트는 본인 IP만 접속이 가능하도록 설정했기 때문이다. 따라서 외부망 보안그룹을 가진 서버들도 22번포트에 접속할 수 있도록 인바운드 보안 정책을 추가해준다.
11. pem키 외부망 서버에도 넣기 (내부망을 ssh로 접속하려면 pem키가 필요하기 때문이다)
vi 에디터로 복사 붙여넣기 하면 된다.
12. 외부망에서 ssh -i [pem 키] ubuntu@[private IP 주소] 을 통해 내부망 접속
하다가 외부망에서 내부망으로 계속 접속이 안됐는데 아웃바운드 규칙이 설정 안돼서 그렇다. 전체 대역으로 보낼 수 있게 아웃바운드 규칙을 설정해야 한다. (etc. 응답 없음(connection timeout) - 방화벽 닫힘 / 연결 거부됨(connection refused) - 방화벽은 열려 있지만 아무 서비스도 실행되지 않고 있음 )
13. NAT 게이트웨이를 만들어서 public ip로 전환하도록 하기
14. NAT 게이트웨이 페이지 들어가기 > 설정(public 서브넷에 생성 > 탄력적 IP 할당) > NAT게이트웨이 생성
15. 내부망 라우팅 테이블을 NAT 게이트웨이 연결 (전체 대역대에 대해서 NAT게이트웨이를 통해 가도록 설정)
16. 내부망 서버에서 sudo apt update 수행
17. 그동안 한 결과
인바운드 Security Group 설정
1. 외부망의 경우 전체 대역대에서 443포트(https)를 오픈 한다.
2. 내부망에서는 DB을 연결할 3306 포트에 대해서 외부망만 접속할 수 있도록 지정
레퍼런스