Today Keys : AWS, outposts, on-premise, hybrid, 하이브리드, 클라우드, 온프레미스, azure, stack, re.Invent

 


이번 주에 진행 중인, AWS re.Invent 2018에서

On-premise에서 사용 가능한 AWS 버전인 AWS Outposts에 대한 내용이 발표되었다고 합니다. (실제 출시는 내년 하반기 이후?)

개인적으로 기존의 Azure의 강점 중의 하나가 On-Premise에서 사용 가능한 Azure Stack을 통해서

사용자에게 Public 과 동일한 Cloud 환경을 제공하는 것이라고 생각했는 데,

AWS에서도 Outposts를 통해서 진행하게 되는 것 같습니다.

이번 포스팅에서는 AWS의 Outposts에 대해서 아주 간략히(?) 정리해 봅니다.


 

AWS Outposts

AWS를 Public Cloud로써의 환경이 아닌 on-premise로 제공하기 위한 서비스

▪ AWS 디지안한 하드웨어로 구축된 컴퓨팅/스토리지랙을 사용하여 On-premise에서 구축

▪ AWS 클라우드에서 사용되는 동일한 native AWS API를 사용 가능

▪ 기존 AWS의 환경을 그대로 사용 할 수 있는 AWS native variant와 AWS에서 제공되던 VMware variant 환경을 제공

▪ AWS Outposts에 대해서도 AWS에서 관리 및 지원을 하며, public AWS region와 마찬가지로 자동으로 관리하고 업데이트

    - 인프라에 대한 업데이트나 패치에 대한 부분 지원

 

AWS Outposts에서 사용 가능한 옵션

▪ AWS native variant

  - AWS native variant 를 사용하는 경우에는 AWS에서 사용하는 것과 동일한 API 및 Control Plane을 사용

  - 초기에는 EC2, EBS에 대해서 지원하며, 향후 RDS, ECS, EKS, SageMaker, EMR 서비스 등을 추가 예정

VMware variant

   - 기존의  AWS에서 제공하던 'VMware Cloud on AWS'를 On-Premise에서 구축. 서비스 제공. AWS

   - VMware 의 API 및 Control Plane 사용 가능.

 

AWS Outposts에서 제공되는 Type 및 사이즈와 서비스

▪ 현재 EC2와 스토리지에 대해서 선택 가능한 옵션

   - EC2 : C5, M5, R5

   - 스토리지 : EBS, Local instance storage Local disk

▪ 단일 Outposts 서버로 시작해서, quarter, half, full Outposts 랙으로 증설 가능.

▪ 다양한 컴퓨팅, 메모리, 스토리지 옵션을 선택할 수 있음은 물론이고 최신의 하드웨어로 손쉽게 업그레이드 할 수 있음.

 

 

정리하고.

 이번 주에 발표된 내용이기도 하고, 아직 많은 내용의 자료도 공개된 게 없어서 큰 내용은 없습니다.

 기존의 Micro Azure Stack에 이어서 AWS Outposts까지... 좀 더 안정적인 Hybrid Cloud를 위한 Public과 동일한 환경의

 On-premise Cloud 솔루션들이 시장을 얼마나 차지할런지는 모르겠습니다.

 다만, 이러한 솔루션과 방향성이 결국 운영 입장에서는 On-premise와 Public 환경에서의

 Cloud 선택지에서 중요 선별 포인트가 되지 않을까 싶습니다.

 

 

 

 

Posted by 네떡지기

Today Keys : AWS, VPC, CIDR, 대역 추역, 네트워크, 디자인, 설계, 중복, 블록, block, ipv4


이번 포스팅은 VPC의 Primary / Secondary CIDR에 대해서 간단히 정리했습니다.





VPC의 CIDR

· VPC를 생성할 때에는 AWS 내에서 사용하게 될 가상 네트워크에 대한 대역(CIDR)을 선언


· Public / Private 서브넷 모두 VPC의 CIDR 네트워크를 기반으로 한 네트워크 대역을 사용

· VPC를 생성하는 시점에 설정한 네트워크 대역(CIDR)은 수정 할 수 없음.

     - 삭제도 불가능하며, VPC 자체를 삭제해야만 함.


 · VPC의 CIDR은 서브넷은 16bit ~ 28bit로 설정 가능 

 · VPC를 생성 할 때에는 전체적인 AWS 내에서의 전체적인 네트워크 구성과 On-Premise와의 연동을 어떻게 할 것인지에 

   대한 디자인을 하는 과정이 매우 중요.

 · VPC 생성 시점에 만든 CIDR의 경우 수정이나 삭제가 불가능하지만, VPC 생성 이후에 추가적인 CIDR을 생성할 수 있음.

 · VPC 생성 시에 만들어진 CIDR을 'Primary CIDR' 이라고 하고, 추가로 만든 CIDR을 'Secondary CIDR'이라고 함.

 · Secondary CIDR를 만들기 위해서는 VPC 메뉴에서 'CIDR 편집'을 선택


 · CIDR 편집 화면으로 가면 다음과 같이 해당 VPC에서 사용할 CIDR을 관리할 수 있도록 제공.

 · Secondary CIDR 생성 시에는 VPC 내에서 기존에 생성한 CIDR의 네트워크 대역과 중첩되면 안 됨. 

     - 중첩으로 생성 시에 다음과 같이 오류 메시지가 발생하며, 생성되지 않음.



 · Secondary CIDR의 경우에는 추가로 4개까지 생성이 가능

    - 5개 이후(Primary CIDR 포함)에 CIDR을 추가로 생성하려고 하면 다음과 같은 오류 발생.


 · Primary CIDR이 수정 및 삭제가 불가능한 반면에 Secondary CIDR의 경우 수정은 동일하게 불가능하지만, 삭제는 가능.

 · VPC Peering 시에 CIDR 추가는 추가로 몇가지 규칙이 적용 됨. 

     - 이 부분은 VPC Peering 에서 다루겠습니다.





 ·

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

티스토리 툴바