oday Keys : Direct Connet, AWS, Dedicated, Hosted, Process, 절차, 회선, 개통, LOA, CFA, cloud, 클라우드



이번 포스팅은 Direct Connect를 구성하기 위한 절차에 대한 도표입니다.

보다 자세한 절차가 인터넷 상에서도 있고, 아래와 같은 절차도 AWS 세미나에서도 정리되서 공개되어 있지만, 

제 입맛에 맞춰서 살짝 조금 수정한 버전입니다. ^^;

Direct Connect를 구성하기 위한 전체적인 흐름을 보시는 데 도움이 되시길 바랍니다. 


※ 관련 포스팅 : AWS - Direct Connect : Part 2 [Hosted Connected] - Hosted Connection 구성 절차






Posted by 네떡지기

Today Keys :Endpoint, Service, 엔드포인트, 서비스, Private Link, VPC, AWS, cloud, 아마존, Amazon, NLB, ELB


이번 포스팅은 VPC Endpoint Service를 생성하고, 생성한 Endpoint Service를 Endpoint(Private link)로

생성해서 직접 사용해보는 2번째 예제입니다. 1번째에서는 NLB를 '인터넷 연결'용으로 생성하였고,

이번 포스팅에서는 '내부'용으로 생성해서 Endpoint Service를 연결합니다.

본 예제에서 다뤄지는 최종 그림은 다음과 같습니다.

 

 

※ 설명에 필요한 컴포넌트만 넣었으면, 전체 컴포넌트가 표기되진 않았습니다.

관련 포스팅 : AWS - VPC : Part 12 [Endpoint-4]

                    AWS - VPC : Part 11 [Endpoint-3] 

                    AWS - VPC : Part 9 [Endpoint-2]  

                    AWS - VPC : Part 8 [Endpoint-1]  


Endpoint Service는 Endpoint-3 포스팅에서 언급된 것처럼 앞단에 NLB(Network Load Balancer를 구성해야 합니다 .

NLB 구성은 다음과 같이 '인터넷 연결'과 '내부' 용으로 나뉘는 데,  

Endpoint-4 포스팅에서는 '인터넷 연결'로 생성한 로드밸런서로 Endpoint Service를 만들었었고

이번 Endpoint-5에서 '내부'로 생성한 로드밸런서로 Endpoint Service로 만들겠습니다.    

 

 

  '내부'용으로 ELB를 다음과 같이 생성 하였습니다.  

 

 

  ELB로 생성된 도메인을 질의해보면, 다음과 같이 사설 Subnet IP를 갖고 있는 인스턴스가 반환됩니다.  

 

  ELB를 생성하지 않은 다른 VPC의 인스턴스에서도 ELB 도메인에 대한 질의를 확인해봅니다.

 

  물론 사설이기 때문에 정상적으로 서비스가 되지는 않습니다. 

(VPC Peering을 맺는다면 또 다른 얘기겠지만... )

 

  이제 Endpoint Service를 생성합니다.

사설로 만든 ELB(NLB)를 연결합니다.

 

 

  정상적으로 Endpoint Service가 만들어진 것을 확인 할 수 있습니다.  

 

   생성된 Endpoint Service의 '서비스 이름'을 확인합니다.

 

 

  이제 Endpoint Service를 사용 할 엔드포인트를 생성합니다.

이름으로 서비스 찾기에서 방금 전에 만든 Endpoint Service의 '서비스 이름'을 입력하면 서비스를 찾을 수 있습니다.  

 

Endpoint가 정상적으로 만들어시고 상태도 '사용 가능'으로 되면, 

Endpoint의 DNS 이름을 확인합니다.  

  

 

 Endpoint의 DNS 이름을 확인해보면, 다음과 같이 Endpoint를 생성한 AZ의 서브넷 IP로 할당이 됩니다.     

 

 서비스 호출도 Endpoint(Private Link)를 통해서 이제 정상적으로 되는 것을 확인할 수 있습니다. 

 

 경로를 확인하면 바로 직접 연결된 Endpoint(Private Link)로 끝나게 됩니다. 

 

 앞서 AWS 서비스로 Endpoint를 만들 때도 확인했던 부분이지만,

Interface Endpoint 유형의 IP 주소는 Endpoint의 '서브넷' 탭을 보면 어느 AZ에 속한 것인지 확인 할 수 있습니다.  

 

 

 

 

 

 

Posted by 네떡지기

Today Keys :Endpoint, Service, 엔드포인트, 서비스, Private Link, VPC, AWS, cloud, 아마존, Amazon, NLB, ELB


이번 포스팅은 VPC Endpoint Service를 생성하고, 생성한 Endpoint Service를 Endpoint(Private link)로

생성해서 직접 사용해보는 예제입니다.

 본 에제에서 다뤄지는 최종 그림은 다음과 같습니다.

※ 설명에 필요한 컴포넌트만 넣었으면, 전체 컴포넌트가 표기되진 않았습니다.

관련 포스팅 : AWS - VPC : Part 11 [Endpoint-3] 

                    AWS - VPC : Part 9 [Endpoint-2]  

                    AWS - VPC : Part 8 [Endpoint-1]  


 

Endpoint Service는 Endpoint-3 포스팅에서 언급된 것처럼 앞단에 NLB(Network Load Balancer를 구성해야 합니다 .

NLB 구성은 다음과 같이 '인터넷 연결'과 '내부' 용으로 나뉘는 데,  

Endpoint-4 포스팅에서는 '인터넷 연결'로 생성한 로드밸런서로 Endpoint Service를 만들고

Endpoint-5에서 '내부'로 생성한 로드밸런서로 Endpoint Service를 각각 만들 것입니다.

(실제 Endpoint Service를 만드는 데는 차이는 없긴합니다.)

 

 NLB를 다음과 같이 생성해 놓았습니다.

서로 다른 AZ에 1개씩 Instance를 생성하였고, 80 서비스를 각각 올려두었습니다.

 

  구성도로 보면 다음과 같습니다.

 

   제 로컬 PC에서 ELB에 대한 도메인을 확인해보면, ELB에 할당된 인스턴스의 EIP로 응답하는 것을 볼 수 있습니다.

앞서 NLB를 생성 할 때. '인터넷 연결'용으로 만들었기 때문에 NLB 생성 시에 할당한 EIP로 응답합니다.

 

 

  AWS의  ELB를 생성한 VPC가 아닌 다른 VPC이 인스턴스에서 확인을 해도 동일하게 보입니다.  

정상적으로 서비스가 되는지 보기 위해서 curl로 확인해보니

제가 설정한 'ZIGISPACE - SVR#1'과 'ZIGISPACE - SVR#2' 라는 값이 정상적으로 보입니다.

 

  다음은 다른 VPC의 인스턴스에서 Traceroute에 대한 값입니다.

실제 통신이 IGW를 통해서 공인 IP로 통신합니다. 

 

  이제 본격적으로 Endpoint Service를 만듭니다.

NLB를 생성한 곳에서 Endpoint Service를 생성합니다.  

 

   Endpoint Service 생성 시에는 어떤 NLB로 연결할지 고르게 되어 있습니다.

앞서 만든 'ZIGI-ELB-Pub'로 선택합니다.

아래 옵션 중에 '엔드포인트 연결 수락 필수'가 기본적으로 체크되어 있습니다.

여기서는 체크되어 있다는 것만 인지하고 뒤에서 보겠습니다..

 

  서비스 생성 버튼을 누르면 다음과 같이 Endpoint Service 생성이 완료됩니다. 

 

  생성이 완료된 안내창과 생성 후 세부정보를 보면 Endpoint Service의 DNS 이름이 있습니다.

이제 이 이름으로 Endpoint를 생성 할 수 있습니다.  

 

 

  이제 Endpoint를 만들겠습니다. 

 

 

  Endpoint를 생성할 때, 예전 포스팅에서는 기본 AWS 서비스로 Endpoint를 만들었다면, 

이번에는 '이름으로 서비스 찾기'를 합니다.

그리고 서비스 이름에 앞서 만든 Endpoint Service의 DNS이름을 선택하면 해당 서비스를 찾을 수 있습니다.

Endpint를 만들 VPC와 사용 영역별로 서브넷을 지정합니다.

하나의 가용 영역에 하나의 서브넷만 지정이 가능합니다.  

 

 

'엔드포인트 생성' 버튼을 누르면 다음과 같이 Endpoint를 만들어 지는 데,

바로 사용 할 수 있는 것이 아니라, '수락 대기 중' 상태로 뜹니다.

앞서 Endpoint Service를 만들 때 '엔드포인트 연결 수락 필수'가 체크되어 있기 때문입니다.

만약 체크를 해제하면 바로 사용할 수 있지만, 그게    아니라면 이렇게 수락이 필요합니다.

 

  Endpoint Service 쪽에서 보면 '엔드포인트 연결' 탭에 수락대기 중인 Endpoint가 확인됩니다.  

      

 

  해당 Endpoint를 선택해서 요청을 수락하면, 

 

   이렇게 다시 한 번 요청을 수락할 것인지 묻는 데, 수락을 합니다.

 

 

 Endpoint가 사용이 가능한 상태로 바뀌게 됩니다.   

 

  이제 Endpoint를 만든 VPC에서 Endpoint 도메인으로 질의를 하면,

Endpoint 생성 시에 지정한 VPC의 서브넷으로 Endpoint가 만들어집니다.

 

 

Endpoint로 서비스를 호출하면 정상적으로 서비스가 호출되는 것을 확인 할 수 있습니다. 

 

  실제 Trace를 직어보면 바로 Endpoint로 만들어진 VPC 내의 서브넷을 호출하고 정상적으로 완료되는 것을 볼 수 있습니다.  

 

 

 

 

Posted by 네떡지기

Today Keys : direct, connect, dx, router, 전용선, dedicated, hosted, AWS, VPC, APN, 가상, VIF, sub, 


이번 포스팅은 AWS와 On-premise를 전용선으로 연동하는 Direct Connect 중에서 Hosted 방식의 연동 예제입니다.

본 포스팅에서는 Direct Connect 관점에서만 예제를 진행하고, 사전에 VPC 설정 등은 다루지 않습니다.


 

 

 

본 포스팅에서는 1개의 VPC(VGW)와 Sub 1G를 연동하는 Hosted Direct Connect 를 구성합니다.

최종 구성 이후의 그림과 같으며, 예제를 시작하기 전에는 Sub 1G를 제공하는 APN파트너와 전용선 개통이 완료된

상태로 가정하고 진행합니다.

Sub 1G를 사용하기 위해서 APN파트너에게 필요한 속도를 신청하면 VIF(가상인터페이스) 할당을 해줍니다.

가상 인터페이스가 할당된 상태에서 Direct Connect 메뉴에 들어가보면 [연결] 에 다음과 같이

APN파트에서 할당된 VIF 정보가 보입니다.

 

해당 연결을 선택하면 하단에 세부 정보가 표기됩니다.

현재는APN파트너에게 할당만 받은 상태이기 때문에 [pending acceptance] 입니다.

그리고 On-premise와 연동에 필요한 VLAN 정보와 포트 속도 등도 확인 할 수 있습니다.

하단의 체크 박스를 선택하고, 연결 수락을 진행합니다.

 

연결수락을 하면 상태가

[pending acceptance] 에서 [pending] 으로 변경됩니다.

 

이 상태에서 가상인터페이스(VIF) 메뉴를 가서보면 아직 가상 인터페이스가 없다고 나옵니다.

또한 가상 인터페이스를 만들 수 있는 메뉴도 없습니다.

연결을 수락한 이후에 가상 인터페이스를 생성할 수 있는 메뉴가 뜨는 데까지는 수 분이 소요됩니다.

 

연결 수락 후, 수 분이 지나면 다음과 같이 가상 인터페이스를 생성할 수 있는 메뉴가 활성화 됩니다.

 

[가상 인터페이스 생성] 메뉴를 선택하면 다음과 같이 VIF(가상 인터페이스)를 생성 할 수 있습니다.

프라이빗과 퍼블릭을 생성할 수 있습니다. 여기에서는 VPC와 연결하기 위한 private VIF를 생성합니다.

VIF를 연결하기 위해서 연결 대상을 '가상 프라이빗 게이트웨이'로 선택하고,

어떤 VPC와 연결할지, VPC에 연결된 VGW를 선택합니다.

VLAN 정보는 사전에 APN 파트너가 할당한 정보로 설정이 되어 있으며 변경되지 않습니다.

사용자 측의 BGP ASN을 지정합니다. 

사용자가 Public AS 갖고 있어서 해당 AS를 사용하거나, 임의의 사설 AS를 사용합니다.

* BGP 사설 AS(16bit) 범위 : 64.512 – 65.534

피어 IP주소와 BGP 키는 자동 생성을 할 수도 있지만,  

자동생성 체크박스를 해제하여 다음과 같이 사용자가 직접 지정 할 수도 있습니다.

 

 

 

 

모든 정보를 다 입력하고 가상 인터페이스를 생성하면 다음과 같이 생성된 가상인터페이스 정보를 확인 할 수 있습니다.

가상 인터페이스는 만든 직후에는 [ pending ] 상태이며, 잠시 후에 [ Down ] 상태로 변경됩니다.

 

 하단에 [ Peerings ] 탭을 선택하면, BGP ASN과 BGP 인증 키, 피어 IP 정보 등을 볼 수 있습니다.


AWS의 VIF 설정이 끝나면,  사용자 측 라우터(혹은 L3 스위치) 설정을 위한 설정 파일을 다운 받을 수 있습니다.

VIF(가상 인터페이스)를 선택하고 작업 메뉴에서 [라우터 구성 다운로드]를 선택합니다.

 

라우터 구성 다운로드에서는 현재 Cisco, Juniper, Palo Alto3가지 벤더의 제품을 지원하고 있습니다.

각 벤더를 선택하면 해당 벤더에서 지원하는 플랫폼(네트워크 장비 OS)과 해당 플랫폼의 버전을 있습니다. 


 

다음은 벤더별 지원하는 플랫폼 종류입니다.

실제 벤더의 모든 제품군을 지원하거나, 혹은 사용자가 갖고 있는 모든 벤더를 지원하는 것은 아니지만, 

아무 벤더의 설정을 다운받아서 사용자가 갖고 있는 벤더의 설정으로 변경해서 사용하시면 됩니다. 

 

 

 

 

 

 

다음은 Cisco Nexus 7000 시리즈의 설정을 다운받은 예시 컨피그입니다.

아래 설정을 다운 받아서 적절하게 설정을 변경해서 사용하시면 됩니다.

특히 Interface 번호나 BGP로 광고할 사용자 측이 네트워크 대역은 반드시 변경해야 합니다.

전체 설정을 모두하지 않더라도 필수적인 인터페이스 설정과 BGP 기본 설정만으로 연동이 가능합니다.

 

사용자 측 BGP 설정이 모두 끝나고 AWS의 VIF 상태를 보면 아래와 같이 BGP가 [ up ] 상태가 되는 것을 볼 수 있습니다.

BGP가 정상적으로 up으로 보이는 데 까지는 수분이 걸릴 수 있습니다. 

 

AWS VIF의 BGP가 up으로 보이기 전에 실제 사용자 장비에서 보면 BGP가 먼저 맺어진 것을 확인 할 수도 있습니다. 

실제 BGP 연동 후, AWS 대시보드에 반영되는 데까지는 좀 더 시간이 걸립니다. 

 

Posted by 네떡지기

Today Keys : VPC, endpoint, privatelink, private, link, 엔드포인트, 서비스, 게이트웨이, 인터페이스, interface,NLB


Private Link

VPC Endpoint는 게이트웨이 형식과 인터페이스 형식으로 구분 됨.

인터페이스 형식으로 구분되는 EndPoint를 Private Link라고도 합니다.

▪ VPC Endpoint 이외에 VPC Endpoint Service라는 것이 있는 데,  

  VPC Endpoint Service는 AWS 서비스가 아닌 AWS 사용자가 직접 만든 서비스를 접근하도록 하는 Private Link 임.

 

정리하면

  VPC Endpoint

     ▪ 게이트웨이 형식

     ▪ 인터페이스 형식 (Private Link) - 사용자

  VPC Endpoint Service  (Private Link) - 제공자

 

PrivateLink

▪ Private Link를 통한 AWS 일반 서비스 접근(VPC Endpoint : 인터페이스 형식)

     - 별도의 인터넷 경로없이 AWS 내부망을 통한 통신

     - Internet Gateway, NAT Gateway, Public IP 등이 필요하지 않음.

     - Direct Connect와 VPN을 통해서도 Private Link 접근 가능.

 

▪  Private Link를 통한 서비스 공유(VPC Endpoint Service)

   - 직접 만든 서비스를  VPC Endpoint Service로 만들어서 다른 AWS 사용자가 서비스에 접근 가능하도록 함.

   - 3rd party 서비스(SaaS)

   - 서비스 제공을 위해서는 NLB를 사용 필수

   ※ VPC Endpoint Service를 통해서 생성된 PrivateLink는 VPC Endpoint에서 사용

 

  


VPC Endpoint  Service 생성

   Step 1. NLB를 생성하여 서비스 연결

   Step 2. VPC EndPoint Service를 생성하면서 NLB를 연결.

 

VPC Endpoint Service 사용

   Step 1 특정 서비스 사용자(소비자)에게 Endpoint Service를 사용 할 수 있는 권한 부여

              - AWS 계정, IAM 사용자 및 IAM 역할

   Step 2 권한을 부여 받은 사용자는 Interface Endpoint 생성

   Step 3 연결을 활성화하기 위해 Interface Endpoint 연결 요청을 수락

              - Default로 수동 수락이지만, Endpoint Service 생성 시에 자동 수락으로 설정 가능.

 

Posted by 네떡지기

Today Keys : VPC, AWS, 아마존, Cloud, 클라우드, 서브넷, Subnet, 라우팅, Routing, NAT, Gateway, IGW


이번 포스팅은 예전 포스팅에서 마법사를 통해서 만들었던 VPC를 마법사를 통하지 않고

각 개별 항목 별로 생성해보는 실습 예제입니다. 

마법사를 통한 구성은 편리하지만, 직접 개별 항목으로 생성해 보는 작업을 통하면 실제 VPC의 구성이 어떻게 이뤄지는지

이해하는 데 많은 도움이 되리라 생각됩니다. 

관련 포스팅 : AWS - VPC : Part 3 [VPC 생성 및 테스트:마법사]


이번 포스팅에서 만들게 될 VPC 구성은 다음과 같습니다. 

하나의 VPC 내에 공인 서브넷과 사설 서브넷을 각각 1개씩 구성합니다.

VPC가 외부와 통신하기 위해서 Internet Gateway와 사설 서브넷이 외부와 통신하기 위한 NAT Gateway를

각각 만들고, 라우팅 테이블을 조정 합니다.

 

 

먼저 VPC를 생성합니다

VPC 생성 시에는 VPC에서 사용한 네트워크를 선언하는 데, 초기에 설정한 네트워크(CIDR)은

삭제나 변경이 불가하며, 초기 설정한 대역을 기준으로 추가 CIDR 설정도 영향을 받기 때문에 잘 설계하여 결정해야 합니다.

 

 

 

  생성된 VPC의 정보는 다음과 같이 확인 할 수 있습니다. 

 

  VPC가 만들어졌으며, 이제 VPC 내에서 사용할 서브넷을 생성합니다.

여기에서는 공인 서브넷과 사설 서브넷을 각각 1개씩 생성합니다. 서브넷에서도 네트워크 대역을 정해야 하는 데,

VPC 내의 서브넷의 네트워크 대역은 VPC의 네트워크 내에 포함되어야 합니다.  

 

  본 예제에서는 AZ는 1개로만 구성하였습니다. 

 

  생성된 서브넷 정보는 다음과 같이 확인 할 수 있습니다. 

 

  이제 외부와 통신하기 위한 Internet Gateway를 생성합니다.

 Internet Gateway를 생성 할 때는 별다른 정보없이 Name만 지정합니다. 

 

  생성된 Internet Gateway는 아직 어느 VPC에서 사용될지 결정된 상태가 아니기 때문에 상태 값이 detached 입니다.  

 

  이제 처음에 만들었던 VPC에서 사용하기 위해서 방금 만든 Internet Gateway를 VPC에 연결합니다. 

 

   VPC를 선택해서 Internet Gateway를 연결하고나면,

 

  Internet Gateway의 상태가 attached로 되고, 연결된 VPC의 정보가 뜹니다.  

 

 다음은 라우팅 테이블입니다. VPC 생성 시에 만들어진 라우팅 테이블에는 VPC의 네트워크(CIDR)이 Local로 되어 있으며,

추가적인 라우팅이 없습니다. (Local이기 때문에 VPC 내에서 설정한 서브넷 간에는 통신이 가능합니다.)

 

 

 인터넷을 나가기 위해서 라우팅 테이블의 Default Route(0.0.0.0/0)의 Target(Next Hop)을 앞에서 만들었던

Internet Gateway로 지정합니다.

 

다음은 Elastic IP를 생성합니다.

 

Elastic IP는 바로 할당 버튼을 누르면 별다른 정보 입력없이 다음과 같이 바로 할당이 됩니다.

 

Elastic IP를 만든 것은 사설 서브넷이 인터넷과 통신하기 위한 NAT Gateway를 만들기 위한 것이었습니다.

사설 서브넷이 인터넷과 통신하기 위해서 만들지만, NAT Gateway를 생성할 때 설정하는 서브넷은

사설 서브넷이 아니라, 공인 서브넷으로 설정하고, 방금 전에 할당받은 Elastic IP를 연결합니다.

 

 

실제  서브넷 정보를 보면 공인 서브넷으로 생성한 '~cefe1' 로 끝나는 ID임을 확인할 수 있습니다.

 

이제 사설 서브넷을 위한 라우팅 테이블을 추가로 만듭니다.

서브넷 별로 라우팅 테이블을 적용 할 수 있습니다.

 

라우팅 테이블 생성하고  라우팅 정보를 수정합니다.

사설 서브넷을 위한 라우팅 테이블이기 때문에 Default Route에 대한 Target(Next hop)을 NAT Gateway로 합니다.

 

이제 초기에 만든 사설 서브넷의 기본 라우팅 테이블을을 확인해서

 

 방금 전에 만든 사설 서브넷용 라우팅 테이블로 변경합니다.

서브넷에 대한 라우팅 테이블을 변경하면 해당 라우팅 테이블의 정보를 볼 수 있습니다.

 여기까지하면, VPC 마법사를 통해서 만든 VPC 구성을 직접 만드는 작업이 끝나게 됩니다.

이제 실제 EC2를 생성해서 여기서 만든 공인 서브넷과 사설 서브넷으로 할당해서 각각 외부와 통신이 되는지

사설 서브넷의 EC2의 경우 공인 IP 주소가 NAT Gateway에 할당된 Elastic IP로 보이는지 확인하면 됩니다.

 

앞서 얘기 했듯이 AWS에서 제공되는 VPC를 생성하는 마법사를 이용하면 좀 더 쉽고 빠르게

VPC를 구성 할 수 있지만, 직접 만드는 작업을 통해서 실제 VPC 구성에 대한 이해를 도울 수 있을 것 입니다.

 

그리고 이렇게 만들어진 VPC는 최소한의 통신을 위한 기본 구성이기 때문에 VPC 설계를 위한 다른 컴포넌트들은

추가로 적절하게 생성하여 연결해야 합니다.

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, services, cloud, 아마존, public


이번 포스팅은 지난 포스팅에 이어서 VPC Endpoint에 대해서 알아봅니다.

VPC Endpoint 중에서 Interface 타입의 Endpoint를 생성해서 어떻게 Endpoint를 이용해서

서비스를 접근 할 수 있는지를 알아 볼 수 있는 간단한 예제 포스팅입니다.

* 관련 포스팅 : VPC Endpoint 알아보기

                        Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 


이번 포스팅에서는 Interface 타입의 Endpoint인 CloudFormation을 생성해 보겠습니다.

먼저 Endpoint를 생성하기 위해서 '엔드포인트 생성' 메뉴를 선택하여 Endpoint를 만드는 메뉴로 들어갑니다.

 

EndPoint를 만들 때에는 서비스 유형에 따라서 Interface로 만들지 Gateway로 만들지 다음과 같이 나옵니다.

각 서비스 별로 유형이 정해져 있는 것이며, 서비스를 Interface 혹은 Gateway 유형을 선택하는 것은 아닙니다.

 

Endpoint 생성의 전체 메뉴는 다음과 같습니다.

서비스를 고르고, 어느 VPC에 적용할지를 선택하면 해당 VPC의 AZ 정보가 나오고

각 AZ 별로 어떤 Subnet에 생성할지 나옵니다.

그리고 'Private DNS 이름 활성화' 라는 메뉴가 기본적으로 체크되어 있습니다.

이 부분은 아래에서 다시 설명합니다.

보안 그룹은 우선 기본으로 설정합니다.

 

여기까지하면, 손쉽게 Endpoint를 만들 수 있습니다.

 

생성이후, '사용가능' 상태로는 약 1~2분정도 소요 될 수 있습니다.

정상적으로 생성되면 다음과 같이 생성된 Endpoint 정보를 확인 할 수 있습니다.

 

하단의 서브넷 탭을 보면 실제 생성 시에 선택한 AZ 별로 서브넷에 속하는 IP 주소를 갖고 있는 것을 확인 할 수 있습니다.

 

Endpoint를 생성하기 전에는 해당 VPC 내에서 CloudFormation 서비스에 대한 URL을 확인하면

AWS의 리전 내의 공인 IP 주소를 받아오는 것을 확인 할 수 있습니다.

 

하지만, Endpoint 생성 이후에 동일한 URL에 대한 질의를 하면 Endpoint가 갖고 있는 IP 주소를

도메인에 질의에 대한 결과로 받게 되는 것을 확인 할 수 있습니다.

앞에서  'Private DNS 이름 활성화' 을 뒤에서 알아보겠다고 하였는 데, Endpoint 생성 시에

'Private DNS 이름 활성화' 옵션을 활성화하면(default 값이 활성화) 서비스 별 기본 도메인 값을 VPC 내의 Private DNS에

자동으로 등록이 되어서 해당 값을 응답 받을 수 있게 됩니다.

일반 URL이 아닌 별도 URL을 사용하여 접근하고자 할 경우에는 해당 옵션에 대한 체크를 해제하고

별도 도메인으로 Endpoint IP 주소를 관리 할 수도 있습니다.

 

 

Posted by 네떡지기

Today Keys : VPC, AWS, Endpoint, Gateway, Interface, Private, links, services, cloud, 아마존, public


 

 이번 포스팅은 VPC 네트워크에서 AWS 서비스를 AWS 네트워크를 통해서 직접 접근하기 위한 Endpoint에 대해서 알아보는 포스팅입니다. Endpoint는 접근하는 서비스에 따라서 Gateway와 Interface 타입으로 나뉩니다. 이번 포스팅에서는 Endpoint에 대한 간략한 소개를 하고, 다음 포스팅에서는 Endpoint를 생성해서 접근하는 방법에 대해서 알아 볼 예정입니다.

* 관련 포스팅 : Gateway Endpoint 만들어보기 - 포스팅 준비 중
                       
 Interface Endpoint 만들어보기


 VPC Endpoints

Endpoints

  ▪ VPC 네트워크 내에서 VPC 외부에 위치한 Public한 서비스를 IGW를 거치지 않고 VPC내부에서 직접 접근하도록 지원
  ▪ VPC의 내부의 인스턴스가 AWS 서비스와 통신하기 위해 공인 IP를 가지지 않아도 됨.
  ▪ Endpoint는 Gateway 타입 Interface 타입 으로 구분
  ▪ Endpoint는 VPC에서 접근하고자 하는 AWS Public 서비스 별로 개별 생성하며, Gateway타입 지원하는 서비스와
    인터페이스 타입을 지원하는 서비스가 나누어져 있음. 
       - 타입 별 지원 서비시는 아래에 참고
  ▪ VPC와 AWS 서비스 사이의 트래픽이 AWS 네트워크에서 처리하며, IAM 정책을 사용하여 액세스 제어 가능.


Gateway Endpoint 
  ▪ Endpoint가 Gateway 타입으로 지원하여 AWS 서비스 접근 시, 라우팅으로 접근
  ▪ 라우팅 테이블에서 S3나 DynamoDB의 목적지 네트워크에 대한 Target(Next Hop)으로 Gateway Endpoint를 지정
  ▪ S3와 DynamoDB 접근을 지원


Interface Endpoint
  ▪ Endpoint가 AZ 내의 Elastic Network Interface(ENI)로 생성하고, 해당 서비스에 대한 도메인 Lookup을 해당 ENI 응답
  ▪ Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM), Elastic Load Balancing(ELB) API 등을 지원
  ▪ Interface Endpoint 생성 시에는 어느 VPC의 어떤 AZ의 어떤 Subnet을 사용할지 선택
  ▪ Interface Endpoint 는 생성 시에 지정한
 각 서브넷의 IP를 각각 할당 받음.
  ▪ Interface Endpoint 를 이용해서 서비스를 호출하는 경우에는, AWS에서 기본으로 사용하는 도메인을 사용하거나, 
    별도의 서비스 도메인을 지정하여 VPC 내에서 서비스 도메인 Lookup 시에  Interface Endpoint 의  IP로 응답하여
    접근하도록 할 수 있음.
  ▪ 기존에 AWS Public 서비스를 사용하도록 어플리케이션이 만들어진 경우에 기본 도메인으로 Interface Endpoint 
   사용하게 되면  어플리케이션에서 AWS 서비스 호출 시에 별도의 변경 과정없이 Endpoint를 이용한 서비시 호출이 가능.

  

Endpoint 타입별 지원 서비스
  ▪ Gateway
    - Amazon S3
    - DynamoDB
 
  ▪ Interface
    - Amazon API Gateway
    - AWS CloudFormation
    - Amazon CloudWatch
    - Amazon CloudWatch Events
    - Amazon CloudWatch Logs
    - AWS CodeBuild
    - AWS Config
    - Amazon EC2 API
    - Elastic Load Balancing API
    - AWS Key Management Service
    - Amazon Kinesis Data Streams
    - Amazon SageMaker and Amazon SageMaker Runtime
    - Amazon SageMaker Notebook Instance
    - AWS Secrets Manager
    - AWS Security Token Service
    - AWS Service Catalog
    - Amazon SNS
    - AWS Systems Manager
    - Endpoint services hosted by other AWS accounts
    - Supported AWS Marketplace partner services

 

 

 

 

 

Posted by 네떡지기

Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke


Last Updated : 18.12.14


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 소개 포스팅에 이어서,

Transit Gateway를 직접 만들어서 테스트해보는 포스팅입니다.

※ 관련 포스팅 : Transit Gateway 소개 포스팅 보기


오늘 포스팅에서 구성하는 Transit Gateway에 대한 구성입니다.

2개의 VPC를 구성하고, 2개의 VPC 모두 하나의 AZ에 속합니다.

VPC-1에는 1개의 Subnet이 VPC-2에는 2개의 Subnet이 있으며, Transit Gateway에는 VPC-1과 VPC-2의

각 하나의 Subnet과 연결되어 있습니다.

 

 

그럼 이제 Transit Gateway를 생성하고 사용하는 과정을 알아 보겠습니다.

먼저 Transit Gateway를 만들어 보려고 합니다.

앞서 소개 포스팅에서 얘기했지만, 서울 Region에는 Transit Gateway를 만들 수 있는 메뉴가 없습니다.

18.12.06 기준 

18.12.14 기준 - 서울 Region에서도 Transit Gateways 사용 가능

 

미국으로 Region을 변경해서 보면, Transit Gateways 메뉴가 보이는 것을 확인할 수 있습니다.

저는 오하이오 Region에서 Transit Gateways를 만들어서 테스트를 진행합니다.

 

현재  생성한 Transit Gateway가 없기 때문에 해당 메뉴에서 [Create Transit Gateway ] 를 선택합니다.

 

다음과 같이 간단한 Name Tag와 옵션들을 선택하고, 바로 생성 가능합니다.

 

생성이 완료되면 다음과 같이 완료 메시지를 확인 할 수 있습니다.

 

완료 메시지 이후에 정상적으로 만들어지기 까지는 수 분이 소요됩니다.

초기에는 다음과 같이 pending 상태가 됩니다.

 

잠시 이후에 State가 available 상태로 되면서 Transit Gateway를 사용 할 수 있습니다.

 

 

Transit Gateway를 생성한 이후에는 연동하고자 하는 정보를 Attatch 해주어야 합니다.

Transit Gateway Attachment 메뉴를 선택해서 들어가면 다음과 같이 Transit Gateway ID에서

방금 전에 생성한 Transit Gateway를 선택 할 수 있습니다.

 

Transit Gateway를 선택하고, 어떤 type으로 attach할 것인지 정하게 되는 데

현재는 VPC와 VPN만 지원하고 있습니다.

Direct Connect 연결은 2019년 초에 지원된다고 합니다.

여기서 유의해서 볼 것은 VPC 연결 시에 특정 VPC 내에서 연결 할 서브넷을 지정할 수 있는 데,

VPC를 만들어 놓은 Region의 AZ 별로 Subnet을 선택 할 수 있습니다.

하나의 AZ에서 Subnet은 드랍박스 형태로 메뉴가 되어 있어서 1개 밖에 선택이 안됩니다. (1개만 가능)

정상적으로 VPC의 Subnet을 Attach하고 나면 다음과 같이 Attach된 내용이 보입니다.

 

동일하게 VPC-2의 서브넷에서도 동일한 과정을 진행하며, Transit Gateway 생성 및 연결이 됩니다.

하지만, 이 상태에서 10.1.1.0/24 Subnet과 10.2.1.0/24의 Subnet이 통신되지는 않습니다.

각각의 Subnet의 라우팅을 추가로 잡아야 합니다.

10.1.1.0/24이 속한 라우팅 테이블에 대해서는 Target(Next hop)을 앞서 만든 Transit Gateway를 선택합니다.

라우팅 테이블 추가 메뉴를 보면 Target 항목에 Transit Gateway를 선택 할 수 있습니다.

양 쪽 서브넷에서 라우팅을 모두 잡고 나면, 이제 정상적으로 두 VPC의 서브넷 간의 통신이 가능합니다.

다만, 라우팅을 10.1.1.0/24이 속한 라우팅 테이블에서 목적지 네트워크를 VPC-2의 CIDR로 설정한 10.2.0.0/16으로

하고 Target을 Transit Gateway로 잡더라도 Subnet 2의 10.2.2.0/24 으로는 통신이 되지 않습니다.

앞선 포스팅과 이번 포스팅 앞에서도 얘기했듯이 1개의 VPC의 1개의 AZ에서는 1개의 서브넷만 연동이 됩니다.

따라서 전체적인 설계를 할 때 이 점을 유의해서 설계해야 할 것입니다.

Posted by 네떡지기

Today Keys : Transit, Gateway, AWS, VPC, 트랜짓, peer, 네트워크, 아마존, TGW, Hub, Spoke

 


Last Updated : 18.12.14 

    - 서울 Region에서 사용 가능.


이번 포스팅은 AWS re.Invent 2018에서 소개되었던, Transit Gateway에 대한 간단한 포스팅입니다.

기존에 제공하지 않던 VPC 간의 Transit을 가능하도록 제공하는 기능입니다.

Transit를 허용하여 기존에 디자인 하던 방식을 좀 더 관리하기 편하도록 제공할 것입니다.

실제 Transit Gateway를 구성해서 테스트해보는 포스팅은 다음 포스팅을 확인하시면 됩니다.

※ 관련 포스팅 : VPC Transit Gateway 테스트 포스팅-1

 


 

AWS Transit Gateway (TGW)

Transit Gateway
  ▪ VPC 간의 Transit이 가능하도록 해주는 게이트웨이 서비스
      - 기존에 제공하지 않던 VPC 간의 Trasit이 가능하도록 제공
  ▪ Hub & Spoke 방식으로 Transit Gateway가 다른 VPC들의 Hub가 되어VPC 간을 통신 연계 가능
  ▪ Hub & Spoke 방식으로 연결되기 때문에 각 VPC는 직접 연결하지 않고 Transit Gateway만 연결하여 관리 및 확장 용이
  ▪ Resource Manager를 통해서 Transit Gateway를 타 계정에 공유해서 타 계정의 VPC와도 연동이 가능.
      - Resource Manager를 통해서 관리가 가능한 Resource 유형 중의 하나로 Transit Gateway를 사용
  ▪ On-premise에서 Transit Gateway로의 접근은 현재 VPN 방식만 지원하며, Direct Connect 기능은 2019년초 제공 예정
  ▪ 현재 서울 Region에서는 Transit Gateway 사용 가능.

 

 < VPN을 이용하여 On-Premise와 VPC 간을 Transit Gateway로 구성한 예 >


Transit Gateway 특징
  ▪ VPN ECMP 지원
  ▪ 연결당 최대 50Gbps 트래픽 처리 가능
  ▪ 각 게이트웨마다 최대 5000개의 VPC 연결 
  ▪ 1개의 VPC에서는 1개의 AZ에 1개의 Subnet만 Transit Gateway에 연결 가능 
      - 동일 AZ 내에서 추가 Subnet을 Transit Gateway에 Attatch 시도 시에 오류발생

 

  < 동일 VPC의 동일 AZ에 Subnet 추가 연동 시에 에러 >

   

 

 < VPC, AZ, Subnet을 고려한 Transit Gateway 연동 예 >

 

 

Posted by 네떡지기

티스토리 툴바