https://www.youtube.com/watch?v=R1UWYQYTPKo&t=925s
위 강의를 듣고 내용에 대해서 필기한 자료 (총 45분 강의 중 28분 부터의 필기)
본 강연에서는 VPC개념과 설정 그리고 요구에 맞게 가상 네트워크를 설정할 수 있는 방법에 대해 다루고 있습니다.
AUSG 4기 오거님의 추천으로 강의를 듣게 되었습니다! (+테라폼 스터디)
목차
1. 이전에 본 내용
1-1. 인터넷 액세스 제한: 서브넷 별로 다른 라우팅
2. NAT gateway
2-1. NAT gateway 서비스 제공
2-2. NAT gateway를 가지고 route를 설정하는 방법!
3. VPC 간 연결: VPC peering
3-1. Security groups across peered VPCs
3-2. Establish a VPC peering: 요청시작
3-3. VPC peering 제약사항
4. 회사 네트워크에 연결: 온프레미스 데이터센터와의 연결
4-1. VPN하고 Direct connect
5. VPC 및 다른 AWS 서비스
5-1. RDS
5-2. S3 (Simple Storage Service)
6. VPC Flow Logs
7. 총정리 (VPC: your private network in AWS)
1. 이전에 본 내용
VPC를 가지고 인터넷에 연결하여 서비스하도록 만들었는데, 이 VPC를 어떻게 또 다르게 연결할 수 있는지에 대해 알아볼것임!
1-1. 인터넷 액세스 제한: 서브넷 별로 다른 라우팅
앞에서는 인터넷으로 향하는 라우팅 정보를 가지고 인터넷과 통신하는 라우팅, 서브넷만 말했는데 만들다보면 앞에있는 프론트엔드 서버는 인터넷 서버와 통신하지만 백엔드 서버는 통신을 절대 못한다. 저기 위에 있는 인터넷 게이트 웨이가 아래는 연결이 안되어있기 때문에!
서버넷 별로 각각 다른 라우팅 설정들을 통해서 우리가 원하는 네트워크를 구성할 수 있다.
2. NAT gateway
이전 그림을 90도로 회전, 오른쪽에 있는 서브넷은 인터넷하고 연결된 서브넷(Public subnet), 왼쪽은 인터넷과 연결되지 않은 서브넷(Private subnet)이라고 하자.
서비스를 위해 열어놨지만 Private subnet에 애플리케이션 패치를 해야함. os 패치, 외부 애플리케이션 소스가 담겨있는 레포부터 애플리케이션 소스를 deploy도 해야되고 인터넷으로 연결되해야되는데 인터넷으로 갈수있는 관문이 없다. 그럼 다운받고 카피하고 이런식의 불편한 방식을 이용해야되는데 이러면 힘드므로 NAT(나트,넷트)를 사용.
2-1. NAT gateway 서비스 제공
서버들은 NAT gateway를 통해서 public하게 왔다가 다시 무언가 다운받아서 전달하는 경로가 생성됨.
장점은 서버들은 NAT gateway를 통해 인터넷에 가 다운로드를 받을 수 있는데, 외부에서 저 서버들을 찾아갈 수 있는 방법은 없다. 왜냐하면 이 서버들은 public ip address가 없기 때문이다!
2-2. NAT gateway를 가지고 route를 설정하는 방법!
management console를 통해서 보자. 나머지 인터넷으로 가는건 igw가는게 아니라 nat gateway의 id를 적어주면 aws가 알아서 패킷들을 NAT gateway로 보낸다. NAT gateway는 인터넷으로 보냈다가 패킷을 받아서 다시 원래 처음에 커넥션을 맺었던 서버에 패킷을 돌려준다.
3. VPC 간 연결: VPC peering
VPC peering이라는게 만들어진건 15년도임.
예) 서비스를 운영할때 다양한 종류의 서비스를 운영한다. 각 게임마다 VPC를 따로 운영한다. 그런데 회사에 게임 유저들에 대한 마스터 정보들을 한군데 가지고 있고 인증을 한군데에서 다 처리하고싶다. (게임 서버마다 인증서버들을 다 따로 두면 관리하기 힘들고, 중복된 비용 투자가 되기 때문에) 즉 공통 모듈을 만들고 싶은 것임.
아주 다른 리소스와는 분리하고 싶다하면 완벽하게 위의 사진처럼 사용할 수 있다. 완벽하게 데이터센터의 전용라인을 연결한것 처럼 private한 라인을 연결해서 사용할 수 있다. 용도는 인증, 모니터링, 로깅, 원격관리, 스캐닝 이런 것들을 위해 VPC peering을 만들어서 사용한다.
3-1. Security groups across peered VPCs
두개의 VPC가 보안 그룹 설정할때, 소스를 ip가 아닌 보안 그룹으로 소스를 referencing할 수 있다고 했다. 이때 VPC peering을 하게 되면 옆에 다른 VPC(내 VPC가 아닌)있는 보안 그룹을 referencing있다 즉 보안 정책 강화 가능
3-2. Establish a VPC peering: 요청시작
만드는 방법은! 두 VPC연결을 할때, 누군가가 신청을 하고 누군가가 승인을 해줘야한다.
account가 같을수도 다를 수도 있다. 회사끼리 서비스하는 것들을 두개 네트워크를 묶을수도 있기 때문에!
피어링 요청 -> VPC오너가 피어링 요청을 수락하고 중간에 커넥션이 생기고, 경로를 만든다. 쟤를 통해서 패킷을 보낼수있도록 라우팅을 잡아줘야함!(라우팅 테이블 만드는건 진짜 간단함 3번째에 있는 레코드!)
10.55.0.0/16 이 네트워크로 가는 패킷이 있다면, pcx라고 하는(피어링 게이트웨이를 만들고 나면, 승인하면 id가 나온다. 즉 피어링 게이트웨이로 향하게 하라고 만든 라우팅 테이블) 곳으로 보낸다. 10.55.3.6서버로 저쪽에서 패킷을 보내면 자기가 알아서 peering으로 패킷을 보낸다. 그러고 받아서는 돌려주면 된다. 그럼 VPC와 VPC끼리 만들어지게 된다.
3-3. VPC peering 제약사항
굉장히 편한거 같지만 제약사항이 있다.
C하고 D는 통신을 못한다. Transit VPC(하나의 VPC를 통해 다른 VPC로 트래픽이 왔다갔다 하는것)
현재 VPC peering은 transit VPC를 지원하지않음. 그러나 이런 용도로 네트워크를 구성하고 싶으면 AWS가 권고하는 패스트 프렉티스 가이드가 있움... 그거 봐라...
만일 C와D가 꼭 통신을 해야된다면 CD사이에 peering을 만들어주면 된다.
그러나 왜 만들지 않냐! peering gateway가 너무 많아진다. (A가 바라보는게 6개 등등 즉, 18개가 생긴다. ) 개수가 많아지면 관리가 많아지기 때문에 불필요한 peering gateway는 만들지 않는게 좋다!!!
4. 회사 네트워크에 연결: 온프레미스 데이터센터와의 연결
AWS내에 VPC끼리도 연결하지만 우리의 온프레미스 데이터 센터와도 연결을 한다.회사의 데이터센터에는 굉장히 중요한 데이터를 AWS에 migration하고 싶다. 그러나 인터넷에서 전송하면 보안팀이 허락하지 않을뿐더라 risk가 있다.
이걸 안전한 경로로 전송을 하는 방법은 2가지가 있다.
1. virtual private network(VPN) 2.direct connect(DX)
사이를 연결해놓고 나면 데이터센터를 네트워크로 확장해놓은 것처럼 사용이 가능하다. (하이브리드 네트워크 구조)
VPN 연결하려면 장비와 장비를 연결해야되는데, 데이터센터에는 VPN 장비만 마련하면 된다(AWS에서는 customer gate way라 칭함.)
AWS에 VPC에는 게이트웨이(virtual private gateway)가 있다. 저걸 가지고 만들게 되면 저 줄사이를 IpSec tunnels 은 항상 2개로 만들어진다(HA때문에). 연결하는건 굉장히 쉬운데 VPN 커넥션을 생성하면서 우리가 사용하는 VPN장비의 제조사와 장비에 들어가있는 OS버전을 선택하면 ㅇㅇㅇ을 만들어서 드린다. (네트워크 엔지니어가 아니면 직접하기 까다로운 설정-> 클라우드가 서버, 라우팅 테이블, 네트워크 설정, 방화벽 설정 등등에 대한 자유로움을 줬다.)
4-1. VPN하고 Direct connect
VPN해서 연결은 되었지만 서비스하기에는 약간 부족함이 있다. secure한 채널은 보장이 되지만, 굉장히 많은 데이터를 정해진 시간내에 보내고싶은 경우, 둘 사이에 latency를 보장받고 싶은 경우.
VPN 연결을 하지만 사실 저 경로는 인터넷이다. 인터넷 상에 IpSec tunnel 즉 보안터널을 연결해주는 것이지, 전용망을 사용하는게 아니다. 그래서 품질이 평소에는 좋다가 비 올때 잡음이 오던 시절 처럼. 인터넷 품질은 좋았다가 나쁠수도 있다. 이런 risk를 없애기 위해 direct connect이라고 하는 전용 라인을 연결하기도 한다.
5. VPC 및 다른 AWS 서비스
지금까지 말한 VPC에 대한 내용들 이외에 다른 AWS서비스와 VPC가 어떤 관계가 있는지 4가지로 정리하여 설명.
5-1. RDS
EC2 인스턴스 뿐만 아니라 VPC안에 위치 시킬수있는 AWS의 다양한 서비스가 있다.
관리형 RDB 서비스인 RDS(relation database service). Instance를 띄우면 VPC안에 위치시켜야 한다. private 서버넷에 담아놓으면 외부에서 접속 못하게 할 수 있다. 또한 람다라고 하는 람다펑션도 VPC안에서 실행시킬 수 있는 옵션을 추가하였다.
RDS뿐만 아니라 데이터웨어하우스 서비스인 redshift도 VPC안에 위치 시켜야한다. 때문에 VPC를 제대로 만들어야 우리가 원하는 네트워크 연결을 할 수 있다.
5-2. S3 (Simple Storage Service)
VPC안에 위치하고 있지 않음. 인터넷이 연결된 곳이라면 S3에 access 할수있다! (리전에 상관없이_서울 리전에 있는 S3 미국, 유럽에 있는 사람이 인터넷 통해 access할 수 있다.)
S3에 접근하기 위해서는 인터넷 게이트 웨이를 통해 VPC 밖으로 나와야한다. 하지만 서울 리전에 굉장히 가까운 곳에 있는데, 네트워크 적으로는 인터넷을 통해 나갔다와야하는게 불합리 하기도 하다.... 보안관점에서 S3라고 하는 서비스는 ip가 고정되어있지 않아(회사의 보안정책 중에 outbound traffic에도 깐깐한 보안룰을 적용해야된다는 보안정책을 가진 회사는 이걸 anywhere로 오픈하는게 어려울 수 있다.) 발생하는 문제들 때문에 VPC endpoints for S3라는 것을 만듦.
인터넷을 통해 왔다갔다 하는 대신 VPC endpoint 라는 걸 제공하며, 하나를 만들어놓으면 private하게 S3에 접속이 가능해진다.
VPC endpoint의 장점) IAM이나 S3 Bucket Policy를 가지고 access control를 잘할 수 있게 된다.
예) VPC endpoint로 왔다갔다하는데, S3 Bucket 중에 내가 가진 Bucket이 매우 많은데 특정 버킷만 access하라고 설정 혹은 S3 Bucket에는 외부에서 인터넷을 통한 access는 차단하고 애플리케이션에서 오는 request만 허용해주는 Policy 설정이 가능하다.
6. VPC Flow Logs
방화벽 설정도 하고 진행을 했는데, 실제로 내가 허용한 방화벽 정책에 대해 패킷이 들어오는지 드랍, 거절되는지 등등에 대해 확인할 수 있어야한다. 이런 자료로 분석 및 사고를 미연에 방지해야하는 이때 사용하는 것이 VPC Flow Logs 서비스이다.
Network ACLs(줄여서 NCL_넷클이라고도함),Security groups (우리에게 익숙한 방식)을 통해 만들어지는 방화벽에 걸리는 모든 패킷들의 로그들을 수집해서 제공받을 수 있다.
7. 총정리 (VPC: your private network in AWS)
1. VPC안에 ec2 인스턴스 안에 만드는데 서브넷을 가용영역 별로 만든다.
2. Security groups, Network ACLs가지고 방화벽 정책을 설정한다.
3. 때론 특정한 서브넷은 인터넷으로 가는 관문을 만들어주고 인터넷으로 가는 경로를 지정해주기도한다.
또는 우리의 데이터 센터와 VPN 또는 direct connect로 연결할 수 있다.
다른 VPC와 연결을 하던지, VPC 밖에 있는 S3같은 서비스하고도 연결할 수 있는 방법에 대해서 알아보았다.
'STUDY > Cloud' 카테고리의 다른 글
[클라우드_강의] 1️⃣가상 데이터 센터 만들기_VPC 설정 (0) | 2021.09.02 |
---|---|
[클라우드] 그림으로 배우는 클라우드 인프라와 API의 구조_5,6장 (0) | 2021.08.31 |