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 네떡지기

Today Key :  AWS, VPC, Cloud, Network, Peering, region, 접속, 피어링


 이번 포스팅은 VPC 간의 연동을 해주는 VPC Peering에 대한 정리입니다.

 실제 VPC Peering을 연동하는 예제는 포스팅용으로 이미지를 정리해야해서.. 다음 포스팅에서 다뤄집니다. ^^

 혹시 수정이 필요한 내용이나, 보완해야 될 내용이 있으면 덧글로 남겨주세요! 



VPC Peering 

 · VPC 간의 인터넷을 통하지 않고 직접 통신 할 수 있도록 연결하는 기술

 · AWS 내에서 정의하는 정의하는 가상의 네트워크인 VPC는 논리적으로 독립적인 네트워크 망을 선언한 것이기 때문에

   기본적으로 VPC 간에는 서로 통신이 불가하여 VPC 간에 서로 영향을 미치지 않음.

 · VPC 간에 서로 통신을 하기 위해서는 VPC 내에서 인터넷을 통해서 다른 VPC로의 통신을 하는 구조였음.

 · 2014년에 VPC Peering 이라는 기술을 통해서 같은 리전 간의 VPC 네트워크를 서로 연결 할 수 있게 됨.

 · 2017년에 멀리 Region 간의 VPC Peering을 지원하도록 함.

 · 서울 Region에서의 VPC Peering은 2018년 중반부터 지원

 

 

VPC Peering 구성

 · 동일 Region 간의 Peering 예

 

 

  · 멀리 Region 간의 Peering 예

 

 

   · 공유 서비스를 이용하는 VPC Peering 예

 

 

VPC Peering 구성 관련

 · VPC Peering으로 연결 시에 VPC 간의 네트워크 대역이 겹치지 않도록 설계해야 함.

  · VPC Peering을 이용하면 Peering 된 VPC 네트워크은 AWS 백본을 통해서 통신하여 Pulbic 인터넷 망을 통과하지

   않기 때문에   보안적으로 보다 우수함.

   또한 내부 백본 네트워크를 통하기 때문에 이중화나 네트워크 병목에 대한 이슈도 없음.

 · VPC Peering은 단일 계정으로도 가능하며, 서로 다른 계정 간의 VPC Peering 구성도 가능

 

 VPC Peering 제한

· 멀티 Region 간의 VPC Peering 시에는 security group 참조 지원 안 함.

· 멀티 Region 간의 VPC Peering 시에는 DNS resolution 지원 안 함.

· IPv6와 Jumbo 프레임 지원 안 함.

·  VPC Peering을 통해서 외부 혹은 다른 VPC에서 VPC를 통해서 또 다른 VPC로 접근하는 Transit 기능은 지원하지 않음.

 

 

 

 

Posted by 네떡지기

Today Keys : VPC, 마법사, 생성, subnet, 게이트웨이, IGW, 라우팅테이블, Route tables, EIP, Elastic, Create



기존 포스팅 : AWS - VPC : Part 1  , AWS - VPC : Part 2


Last Updated : 2018.11.30

이번 포스팅에서는 AWS VPC를 마법사를 통해서 생성하여 간단하게 VPC와 관련된 컴포넌트를 구성하고, 

통신 테스트를 진행합니다.


 

먼저 VPC 대시보드로 들어가면, VPC에서 사용하는 다양한 컴포넌트가 있습니다.

'상단에 VPC 만들기'라는 파란 버튼을 클릭하면,

 

 

다음과 같이 VPC를 손쉽게 구성할 수 있도록 마법사 형태로 제공합니다.

VPC 구성 형태에 따라서 4가지 방식을 제공하는 데,

1. 단일 퍼블릭 서브넷이 있는 VPC

2. 퍼블릭 및 프라이빗 서브넷이 있는 VPC

3. 퍼블릭 및 프라이빗 서브넷이 있고 하드웨어 VPN 액세스를 제공하는 VPC

4. 프라이빗 서브넷만 있꼬 하드웨어 VPN 액세스를 제공하는 VPC

 

이 포스팅에서는 AWS에서 일반 인터넷과의 통신만 하는 간단한 네트워크 구조를 만들기 떄문에 별도의 VPN 액세스 제공하는 3,4번 대신에 1,2번 중의 Private과 Public이 함께 있는 2번째 마법사를 선택해서 진행합니다.

 

우선 마법사를 본격적으로 진행하기 전에 탄력적 IP(Elastic IP:EIP)를 먼저 생성합니다.

마법사로 Private 서브넷을 생성하게 될 경우에 NAT 게이트웨이도 함께 생성하는 데, NAT 게이트웨이에 할당 할 EIP가 필요합니다.

 

 

새 주소 할당에서 바로 '할당'을 클릭하면

다음과 같이 새로운 Elastic IP 주소가 생성됩니다.

 

이제 VPC 마법사를 이용해서 VPC 생성에 필요한 값을 입력합니다.

VPC 내에서 사용할 CIDR 블록을 먼저 지정합니다.

VPC 의 CIDR은 생성 이후 변경이 불가하기 때문에 VPC를 얼마나 확장성 있게 설계할 것인지에 따라서 크기를 잡아야 합니다.

다음은 Public과 Private 서브넷에 대한 CIDR을 지정하는 데, 여기서 사용되는 CIDR은 VPC CIDR 블록 내에 속해야 합니다.

예제에서는 Public 은 10.0.0.0/24, Private는 10.0.4.0/24로 선언합니다.

서브넷 생성 시에는 어떤 가용영역(AZ)에 속할지도 함께 선택합니다.

마법사 이용 시에는 각각 1개의 서브넷을 생성하지만, VPC 생성이 완료된 이후에 추가로 생성이 가능합니다.

서브넷 다음에는 Private 서브넷이 외부와 통신하기 위한 NAT 게이트웨이의 Elastic IP를 선택하는 데, 앞에서 만든 EIP를 지정합니다.

필요한 정보를 입력한 이후에 생성 버튼을 누르면, 몇 분 이내에 생성이 완료됩니다.

 

VPC 생성이 끝나면 다음과 같이 정상적으로 생성되었다고 나옵니다.

 

마법사를 이용해서 VPC를 생성하고 나면, VPC의 다양한 컴포넌트들이 생긴 것을 알 수 있습니다.

왼쪽은 기본 VPC 상태였고, 오른쪽이 VPC 마법사를 이용해서 VPC를 만든 이후의 컴포넌트입니다.

'서브넷 2개(Public/Private), 라우팅 테이블 2개, 인터넷 게이트웨이 1개, NAT 게이트웨이 1개, 네트워크 ACL 1개, 보안그룹 1개 '

가 추가로 생성된 것을 확인할 수 있습니다.

 

이제 새롭게 만든 VPC와 서브넷을 이용해서 EC2를 만듭니다.

EC2 생성 시에 Default VPC 대신에 새롭게 만든 Public/Private 서브넷을 가진 EC2를 생성합니다.

Public 서브넷을 가진 EC2를 생성할 때 Public IP를 자동할당 받을 수 있도록 설정합니다.

 

Private 서브넷을 가진 EC2를 생성할 때는 Public IP를 받을 필요가 없으며, 실제 생성하더라도 해당 IP로 접속이 불가합니다.
(물론 설정을 변경하면 가능하나, 설정을 변경하는 경우에는 실제 Private 서브넷이 아니라 Public 서브넷으로 동작합니다.)

 

Public 서브넷을 가진 EC2가 자동으로 할당받은 IP는 13.124.63.40 입니다.

13.124.63.40으로 EC2에 접속해서 IP 주소를 확인해보면, 10.0.0.247인 것을 확인할 수 있습니다.

앞서 Public 서브넷을 10.0.0.0/24으로 선언하였고, 해당 네트워크 대역에 속하는 인스턴스입니다.

 

Private 서브넷에 속한 EC2의 경우에는 직접 접근이 불가능하지만, Public 서브넷을 통해서 접근이 가능합니다.

VPC의 CIDR에 속한 모든 인스턴스는 상호 간의 모두 별도의 설정없이 통신이 가능합니다.

(라우팅 테이블에서 VPC의 CIDR이 Local 영역으로 설정)

Private 서브넷의 EC2도 외부(8.8.8.8)와 통신이 가능합니다.

왜냐면 Private 서브넷이 외부와 통신할 수 있도록 NAT 게이트웨이가 있기 때문입니다.

실제 확인을 위해서 자신의 공인 IP 확인을 위해서 ifconfig.me를 통해서 Private 서브넷 EC2의 공인 IP를 확인합니다.

 

ifconfig.me를 통해 확인한 공인 IP가 실제로 NAT 게이트웨이에 할당된 Elastic IP 주소인 13.125.4.205인 것을 확인할 수 있습니다.

 

마지막으로 Public과 Private 서브넷에 지정된 2개의 라우팅 테이블을 확인합니다.

Private 서브넷이 포함된 라우팅 테이블은 VPC CIDR이 Local로 선언되어 있고, Default 라우팅은 NAT 게이트웨이를 향합니다.

 

 

Public 서브넷이 포함된 라우팅 테이블은 Private 서브넷이 포함된 라우팅 테이블과 마찬가지로 VPC CIDR이 Local로 선언되어 있지만,

디폴트라우팅은 인터넷 게이트웨이(IGW)인 것을 확인 할 수 있습니다.

이상으로 VPC 마법사를 이용한 기본 VPC 생성 및 VPC를 이용한 인스턴스를 만들어서 통신하는 과정을 보았습니다.

이후에는 마법사 대신에 개별 컴포넌트 별로 생성하면서 어떻게 연결이 되는지 알아보도록 하겠습니다.

 

다음은 본 예제에 대한 구성입니다.



Posted by 네떡지기

Today Keys : AWS, VPC, Route, Table, IGW, Internet, Gateway, EIP, Elastic, IP address, NAT, 네트워크, 아마존



AWS VPC 대시보드를 보면 다음과 같이 VPC에서 사용되는 다양한 컴포넌트가 있습니다.

이번 포스팅에서는 VPC의 다양한 컴포넌트 중에서 라우팅 테이블과 인터넷 게이트웨이, 탄력적 IP, NAT 게이트웨이에 대해서 알아보겠습니다.

Last Updated : 2018.11.30 



 

라우팅 테이블(Route Tables)

 · 특정 네트워크 대역에 대해서 어떤 경로를 통해서 갈지에 대한 테이블 

 · 목적지 네트워크 대역을  '도착(Destination)'으로 표기하고, 목적지로 가기 위한 Next Hop을  '대상(Target)'이라고 나타냄

 · 라우팅 테이블은 서브넷 별로 적용 되기 때문에, 하나의 서브넷은 하나의 라우팅 테이블에만 속함.

 · 서브넷은 하나의 라우팅 테이블에 속하지만, 하나의 라우팅 테이블에는 다수의 서브넷이 속할 수 있음.

 · 라우팅 선언 시에 하나의 목적지 네트워크(Destination)에 대한 라우팅은 1개만 선언 가능하기 때문에 라우팅 테이블 선언으로 백업 경로 지정 불가

 · VPC의 CIDR로 선언한 네트워크 대역은 'Local'로 인식

 

 ·

 

인터넷 게이트웨이(IGW : Internet Gateways)

 · VPC 내부에 존재하는 인스턴스가 외부로 나가기 위한 관문

 · 공인 서브넷이 되기 위해서는 라우팅 테이블에서 Next-hop(Target)이 인터넷 게이트웨이(IGW)인 경우 임.

 · 사설 서브넷 인스턴스의 경우에도 외부와 통신하기 위해서는 NAT 게이트웨이를 통한 이후에 다시 인터넷 게이트웨이를 경유하는 데, 
   NAT 게이트웨이 자체가 공인 서브넷에 존재하기 때문에 결국 공인 서브넷의 라우팅 테이블을 적용 받아서 IGW를 지나기 때문.

 ·

 

탄력적 IP(Elastic IPs)

 · AWS 내에서 할당되는 Static한 공인 IP

 · EIP 생성 시점에는 Public EIP만 할당이 되지만, 해당 EIP를 바인딩하게 되면, 사설 IP와 1:1로  매핑 됨.

 

 

NAT 게이트웨이(NAT Gateways)

 · 사설 IP를 가진 인스턴스가 별도의 공인 IP를 할당받지 않은 상태에서 외부와 통신하기 위해서 사용하는 NAT 컴포넌트

 · NAT 게이트웨이에는 NAT를 Public 서브넷과 실제 NAT되는 EIP를 할당.

 · 특정 서브넷에 대한 NAT 기능을 수행하도록 사설 서브넷과 공인 IP가 매핑된 형태의 컴포넌트로 볼 수 있음.

 · 라우팅 테이블의 Next Hop을 NAT 게이트웨이로 지정하게 되면, NAT 동작을 수행.

 · 최대 1G 대역폭 지원




Posted by 네떡지기

 

Today Key :  AWS, VPC, Cloud, Network, region, subnet, CIDR, AZ


 Last Updated : 18.11.28



AWS VPC

 · AWS 내에서 정의하는 가상의 네트워크 환경 (논리적인 네트워크 구성)

 · 사내망(On-Promise)과 VPN이나 Direct Connect와 같은 서비스를 이용하여 연결 가능

 · VPC 내에는 Public 서브넷과 Private 서브넷을 구성 할 수 있음.

 

 

VPC 특징

 · VPC는 하나의 region 속함.

 · Region 내의 AZ 간에는 VPC를 같이 사용 가능.

 · 네트워크 주소와 라우팅을 직접 설정

 · 복수의 region 사용 시에는 네트워크 주소 설계 고려

 · VPC 생성 시 VPC에 속하는 하나의 CIDR을 생성

       - 최대 네트워크 : 16bit /  최소 네트워크 : 28bit

 · VPC 내에서 사용 할 서브넷은 추가로 설정해야 하고

  서브넷은 VPCCIDR 내에 속해야 하기 때문에 서브넷 크기를 고려하여 CIDR 크기를 결정해야 함.

 · VPC 생성 시에 만든 CIDR 은 변경이 불가능하기 때문에 초기 생성 시에 향후 만들어질 설계 방안을 고려해서 CIDR을 디자인해야 함. 

 · VPCCIDR 생성 시에는 사설 IP 대역을 사용 할 것을 권장

       - 10.0.0.0/8 , 172.16.0.0/12, 192.168.0.0/16

 · VPCCIDR은 생성 이후 변경이 불가하기 때문에 Region, On-Premise과의 연동을 고려하여 IP 중복이 되지 않도록 설계 필요.

 · VPC의 CIDR에서의 IP 중복은 On-Premise 뿐 아니라, 나중에 다뤄질 VPC 간의 연결을 하는 VPC Peering도 고려하여 
   각 VPC 간의 네트워크 대역도 중복되지 않도록 설계해야 함.

 · VPC 생성 시 입력이 필요한 항목

       - Name tag

       - CIDR block  : VPC에서 사용 할 네트워크 대역 선언

       - Tenancy  : 전용 물리 하드웨어를 사용 할 것인지에 대한 옵션

 · VPC 네트워크는 기본 설정으로는 폐쇄망 구성이기 때문에 외부와 통신 불가

 · VPC가 외부 네트워크와 통신하기 위해서는 Internet-Gateways가 필요

 · 하나의 VPC 내에 속한 서브넷은 Local Router를 통해서 서로 통신이 가능.

 

 

서브넷 특징

 · 하나의 VPC 내의 하나의 AZ에 속함 (AZ 간에는 서브넷이 다름)

 · 서브넷 생성 시 입력이 필요한 항목

      - Name tag

      - VPC

      - Availability Zone

      - CIDR block

 · VPC에 속하는 네트워크(CIDR)로 설정해야 하며, 해당 네트워크를 벗어나면  오류 발생(생성 불가)

 · 서브넷 설 정 시에 1~3번은 다음과 같은 목적으로 사용되기 때문에 사용 불가(네트워크 주소 및 브로드캐스트 주소 제외)

      - 1 : VPC 라우터용

      - 2 : AWS에서 예약한 DNS 주소

      - 3 : AWS에서 예약(향후 사용)

 

 

 

 


Posted by 네떡지기
DevOps/Programmability2018.02.07 08:02

안녕하세요.

이번 포스팅은 Programmability for Networker의 25번째 포스팅입니다.

ACI Cobra를 이용하여 Port Channel 혹은 vPC Profile을 만들어주는 코드에 대해서 공유합니다.

세부적인 코드 설명은 포함되어 있지는 않지만, 현업에서 아래의 코드를 사용한다면

보다 쉽고, 빠르게 Profile을 만드실 수 있을겁니다.

이번 코드는  운영 중인 커뮤니티에서 진행된  '제 22회 네트워크 전문가 따라잡기 'N.EX.T''에서 발표하였던 코드이기도 합니다.

(정리해서 올리기로 하고.. 1년 가까이가 지났네요. ^^)

 

물론 포스팅 설명에 앞서서 한가지 미리 얘기를 드리면,

'왜 Port Channel이나 vPC Profile을 대량을 으로 만들어야 하지?' 라고 생각하실 수 있습니다.

ACI에 대한 포스팅을 준비만 하면서 계속하지 못하고 있어서 다루지 못한 부분이기는 하지만..

이 부분은 ACI를 어떻게 설계해서 사용하느냐에 따라서 많아질 수도.. 혹은 적어질 수도 있을 것이라고 생각합니다.

(물론 개인적인 생각은 최적화 된 Profile로 설계해서 사용한다면 그리 많지 않은 Profile로 모두 수용이 가능합니다.)

 

그럼 이제 본 내용을 시작합니다.

 


 

ACI에서 기본적으로 제공되는 APIC GUI에서 Click! Click을 이용해서 설정하는 방법 이외에

 

일괄적으로 대량을 설정을 하기 위해서는

JSON이나, XML 포맷의 파일을 미리 만들어 POST 하여 설정을 하거나,

ACI에서 제공되는 API를 이용해서 코드로 설정하는 방법이 있을 것입니다.  (CLI를 제외하고..)

 

하지만, 오늘 다룰 내용인 Interface Policies 항목에서는 POST를 할 수 있는 메뉴가 없습니다.

최상단의 Interface Policies에도 없고요.

 

 

 

 

 

 

하단의 Policy Groups에도 없습니다.

 

 

 

물론 그 하단인 Leaf Policy Groups에도 없습니다.

 

 

그래서 PC Profile이나 vPC Profile을 생성하기 위해서 ACI SDK인 Cobra를 이용하여 Port Channel이나 vPC Profile을 만들려고 합니다.

 

다음은 Port Channel이나 vPC Profile을 만드는 코드입니다.

 

 

위의 코드 이외에 Port Channel 혹은 vPC Profile의 이름이 선언된 info.txt라는 파일이 있어야 합니다.

info.txt에는 단순히 Profile에 사용할 이름만 한 줄씩 나열합니다.

 

그러면 info 파일에서 한 줄씩 읽어서 해당 이름으로 Profile을 생성하게 됩니다.

코드 본문에 있는 AEP 변수에서 사용하실 AEP 이름을 수정하시고

Port Channel을 사용할지, vPC를 사용할지에 따라서 AccBndlGrp 메서드 호출 시에 lagT에 대해서

 

Port Channel은 'link'로 설정하시고, vPC의 경우에는 'node'로 설정하시면 됩니다.

 

위의 코드에서는 Link Level Policy, Port Channel Policy, Attach Entity Profile에 대한 속성만 설정하였지만,

기타 그 밖의 설정을 추가할 수도 있습니다.

 

혹시라도 대량으로 PC, vPC Profile을 설정하셔야 하는 경우에 이 코드를 사용하시면 조금은 쉽게 설정이 가능하실 겁니다.

물론 자동화의 장점은 설정에 대한 편의성도 있지만, 잘못된 설정으로 인한 휴먼에러의 방지도 가능할 것입니다.

 

참고로, 위의 코드에서는 설정 시의 기본 예외처리만 만들었으며

기타 다른 상황에 대한 세부 예외 처리가 되어 있지 않기 때문에 더 보완해서 사용해보시는 것도 좋을 것 같습니다.

 

 

Posted by 네떡지기
분류없음2017.07.09 19:31

Today Keys : profile, switch, policies, 설정, template, aci, cisco, vpc


Cisco ACI에 대한 두 번째 포스팅입니다. 

이번 포스팅은 지난 포스팅(Interface Policies)에 연장선상인 Switch Policies 입니다. 
기존의 장비의 각 인터페이스, 장비별 설정이 아닌 Profile을 통해서 장비 설정을 하게 되기 때문에 
이러한 Profile을 어떻게 설정하게 되는지에 대한 부분에 있어서 많은 이해가 필요할 것 같습니다.
전체적인 구성을 어떻게 만들지에 따라서, Profile에 의한 설정은 약이 될 수도 독이 될 수도 있다고 생각하기 때문입니다. 
아직 서비스 연결을 위해서 설정해야 할 부분들이 많이 남아있지만, 
하나씩 차근 차근 포스팅을 통해서 정리해보도록 하겠습니다. 

※ 현재 포스팅 기준은 ACI 2.0 기준입니다.


Switch Policies


Policies 
 - Switch에 전체에 설정되는 속성 값 설정. STP, VPC Domain 등의 설정 등에 대한 설정 가능. 
 - 아래의 메뉴처럼 스위치에 대한 정책 값들을에 대한 몇 가지 설정이 가능하나, 실질적으로 사용될만한 것은 vPC에 대한 부분입니다.

 
              
               

< Switch Policies의 Policies로 설정 가능한 메뉴 >


< VPC Domain Policies 설정 >


  - ACI 를 구성하는 Leaf에서 vPC를 사용하기 위해서는 아래와 같이 vPC Group으로 묶일 스위치를 선언해주어야 합니다.

    이 때에 사용되는 ID는 해당 APIC Pod에서는 Unique한 값으로 사용되어야 합니다. 

    그리고 vPC로 구성되는 Leaf은 2대로만 구성이 가능합니다. 

    만약, 이미 vPC로 구성된 스위치를 다른 vPC Group의 Switch로 선택하지 않도록 유의해야 합니다. 

    ACI 2.1 이후부터는 이미 vPC로 구성된 스위치를 다른 vPC Group에 선택하게 될 경우에 오류가 뜨면서 설정이 되지 않지만, 

    ACI 2.0 이하에서는 선택이 되면서, 기존의 vPC Group과 신규로 설정한 vPC Group 모두 비정상적으로 동작될 수 있습니다. 


< VPC Domain Policies 설정 >




Profile 
  - 실제 Switch Policies에서 주로 설정하게 될 설정으로, 물리적인 Switch에 대한 Profile을 어떻게 만들 것인지 정함.
  - Leaf Selector 에서 Blocks로 어떤 Block(물리 Leaf단위-leaf ID 값)를 설정할지 선정. 
    즉, 이 Switch Profile을 적용할 물리적인 Switch가 무엇인지를 선언. 
    하나의 Profile에서 하나의 Switch를 선택할 수도 있고, 다수의 Switch를 선택할 수도 있음.


            이 때에 Switch Policy Group으로 스위치에 설정할 값을 넣을 수 있음. 
            즉, Profile 이름을 지정 / 실제 물리 스위치 지정 / Policy Group 적용해서 설정
            하나의 leaf에 여러 개의 Policy Group을 적용도 가능 할 듯. 
            그리고, Interface Selector Profile을 어떤걸 적용할지 정할 수 있음.  
              : 다수개 가능(?) - 이게 어떤식으로 mapping 되는지 확인 


    - 그리고, 현재 Profile에 적용할 Interface Policies를 어떤 것을 선택할 것인지 선택.
      즉, 지난 포스팅에서 설정한 Interface Polices의 Profile을 적용할 스위치를 Switch Profile에서 선택. 
    - 동일한 Interface Profile을 사용하게 되는 Switch들의 경우에 각 스위치별로 설정을 하는 것이 아니라, 
      Switch Profile을 만들고, Switch Selector로 다수개의 스위치를 선택하여 Interface Profile을 지정하여 일괄적으로 적용이 가능.

         





  
Interface & Switch Policies 정리해서 이해하기!
    - 지난 포스팅의 Interface Policies와 이번 포스팅의 Switch Policies의 구성을 보면 다음과 같이 표현할 수 있습니다.
    - 일반 Interface의 개별 설정들에 대한 값들을 선언하고, 그러한 값들을 모아서 Interface Policy Group을 만들게 됩니다.
      Interface Policy Group은 실제 특정 인터페이스에 적용된 설정 값으로, 기존 NX-OS의 Port Profile과 거의 유사합니다. 
    - Interface Policy Group이 하나의 Interface에 적용되는 설정 값이라고 한다면, Interface Profile은 해당 설정 값이 적용될 
      Interface range 값을 포함한 내용입니다. Interface Selector을 통해서 적용된 interface를 지정합니다.
      단, 여기에서는 Interface의 range만 지정이 가능하며, 어떤 스위치에 적용될지에 대한 부분은 설정하지 못합니다.
    - Switch Profile에서는 어떤 Switch에 어떤 Interface Profile을 적용할 것인지를 mapping하게 됩니다.
    - 여기에서도 마찬가지로 Switch Selector를 통해서 다수의 Switch를 지정해서, 원하는 Interface Profile을 Mapping 할 수 있습니다.
    - 즉, 동일한 Interface 설정을 가진 스위치를 개별로 설정하는 것이 아니라, 일괄적으로 설정이 가능하게 됩니다.
    



Interface & Switch Policies 포스팅 마무리
    - Interface Policies와 Switch Policies를 정의할 때에는 그 때 그 때 Policies를 선언하는 방식이 아니라, 
      처음 구성 할 때부터 어떻게 구성을 하겠다는 전체적인 아키텍처의 그림이 나와야 합니다.
      한 번 설정한 Interface / Switch Policies를 변경하려고 하면, 기존에 적용된 내용들까지 모두 영향을 미치게 됩니다.
    - 전체 Range로 설정을 하였다가, Range를 풀어서 다시 묶어야 하는 경우에는 Range를 푸는 순간 기존 서비스는 설정이 사라지기 때문에
      서비스 이슈가 발생할 수 있습니다.
    - 설정에 대한 override도 가능한 것으로 보이나, 가능한 운영 관점에서는 일관된 설정으로 가는 것이 운영상에 좋지 않을까 생각해봅니다.
    


Posted by 네떡지기

티스토리 툴바