Public Cloud(AWS) : Network Connectivity service - VPC Peering, VPC Endpoint, Route53

Network Connectivity

VPC Peering

• Peering : 격리되어있는 서로 다른 2개이상의 VPC간의 네트워크 연결 → 매우 광범위한 연결까지 지원( 동일계정의 서로다른 VPC, 다른계정의 서로다른 VPC, 다른리전의 서로다른 VPC )

• 연결자체는 무료이지만 트래픽에서 과금이 발생가능 ( 동일 리전, AZ의 데이터 트래픽은 무료이지만 이를 교차하는 트래픽에는 과금 )
• 제약사항 : CIDR Block이 겹치는 경우 VPC Peering 구성 불가능 & 전이적 연결 제한 ( 통신을 위해서는 직접 피어링 )

 

VPC Peering 실습

 

 

[ 동일 리전 VPC Peering 연동 ]

 

피어링 연결 생성

(1) VPC1이 요청자 & VPC2이 수락자 → 요청을 수락해야 피어링이 활성화됨

 

 

(2) 피어링된 VPC의 경로정보를 라우팅 테이블에 추가해야 통신가능 ( 양방향 ), 유형자체가 피어링으로 등록

• VPC1 → VPC2 : VPC2 네트워크( 10.10.0.0/16 )를 피어링 연결( 생성한 피어링 )으로 등록

 

• VPC2 → VPC1 : : VPC1 네트워크( 10.0.0.0/16 )를 피어링 연결( 생성한 피어링 )으로 등록

 

VPC2 → VPC1 : : VPC1 네트워크( 10.0.0.0/16 )를 피어링 연결( 생성한 피어링 )으로 등록

 

 

VPC2의 private subnet에 생성한 네트워크 테스트용 EC2 인스턴스( 10.10.40.36 )

웹서버( VPC1 )에서 테스트용 웹서버( VPC2 )로 통신가능

 

 

public subnet 라우팅 테이블에서도 VPC2와 연결을 설정

 

EC2는 서버내 설정된 라우팅 테이블로 라우터로 전송

라우터에서도 라우팅 테이블을 기반으로 전송

 

라우팅 테이블 구성 : dest( 주소 ) → genmask로 prefix가 어디까지인지 파악가능, ( 목적지 )

양방향으로 통신이 가능하려면 서로 라우팅 테이블에 서로를 등록

 

 

[ Multi Region VPC Peering 구성 ]

같은 리전의 다른 VPC가 아니라(VPC1, VPC2) 다른 리전(수락자)의 VPC( 직접 VPC ID를 복사해와야함 )

다른 리전과 피어링 ( 프랑크프루트 리전 & 서울 리전 )

• 연결대상 : 프랑크 프루트의 VPC

• 요청자는 서울의 VPC1, 수락자는 프랑크프루트의 VPC( lab-edu-vpc-eu )

 

• 수락자(프랑크프르투)에서 피어링 요청을 수락 ⇒ 피어링이 활성화

 

• 하지만 통신정보(라우팅)를 추가적으로 더 설정해줘야 통신이 가능하다!

프랑크 프루트 private 라우팅 테이블 → 서울 private subnet ( 10.0.0.0/16 )

서울 VPC1의 private 라우팅 테이블 → 프랑크 프루트 private subnet ( 10.30.0.0/16 )

 

 

스택에서 생성될때 output값으로 내뱉었던 네트워크 실험용 인스턴스 주소( 프랑크 프루트 VPC의 private subnet에 생성 )

현재 vscode에서 ping을 날렸을때 제대로 이루어지고 있음

 

 

[ 전이적 VPC Peering Network 통신 테스트 ]

현재상황 : 서울의 VPC2 - 서울의 VPC1 - 프랑크프루트 VPC

⇒ 서울의 VPC2와 프랑크프루트의 VPC는 연결되지 않음

억지로 프랑크프루트의 private 라우팅 테이블에 서울 VPC2 private 서브넷을 등록 ( 피어링 타입, 10.10.0.0/16 )

 

억지로 서울의 VPC2 private 라우팅 테이블에 프랑크프루트 private 서브넷을 등록 ( 피어링 타입, 10.30.0.0/16 )

서울 VPC2 private 서브넷에 위치한 네트워크 테스트용 EC2 ⇒ cloud formation을 통해 생성하여 여기서 그 주소를 얻음 ( 10.10.40.36 )

프랑크프루트의 서버에서 세션 매니저로 ping 통신을 시도하지만 진행되지 않음

 

 

VPC Endpoint

VPC내부 리소스가 AWS서비스를 접근할때 IGW처럼 밖으로 나가지 않고 Private Link를 사용해 사설 통신을 할 수 있게 된다. ( 내부 트래픽으로 전환 ) ⇒ 보안적 우수성

AWS 서비스 접근을 위해 VPC외부로 나가는 공간이 IGW와 같은 public경로를 거치지 않고 내부 Endpoint 경로로 흘러간다.

 

 

[ VPC Endpoint 종류 ]

• Gateway Endpoint : S3, DynamoDB 서비스를 대상으로 엔드포인트가 제공됨( 무료 ) → 라우팅 테이블의 경로정보를 이용하여 통신
• Interface Endpoint : 모든 서비스 대상으로 엔드포인트가 제공됨( 트래픽에 따른 비용발생 ) → endpoint 역할을 하는 IP값이 도출됨, 별도로 라우팅 테이블을 조정할 필요가 없음 → IP주소를 가지기에 Elastic Network Interface(ENI)가 할당되게 됨, 여기에는 접근제어를 할 수 있는 Securtiy Group이 할당가능함

 

 

Endpoint 실습

각 유형의 엔드포인트를 만들고 사설 통신을 테스트해보자

 

 

[ S3 버킷용 VPC Endpoint 생성 (Gateway Type) ]

 

(1) VPC Endpoint - S3 ( lab-edu-endpoint-s3 )

 

서비스 : 유형 필드의 값이 Gateway인 항목 선택

VPC1( lab-edu-vpc-ap-01 )에 생성

NAT 게이트 웨이 제거

web-server에서 인터넷이 안되는 환경임에도 endpoint를 이용한 접근이 가능하다

 

• S3 버킷에서 기존 권한을 삭제

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::307946651307:role/lab-edu-role-ec2"
                ]
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::lab-edu-bucket-image-307946651307",
                "arn:aws:s3:::lab-edu-bucket-image-307946651307/*"
            ]
        }
    ]
}

S3의 Bucket Policy : 인터넷을 통해서도 VPC외부의 S3에 대한 접근이 가능한 상황( 해당role만 존재한다면 )
⇒ private에서도 NAT를 날렸을때 endpoint로 S3에 접근이 가능함

 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::lab-edu-bucket-image-307946651307",
                "arn:aws:s3:::lab-edu-bucket-image-307946651307/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:sourceVpce": "vpce-0a4879793e0583a0a"
                }
            }
        }
    ]
}

role이 없어도 모든 사용자에 관해서(*) Endpoint로 접근한다면 가능함

엔드포인트의 라우팅 테이블을 관리 : 엔드포인트를 사용할 private subnet의 라우팅을 연결

 

 

(2) VPC Endpoint - SSM

Session Manager 서비스 사용요건 : 인터넷이 되는 서버 혹은 VPC endpoint를 session용으로 만들어놓고 SSM을 사용가능한 권한을 가지고 있어야함

NAT 게이트 웨이 제거

 

SSM 사용불가한 상황

 

먼저 interface endpoint에 적용할 보안그룹( lab-edu-sg-endpoint-interface )부터 생성하기

⇒ 인바운드 포트를 open함 : 443 포트 (HTTPS), 53 포트 (DNS)

 

ssm용 엔드포인트를 생성 ( interface 엔드포인트로 IP를 가짐 → DNS 활성화 )

 

사전에 VPC설정에서 DNS 호스트 활성화 & 서브넷은 가용영역에 위치한 private subnet 2개를 각각 할당 & 보안그룹 설정

이외에도 2개의 엔드포인트(ssm, ssmessages, ec2messages)를 추가로 생성한다. ( 보안그룹 공유 )

다시 lab-edu-ec2-web에 SSM를 이용하여 연결하려고 하면 잘 된다

 

기존의 private 서버는 NAT게이트를 이용하여 VPC 외부로 접근을 하였다 ( S3 접근 )

( * bucket policy의 condition : NAT게이트의 IP를 가진 것의 접근을 허용, source IP가 NAT gateIP인 경우 접근 allow )

⇒ NAT게이트 없이도 endpoint로 외부 접근이 가능하도록 한다. ( * bucket policy의 condition : endpoint의 IP를 가진 것의 접근을 허용 )

 

Route53

AWS에서제공하는완전 관리형 DNS 서비스 : 도메인 구입, 도메인 호스팅 지원( 외부 도메인을 hosted zone에 등록하여 사용가능 )

• DNS routing policy : 도메인 질의가 오면 적절한 IP를 반환 → 이때 라우팅 조건에 따라 다른 Endpoint로 연결하며 트래픽 조절 ( LB의 DNS서비스로 접근X, bastion의 IP로 접근X )
• 도메인 및 연결된 리소스에 대한 헬스체크(HealthCheck)기능을 제공
• AWS에서 유일하게 100% SLA를 제공( 서비스 안전성 보장 )

 

Public Hosted Zone : 인터넷에 연결된 모든 리소스에서 접근 가능한 DNS 서비스 제공

Private Hosted Zone : 특정 VPC 내부 리소스만 접근가능한 Local DNS 서비스 제공 ( VPC 내부 리소스간 통신을 위한 맞춤형 도메인 )

 

 

[ DNS Records Type ]

• A : 도메인 주소와 IPv4주소를 직접할당
• AAAA : 도메인 주소와 IPv6주소를 직접할당
• CNAME : 별칭레코드( canonical name record ), 도메인주소를 다른 도메인 주소에 할당 ( IP주소가 아닌 도메인주소에 매핑하는 개념 )
• MX( mail exchanger ) : 도메인주소를 이메일 서버에 할당 ( 도메인주소를 이메일주소로 사용 )
• NS( name server ) : 구매한 도메인을 관리하는 네임서버 정보 ( 구입한 도메인의 경우 해당 네임서버로 가서 매핑정보를 반환받음 )
• SOA( start of authority ) : 구입한 도메인에 대한 기본정보가 담긴 레코드 -> open search로 로그를 검색, 분석, 시각화 가능

 

[ Routing policy ]

 

(1) Simple policy : 단순한 방식으로 도메인에 대한 트래픽을 리소스로 전달하는 방식

• single value : 도메인과 IP가 일대일 매핑
• multi value : 도메인에 매핑되는 다중값 IP가 반환되고 접속장치(client)에서 하나를 선택하여 사용

 

(2) Weighted : 도메인에 등록된 리소스 마다 가중치를 적용해 트래픽 양을 조절하는 방식

레코드 유형 및 이름을 동일하게 구성한뒤, 각 레코드에 가중치를 설정

 

기존 시스템의 위치를 이동하는 경우에 주로 사용( 기능은 동일하나 위치가 분산됨 ) : 기존 서버의 트래픽을 감소시키고 새로운 서버에서의 트래픽을 점진적으로 증가시킴, 트래픽이상을 체크하며 점진적으로 비중을 조정해나감

 

(3) Latency : 응답지연시간이 가장 적은 리소스의 정보를 반환하는 방식

다중 region 환경에서 클라이언트와 가장 근접한 리소스로 연결될 확률이 높음 ( 그러나 경우에 따라 가까이 위치해도 트래픽이 몰린다면 연결되지 않을 수 있음 )

 

(4) Failover : 상태검사기 리소스를 이용하여 정상 리소스값을 반환하는 방식

기본 레코드와 보조 레코드로 구성 -> 기본레코드의 상태가 unhealthy라면 보조 레코드로 서비스( 상태호전에 따라 다시 정상화 가능 )

 

(5) Geolocation : Client의위치 정보를 기반으로가장 가까운 리전의 리소스정보를 반환하는방식

참조중인 로컬 DNS 서버의 IP주소를 기반으로 동작

EDNS(RFC 7871) 기능의 지원 -> 확장헤더에 client IP를 추가하여 전달하여 정확한 위치를 전달

 

 

[ Route53 실습 ]

 

도메인 등록이전에 가용성확인 ( 누군가 쓰고 있는가를 확인 )

도메인마다 가격이 다름

 

 

(1) Route 53 Public Hosted Zone 생성

호스팅 영역 : 나의 도메인 관련 하위 도메인에 대한 트래픽을 라우팅하는 방식에 대한 정보를 담은 컨테이너

NS, SOA타입의 레코드는 기본으로 생성된다.

DNS 질의시 NS의 라우팅 대상 4개중 하나로 가서 IP값을 받아오게 된다.

 

(2) Public Hosted Zone NS Record 생성

서울리전에서의 lab-edu-ec2-web

 

버지니아 리전의 lab-edu-ec2-web-us

 

프랑크프루트 리전의 lab-edu-ec2-web-eu

 

+) 유럽영역에서 통신문제 발생( 연결거부 ) -> 포트상태를 확인, 80번 포트 리스닝으로 교정( 세션메니저 이용 )

 

# public ip 기록

ap-northeast-2	43.201.51.249
us-east-1		54.196.226.49
eu-central-1	18.199.221.16

 

 

[ Simple Routing Policy ]

레코드 추가 : simple 방식 & ap-northeast-2 43.201.51.249

서울리전의 레코드 생성( simple )

 

도메인명으로 정상접속

dig 도메인 네임 수행시 등록된 하나의 IP값(public IP)을 반환함

 

 

[ Multi Value Simple Routing Policy ]

TTL(time to live) : 값을 반환하는 네임서버가 매핑변환값을 보관해 놓을 시간

레코드의 값에 서울리전 뿐아니라 다른 리전의 웹서버 ip도 동시에 등록해본다.

dig 수행시 값이 3개 출력됨

 

실제 도메인을 통한 접속시에도 웹브라우저에 랜덤하게 반영

 

 

[ Route 53 Weighted Routing Policy ]

 

 

dig 접속시 가중치에 따라 다른 IP값을 반환

 

 

[ latency routing policy ]

레코드를 새로 생성 ( latency라는 이름으로 등록, 지연시간 정책 & 리전 정보 등록 )

지연시간은 대체적으로 같은 위치에서 실행한 결과를 따르게 된다

 

서울의 vscode에서 실행한 결과

 

버지니아 리전의 web-server에서 실행한 결과( session manager )

 

프랑크 프루트 리전의 web-server에서 실행( session manager )

 

 

[ fail over 검사 ]

 

별도의 상태검사기 리소스를 구축해야한다.

Route 53 메인 콘솔 화면 → 상태 검사 리소스 탭 → 상태 검사 생성 버튼 클릭

 

(1) 서울리전의 상태검사기 만들기

상태검사기는 같은 리전의 것만 쓰는 것으로 한다.

 

각 지역에 있는 상태검사기에서 검사중

보안그룹에서 내IP만 인바운드 허용해서 fail

보안그룹 편집후에 실행시 다시 잘 동작함을 알 수 있다.

 

(2) 레코드 생성 → 장애조치 유형, 상태 검사기 등

 

서울IP를 기본으로, 버지니아IP를 장애조치 보조로 설정하여 생

 

일반적인 경우 서울의 IP로 접속된다.

 

의도적으로 서울 인스턴스를 중지시켜서 장애를 발생시긴다 -> 상태검사기에서도 Failure결과가 도출됨

 

도메인 접속시 미국으로 접속됨 (보조)

 

그러나 다시 서울 인스턴스를 재시작하게 되면 서울 인스턴스의 IP로 정상접속이 이루어진다.

이와 같은 방식으로 기본을 AWS, 보조를 Azure로 두고 시스템 자체를 이중화하기도 한다.

 

[ geolocation ]

dig 시에 서울리전의 ip반환

 

미국에 위치한 네임서버로 변경

 

버지니아 ip 반환

 

구글의 EDNS를 네임서버로 저장 → nameserver 8.8.8.8

구글 DNS 위치상관없이 가까이 있는 서울로 연결됨