AWS 구성요소- 네트워크

 

1. 네트워크 개요

네트워크는 시스템 인프라를 구성하는 구성 요소 중 서버와 서버 간의 데이터에 대한 인터페이스 역할을 수행하는 구성요소 중 하나이다. 

일반적으로 네트워크 설계는 서버가 구성되는 데이터 센터를 기준으로 내부와 외부를 구분하고 이에 대한 연결 방식, 보안 등을 고려하며 인터페이스를 설계하며, 또한 센터 내의 경우에도 보안 등을 기준으로 사용자 접근 가능 영역/불가능 영역 그리고 서버 기능별로 그룹을 구성하고 이에 대한 인터페이스를 설계한다. 

본 장에서는 클라우드 환경 하에서 네트워크에 대한 특징을 알아보고 이에 대한 설계와 관련된 주의사항에 대하여 설명한다. 

2. 클라우드 네트워크 특징

On-Premise 환경에서는 네트워크 구성은 서버/스토리지와 마찬가지로 다수의 물리적인 장비와 이러한 장비와 장비 간, 장비와 서버 간 연결을 위한 케이블링 등을 이용하여 구성하는 것이 일반적이다.

클라우드 환경의 경우 다른 구성요소와 동일하게 기존 구성된 시스템 자원을 설정 등을 이용하여 논리적으로 네트워크 환경에 대한 구성이 가능하며, 케이블링 등과 같은 물리적인 작업이 필요 없다는 장점이 있다. 그 외에 클라우드 환경 내에서의 네트워크는 일부 용어를 제외하고는 구성 방식 등이 On-Premise와 동일하다고 할 수 있어, On-Premise의 설계 방식을 변경 없이 준용 가능하다. 

본 가이드의 대상이 되는 AWS에서 네트워크 환경 구성을 수행하기 위해서 네트워크 관련 AWS 서비스에 대하여 알아둘 필요가 있다. 

항목

내용

Region

On-Premise의 물리 전산 센터 영역
즉, 일반적인 주 센터, DR 센터 같이 지역적/물리적으로 분리된 센터를 의미
또한, AWS에서의 리전은 물리적으로 분리되었을 뿐 아니라 각각 독립적으로 동작

Availability Zone
(이하 AZ)

물리 센터 내에 논리적으로 분리된 논리 센터 영역
하나의 물리 센터 내에 다수의 AZ가 구성되어있으며, 각 AZ는 논리적으로 분리되어있음
하나의 AZ에서 발생한 장애가 타 AZ로 전이되지 않음

Virtual Private Cloud
(이하 VPC)

AWS 내에 구성 가능한 사용자 정의 가상 네트워크 영역
해당 VPC를 이용하여 다른 사용자의 시스템 리소스와 구분 가능
VPC는 여러 Region에 걸쳐 구성은 불가능하나, 해당하는 Region에 존재하는 여러 개의 AZ에 걸쳐서 구성 가능

Subnet

VPC 내에서 사용 가능한 IP 주소의 범위
On-Premise 환경에서의 Subnet과 동일 의미

Routing Table

VPC 내/외부와 통신하기 위한 Router 정보 등의 설정
On-Premise 환경에서의 Routing Table과 동일 의미

Route 53

외부 사용자 또는 VPC 내부 서버 인스턴스가 외부와 통신 시 필요한 Domain Name System(이하 DNS)
기본적인 DNS 기능 이외에 Latency Based Routing, Weighted Round Robin, DNS Failover, Geo Routing 기능을 제공

Region과 Availability Zone에 대한 상세 내용은 http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones 참조

표 45. AWS 네트워크 관련 서비스 

3. 네트워크 설계시 주의사항

클라우드 환경에서 네트워크 설계 시 아래와 같은 주의사항이 존재한다. 

항목

내용

VPC IP CIDR 블록 사이즈

VPC IP CIDR 블록 사이즈는 /28(IP 16개) ~/16(IP 65536개) 넷마스크까지 설정할 수 있는데 한번 설정하면 사이즈나 주소 변경이 불가능하므로 주의가 필요하다.

IP 주소

각 서브넷 CIDR 블록에서 첫 4개의 IP 주소와 마지막 IP 주소는 사용자가 사용할 수 없으므로 /28 넷마스크의 경우 실질적으로 11개의 IP 주소를 사용할 수 있다.

서버 간 통신

환경을 생성해도 Security Group으로 특정 포트에 대한 통신을 허용하지 않으면 기본적으로 모든 포트에 대한 통신이 불가하다.

표 46. 클라우드 환경 네트워크 설계 시 주의사항 

4. Region/AZ 구성

On-Premise 환경 또는 Private 클라우드 환경의 경우 자체적으로 보유하고 있는 데이터 센터를 이용하거나, 데이터 센터 서비스를 제공하는 제공자의 센터를 임대하여 센터를 구성하는 경우가 일반적이다. 

본 가이드의 대상이 되는 AWS는 전세계에 다수의 데이터 센터를 보유하고 있으며, 각각의 데이터 센터를 Region이라는 명칭으로 서비스 하고 있다.

해당 Region은 물리적인 데이터 센터와 동일한 개념이며, 각 Region은 내부에 논리적으로 구분된 다수의 AZ로 구성되어있다. 즉, 하나의 물리 센터 내에 논리적으로 분리된 여러 AZ가 존재하며, 이는 클라우드 서비스 제공 업체에 의해 구성되고 관리된다. 또한 Region과 AZ는 개별적으로 동작하며, 하나의 Region/AZ에서 발생한 장애는 타 Region/AZ로 전이되지 않도록 구성되어 있다. 

이러한 Region과 AZ를 도식화 하면 아래와 같다. 

그림 12. AWS Region과 AZ 

5. VPC 구성

본 가이드의 대상인 AWS와 같은 Public 클라우드는 인터넷을 통해 제공되는 서비스이며, 이는 해당 클라우드는 인터넷을 통하여 불특정한 다수가 접근 할 수 있다는 의미이기도 하다. 

이러한 환경 구성의 특성 상 AWS에서는 클라우드 환경 내에 외부와 논리적으로 분리된 가상의 네트워크 영역인 VPC를 구성할 수 있으며, 이를 통하여On-Premise 환경에서 Private IP 대역을 사용하는 서버의 그룹과 동일하게 외부로부터의 무제한 적인 접근을 1차적으로 제어하는 기능을 수행한다 할 수 있다. 

또한 Virtual Private Cloud(VPC)라는 사용자의 AWS 계정 전용 가상 네트워크를 통해 멀티 테넌트 환경에서 다른 리소스와 논리적으로 분리된 환경을 구성할 수 있다. VPC를 생성해 각 VPC에 IP 대역을 할당하고 라우팅 테이블 구성, 네트워크 게이트웨이 및 보안 설정 등의 작업으로 EC2 인스턴스 등 AWS 리소스를 생성할 수 있는 네트워크 환경 구성이 가능하다. 

이를 통하여 On-Premise 환경에서 운영 환경과 개발/검증 환경을 구분하는 방법과 동일하게 클라우드 환경 내에 VPC를 이용하여 운영, 개발/검증 환경을 구분하는 것이 일반적이다. 

VPC는 다음과 같은 구성요소로 이루어져 있으며, 대부분의 구성요소는 On-Premise 환경의 그것과 동일한 구성요소이다. 

항목

내용

VPC

AWS 클라우드 내의 논리적으로 격리된 가상 네트워크

Subnet

격리된 리소스 그룹을 배치할 수 있는 VPC IP 주소 범위의 한 세그먼트

Internet Gateway

퍼블릭 인터넷에 연결되는 Amazon VPC 측 게이트웨이

NAT Gateway

프라이빗 서브넷에 있는 리소스가 인터넷에 액세스할 수 있게 해주는 가용성이 뛰어난 관리형 NAT(Network Address Translation) 서비스

라우터

서브넷을 상호 연결하고, 인터넷 게이트웨이, 가상 프라이빗 게이트웨이, NAT 게이트웨이 및 서브넷 간의 트래픽을 전달

피어링 연결

피어링 연결을 사용하여 프라이빗 IP 주소를 통해 피어링되는 두 VPC 간 트래픽을 라우팅

VPC 엔드포인트

인터넷 게이트웨이 또는 NAT를 사용하지 않고 VPC 내에서 Amazon S3에 액세스하고, VPC 엔드포인트 정책을 사용하여 액세스를 제어

송신 전용 인터넷 게이트웨이

VPC에서 인터넷으로 IPv6 트래픽에 대하여 출구 전용 액세스를 제공하는 상태 정밀 검사 게이트웨이

하드웨어 VPN

사용자의 Amazon VPC와 데이터 센터, 홈 네트워크 또는 코로케이션 시설 간의 하드웨어 기반 VPN 연결

Virtual Private Gateway

VPN에 연결되는 Amazon VPC 측 게이트웨이

고객 Gateway

VPN에 연결되는 사용자 측 게이트웨이

표 47. VPC 구성 요소 

6. 서비스 별 구성

6.1. 내/외부망 분리

On-premise환경에서 대민 서비스 등 인터넷을 통한 서비스 요건이 있는 경우 보통 인터넷과의 통신이 가능한 외부망과 외부 접속이 불가한 내부망을 구분해 네트워크 환경을 구성한 것처럼 AWS 환경에서도 내/외부망을 분리하여 네트워크 환경 구성이 가능하다. 기본적으로 VPC라는 격리된 사설 네트워크를 생성하고 VPC 내부에 서브넷을 분리하여 인터넷으로부터의 Inbound 통신을 위해 필요한 Interet Gateway에 대한 라우팅 정책 추가 여부에 따라 Public Subnet과 Private Subnet을 생성해 애플리케이션 아키텍쳐에 적합하게 서브넷을 분리하여 인스턴스를 배치하고 외부 접속 필요 여부에 따라 라우팅 테이블을 구분해 작성하는 것으로 내/외부망 분리 구성이 가능하다.



그림 13. AWS 내부망/외부망 분리 구성도


  • VPC-172.51.0.0/16 내/외부망 구성 예시

<Subnet 구성>

Subnet Name

CIDR

AZ

Route Table

Description

PRD_PUB_AZ1

172.51.0.0/22

Availability zone A

PRD_RT_PUB

1번 AZ의 외부망

PRD_PRI_APP_AZ1

172.51.32.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 내부망

표 48. VPC 내/외부망 서브넷 구성 예시

6.2. 티어별 분리

내부망 내에서도 DBMS 등 특별한 이유로 인스턴스 군을 별도 분리해야할 요건이 있는 경우, 별도 서브넷을 추가 구성하여 서브넷을 분리할 수 있다. 


그림 14. AWS 서브넷 분리 구성도


  • VPC-172.51.0.0/16 내/외부망 분리 + 티어별 분리 구성 예시

<Subnet 구성>

Subnet Name

CIDR

AZ

Route Table

Description

PRD_PUB_AZ1

172.51.0.0/22

Availability zone A

PRD_RT_PUB

1번 AZ의 외부망

PRD_PRI_APP_AZ1

172.51.32.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 내부망

PRD_PRI_DB_AZ1

172.51.64.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 DB전용 내부망





표 49. 티어별 분리 서브넷 구성 예시

7. 데이터 센터 별 구성

기존 On-Premise환경에서 가용성 보장을 위한 기본 구성은 모든 리소스를 이중화로 구성하는 것이다. 클라우드 환경에서도 이처럼 인스턴스의 이중화 구성을 통해 아키텍처의 가용성을 향상시킬 수 있지만 단순히 같은 기능을 하는 인스턴스를 1대 이상 배치해 서버 장애에 대응하는 것 이상으로 2개 이상의 Availability Zone (이하, AZ 또는 가용영역)을 활용해 데이터 센터 수준의 장애에 대응하는 구성이 On-Premise 환경보다 간단한게 구축 가능하다. 가용 영역은 서로 물리적으로 분리되어 있는 데이터센터로 각 가용영역 사이의 통신은 고속 전용망을 통해 이뤄지며 리전별로 최소 2개에서 최대 5개까지 제공된다. *Seoul 리전의 경우 2개



그림 15. AWS 데이터 센터별 구성도

드물기는 하지만 특정 가용영역에 있는 모든 인스턴스의 가용성에 영향을 미치는 장애 (예: 정전이나 지진, 네트워크 장애) 가 발생할 경우, 하나의 가용영역에 복수개의 인스턴스를 구성했더라도 전체 서비스에 치명적인 영향을 줄 수 있기 때문에 AWS 환경에서는 최소 2개 이상의 가용 영역에 인스턴스를 이중화 구성으로 배치하기 위해 동일한 기능의 서브넷을 각 AZ 별로 개별적으로 구성할 필요가 있다.


그림 16. AWS AZ별 구성도


  • VPC-172.51.0.0/16 내/외부망 분리 + 티어별 분리 구성 + AZ별 분리 구성 예시

<Subnet 구성>

Subnet Name

CIDR

AZ

Route Table

Description

PRD_PUB_AZ1

172.51.0.0/22

Availability zone A

PRD_RT_PUB

1번 AZ의 외부망

PRD_PUB_AZ2

172.51.4.0/22

Availability zone C

PRD_RT_PUB

2번 AZ의 외부망

PRD_PRI_APP_AZ1

172.51.32.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 내부망

PRD_PRI_APP_AZ2

172.51.48.0/20

Availability zone C

PRD_RT_PRI

2번 AZ의 내부망

PRD_PRI_DB_AZ1

172.51.64.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 DB전용 내부망

PRD_PRI_DB_AZ2

172.51.68.0/20

Availability zone C

PRD_RT_PRI

2번 AZ의 DB전용 내부망











표 50. AZ별 분리 서브넷 구성 예시 

8. 개발/검증/운영 환경 별 구성

기존 On-Premise 환경에서 운영/보안 등의 이유로 용도에 따라 네트워크를 분리하여 구성하였던 것 처럼 AWS에서도 용도에 따라 복수개의 VPC를 생성해 각 VPC에 IP 대역을 할당하고 라우팅 테이블, 네트워크 게이트웨이 및 보안 설정 등의 작업으로 분리된 네트워크 환경을 구성해 EC2, EBS, RDS, ElastiCache, EMR 등 VPC 내부에 생성되는 리소스는 VPC 별로 분리하여 구성할 수 있다.

다만 기존 환경의 경우, 시스템에서 사용하는 리소스가 데이터 센터 밖에 위치하는 경우가 극히 드문것에 비해 AWS환경의 경우, VPC 외부에도 리소스가 존재한다. VPC 외부 리소스를 운영 인스턴스에서만 운영 리소스의 데이터 변경을 허용하는 등 환경별로 분리해야할 경우, 하나의 AWS Account를 사용하는 경우라면 IAM이나 Access Policy 등 접근 제어를 통해서 리소스에 대한 세밀한 권한 설정이 필요하다. 또, VPC 별로 분리된 리소스라고 하더라도 IAM 정책으로 운영자의 권한에 따른 작업에 대한 권한 제어가 필요하다. 자세한 내용은 보안 파트의 인증/권한제어를 참조한다. 

 

단일 AWS Account / 복수 VPC

복수 AWS Account / 복수 VPC

장점

  • 시스템 전체 리소스에 대한 통합 뷰 가능
  • 손쉽게 분리된 환경 구성 가능

단점

  • 세밀한 IAM 정책 설계가 필요

    Ex. VPC 외부 리소스 - IAM Role/Access Policy 기반 접근 제어를 통해 분리
    VPC 내부 리소스 – VPC 별로 권한 제어 설정
  • 환경 별로 공유가 필요한 리소스 (ex. 아티팩트가 보관된 S3)의 경우 교차 계정 접근 제어가 필요
  • AWS Account 별로 Support Costs 부과

표 51. VPC와 단일/복수 AWS Account 구성 

  • 단일 AWS Account / 복수 VPC 예시


그림 17. 단일 AWS Account / 복수 VPC 구성도

  • 복수 AWS Account / 복수 VPC 예시


그림 18. 복수 AWS Account / 복수 VPC 구성도

8.1. 분리 구성된 VPC 간의 통신 방안

필요에 의해 VPC로 네트워크 환경을 분리했어도 분리된 VPC 간의 통신이 요구되는 경우가 있을 것이다. 그런 경우, Gateway 나 VPN 연결 방식이 아닌 AWS환경 내부 통신을 통한 연결을 제공해 보안이나 대역폭, SPoF에 대한 고려 없이 VPC 간의 통신을 제공하는 VPC Endpoint 도입을 고려한다.
















그림 19. VPC간 통신 방안 


아래는 VPC Peering 의 제약 조건으로 설계에 참조한다.

  • 다른 Region에 있는 VPC 간에는 Peering 연결 불가
  • 다른 Account의 VPC라도 같은 Region이면 연결 가능
  • 두 VPC 의 CIDR 블럭이 중복되는 경우 연결이 불가
  • VPC Peering 간 최대 MTU는 1,500 byte
  • Transitive Peering 구성 불가: VPC B에서 다이렉트로 192.168.0.0/16 과 통신 불가, 통신을 위해서 VPC A에 Proxy 서버 등의 추가 구성이 필요

 
그림 20. VPC Peering 제약사항

<참고URL>

9. 외부망 통신

On-Premise환경에서는 서버와 운영자가 같은 망에 위치해 대민 서비스와 관련된 특정 서버만 인터넷 Inbound 통신이 필요한 경우가 보통이지만 클라우드의 경우, Legacy환경과 별도의 네트워크 환경이 구성되지 않았다면 개발자가 개발서버에 접속하는 것도 인터넷을 통한 접속이 필요하다. VPC에 생성되는 모든 인스턴스는 생성된 서브넷 IP 주소 범위 내의 기본 Private IP주소와 인스턴스의 Private IPv4 주소를 확인하는 내부 DNS 호스트 이름이 할당되는데 이 Private IP는 인터넷과 통신이 불가하다.

따라서, 인터넷 Inbound 통신이 필요한 인스턴스의 경우, 인터넷과 통신이 가능한 Public Subnet에 공인 IP가 자동 할당되도록 생성해야한다. 



그림 21. 인터넷 통신을 위한 퍼블릭 IP 할당


문제는 이렇게 할당된 공인 IP는 고정된 IP 주소가 아니라 유동 IP 주소로 해당 인스턴스를 중지하면 할당되었던 Public IP가 해제되고 인스턴스가 다시 시작되면 새 Public IP 주소가 할당되어 IP주소가 변경된다.

그렇기 때문에 외부에서 지속적으로 같은 IP주소를 통한 통신이 필요하다면 Elastic IP (엘라스틱 IP, 이하 EIP)를 할당받아 인스턴스에 설정해야한다.

EIP는 생성하면 반납하기 전까지 고정적으로 사용할 수 있는 Public IP주소로 필요에 따라 특정 인스턴스(또는 네트워크 인터페이스) 에 연결할 수 있다.

EIP는 VPC에 할당된 리소스로 인스턴스나 네트워크 인터페이스와 독립적이다. 따라서, 인스턴스 A에 연결했다가 해제하고 인스턴스 B에 재연결하는 등의 사용이 가능하고 Active-Standby 이중화 구성등에 활용될 수 있다.

그림 22. EIP 할당


Public IP와 관련된 주의사항은 아래와 같다.

  • 인스턴스가 중지 또는 종료되면 EIP가 아닌 인스턴스의 Public IP 주소는 해제
  • 인스턴스에 2개 이상의 네트워크 인터페이스가 연결된 경우, Public IP 주소가 할당되지 않음
  • EIP 는 IPv6를 지원하지 않음
  • EIP를 할당 받고 리소스와 연결하지 않아도 요금이 부과되어 사용하지 않는 EIP는 반납 필요
  • VPC 당 EIP 최초 제한 개수는 5개로 그 이상 필요한 경우 AWS Support를 통해 추가 요청 필요

<참고URL>
http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/vpc-eips.html

10. 내부망 통신

10.1. 인터넷 Outbound 통신 구성

Private Subnet은 보안 등의 이유로 외부와의 통신이 단절된 환경이다. 하지만, 기존 On-Premise 환경에서 내부망에 있는 서버들이 인터넷을 통한 통신이 거의 대부분 필요하지 않았던 것에 비해 AWS 환경에서는 Private Subnet에 생성된 인스턴스 들도 VPC 외부의 다른 AWS 서비스 사용이 필요하거나 인터페이스 네트워크가 없는 환경과의 타 데이터 센터와의 통신 등 인터넷 Outbound 통신이 필수적인 요건인 경우가 있어 아키텍처에 따라 Private Subnet 인스턴스의 인터넷 Outbound 통신을 위한 구성이 추가로 필요할 수 있다.


< 대표적인 VPC 외부 리소스 >

  • S3
  • SQS
  • DynamoDB
  • CodeCommit / CodeCommit / CodeDeploy 등




10.1.1. NAT 구성

외부 통신이 가능한 Public Subnet 에 EC2 인스턴스를 배포하고 이 인스턴스를 NAT 서버로 구축하여 사용하는 방법과 VPC환경에서 NAT 서버를 배포하고 관리해주는 서비스인 NAT Gateway를 사용하는 방법이 있다. NAT Gateway는 관리형 서비스이기 때문에 서버에 대한 운영 부담을 덜 수 있다는 점과 네트워크 트래픽에 따라 확장성을 보장해 병목지점이 되지 않는다는 장점이 있다 (그 외 비교는 하단의 URL 참고). 추가로, 모든 EC2 인스턴스는 기본적으로 보내거나 받는 트래픽의 원본 또는 대상이어야 하는데 NAT의 경우, 트래픽의 원본 또는 대상이 그 자신이 아닐 때도 트래픽을 보내고 받을 수 있어야 해서 SrcDestCheck(원본/대상 확인) 속성의 비활성화가 필요하다.



그림 23. NAT 구성도

<참고URL>

10.1.2. VPC Endpoint

Private Subnet의 인스턴스에서 S3에 파일을 업로드/다운로드해야할 경우, VPC Endpoint를 구성하면 인터넷 게이트웨이나 NAT등 없이도 S3와 통신이 가능하다. VPC Endpoint는 동일한 Region의 VPC와 S3간 지정 가능한 일종의 전용 네트워크로 Private Subnet에서 인터넷 Outbound 통신이 오직 S3 와의 통신인 경우라면 NAT 구성에 비해 다음과 같은 장점을 지닌다.

  • 대역폭 이슈에서 우위;
    Private Subnet의 인스턴스와 Internet 구간과의 트래픽이 한꺼번에 몰렸을 때, NAT를 수동으로 구성한 경우 NAT 인스턴스의 대역폭에 따라 병목 발생 가능성 有
  • NAT 구성에 필요한 비용을 절감


그림 24. VPC 엔드포인트 구성

<참고URL>

10.2. 접속 환경 구성

On-Premise환경에서는 보통 서버와 운영자가 서로 통신이 가능한 망에 위치해 관리/운영의 목적으로 서버에 접속하기 위한 네트워크 환경 구성에 관해 특별히 고려할 사항이 없었지만 클라우드 환경에서 인터넷 Inbound 통신이 불가능한 Private Subnet에 생성한 인스턴스의 경우, 외부에서 서버로의 접속이 가능한 환경을 구성하는 것 역시 중요하게 고려될 사항이다.

10.2.1. Bastion Host 구성

추가 인터페이스 통신 환경이 없어 인터넷을 통해 접근이 필요한 경우, Bastion host 방식으로 외부로부터의 접근이 가능하도록 구성한다. Private Subnet에 접속하기 위한 일종의 Proxy 역할을 하는 EC2 인스턴스를 Public Subnet에 생성하는 것으로 AWS에서 제공하는 기능은 아니다. Private subnet에 생성된 리소스들은 모두 Bastion Host를 통해 접속해 Bastion host의 접속 이력만 관리하면 Private subnet에 접속하는 모든 기록을 관리할 수 있고 접근 허용을 한 곳으로 한정 지어 보안을 강화할 수 있다. 단, Bastion host 가 공격 당하면 내부 네트워크가 모두 위험해 질 수 있으므로 인터넷으로부터 Bastion host에 대한 접속 허용 포트에 관해 철저한 관리가 필요하다.



그림 25. Bastion Host 구성도


Bastion Host 인스턴스의 OS로는 Windows나 Linux 계열 모두 사용할 수 있고 각각은 아래와 같은 특징을 지닌다.

 

Windows

Linux

구성 방식

  • 원격 접속
  • IP Masquerade 기능 활용
  • SSH 터널링 기능 활용

장점

  • 로컬과 Bastion Host 간 통신이 윈도우 원격 접속 포트만 사용해 네트워크 보안관련 제어가 쉬움
  • 동시 접속에 제한 없음

단점

  • 윈도우 EC2 인스턴스의 가격에 포함된 동시 원격 접속 허용 개수가 2개로 3명 이상의 동시 접속이 필요한 경우 원격 데스크톱 서비스(RDS) 라이선스 구매 필요
  • Private Subnet의 윈도우 인스턴스로의 접속이 필요한 경우, 원격 데스크탑을 이중으로 사용
  • 접속 인스턴스 1대 당 Bastion Host의 포트를 1개 사용, 따라서 운영자가 접속하는 IP대역으로 모든 포트를 오픈할 것이 아니라면 네트워크 보안관련 제어가 복잡해짐

표 52. Bastion Host 인스턴스 OS 

<참고URL>

10.2.2. 관리망 구성

기존 On-Premise환경에서 서버의 운영/관리를 위해 별도의 관리망을 구성했던 것 처럼 AWS 환경에서도 한 서브넷의 네트워크 인터페이스를 동일한 AZ에 구성된 VPC내 다른 서브넷의 인스턴스에 연결할 수 있어 인스턴스에 서로 다른 서브넷에 할당된 복수 개의 네트워크 인터페이스를 매핑하는 구성으로 인스턴스의 주 네트워크 인터페이스가 서비스 트래픽을 처리하고 부 네트워크 인터페이스가 관리 트래픽을 처리하도록 구성 할 수 있다. 이런 구성은 관리망 구성에도 활용될 수 있지만 3.1.1.2 티어별 서브넷 분리에서 WAS와 DB 인스턴스의 서브넷을 분리해 구성한 것을 활용해 WAS 인스턴스를 이중 홈 인스턴스로 구성하는 것도 가능하다. 단, 인스턴스 타입 별로 최대 ENI 개수 제한이 상이하여 확인이 필요하고 가용성/확장성 확보 방안으로 Auto-Scaling 구성을 활용하는 경우, 주 네트워크 인터페이스를 제외한 네트워크 인터페이스는 자동으로 할당되지 않기 때문에 추가 구성 방안 확보가 필요하다.



그림 26. 관리망 구성도


  • VPC-172.51.0.0/16 내/외부망 분리 + 티어별 분리 구성 + AZ별 분리 + 관리망 구성

<Subnet 구성>

Subnet Name

CIDR

AZ

Route Table

Description

PRD_PUB_AZ1

172.51.0.0/22

Availability zone A

PRD_RT_PUB

1번 AZ의 외부망

PRD_PUB_AZ2

172.51.4.0/22

Availability zone C

PRD_RT_PUB

2번 AZ의 외부망

PRD_PRI_APP_AZ1

172.51.32.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 내부망

PRD_PRI_APP_AZ2

172.51.48.0/20

Availability zone C

PRD_RT_PRI

2번 AZ의 내부망

PRD_PRI_DB_AZ1

172.51.64.0/20

Availability zone A

PRD_RT_PRI

1번 AZ의 DB전용 내부망

PRD_PRI_DB_AZ2

172.51.68.0/20

Availability zone C

PRD_RT_PRI

2번 AZ의 DB전용 내부망

PRD_PRI_MGT_AZ1

172.51.192.0/19

Availability zone A

PRD_RT_MGT

1번 AZ의 관리망

PRD_PRI_MGT_AZ2

172.51.224.0/19

Availability zone C

PRD_RT_MGT

2번 AZ의 관리망

표 53. 관리망 구성 서브넷 예시 

<Routing Table 구성>

Routing Table Name

Destination

Target

Description

PRD_RT_PUB

172.51.0.0/16

local

Default Rule (자동생성/변경불가)

 

0.0.0.0

Igw-XXXXXXXX

Public Subnet 인스턴스 인터넷 Inbound 통신 Rule

PRD_RT_PRI

172.51.0.0/16

local

Default Rule (자동생성/변경불가)

 

0.0.0.0

NAT eni-id

Private Subnet 인스턴스 인터넷 Outbound 통신 Rule

PRD_RT_MGT

172.51.0.0/16

Local

Default Rule (자동생성/변경불가)

 

0.0.0.0

vgw-XXXXXXXX

Private Subnet 인스턴스와 Legacy 시스템 간 통신 Rule

표 54. Routing Table 구성 예시

<참고URL>

11. 기존 Legacy 시스템과의 통신

기존 On-Premise 환경에서 타 시스템과의 인터페이스 통신 요건이 있는 경우, 타 센터와의 전용망을 구성하거나 VPN 구성으로 보안을 강화한 것처럼 클라우드 환경 내의 시스템이 기존 데이터 센터와의 인터페이스 요건으로 인터페이스 네트워크 환경 구성이 필요할 때도 위의 두 가지 방안으로 접근할 수 있다.

11.1. 전용 네트워크 환경 구성

기존 센터와 센터 간 ISP로부터 전용선을 임대한 회사에서만 사용이 가능한 폐쇄망을 구성하던 것 처럼 AWS 환경에서도 AWS DirectConnect라는 서비스로 전용 네트워크 구성이 가능하다. 높은 보안성 이외에 VPN 구성에 비해 일관된 네트워크 성능 보장이 가능하다는 점에 가장 우선적으로 고려되어야 할 방안이다.



그림 27. 전용 네트워크 환경 구성도


<참고URL>

11.2. VPN 구성

특정한 이유로 전용 네트워크 구성이 불가한 경우라도 통신 데이터의 보안을 위해 Legacy 시스템과의 인터페이스 환경은 VPN 구성이 필요하다. AWS에서 VPN 구성을 하는 방식은 On-Premise 환경의 물리 VPN 장비와 VPN 통신을 하는 VPN Gateway를 사용하는 구성과 서버 등에 설치된 VPN 솔루션을 통한 Software VPN 구성이 가능하다.

11.2.1. Hardware VPN

인터넷을 통해 원격 네트워크와 Amazon VPC 간에 하드웨어 기반의 IPsec VPN 연결을 구성하는 방식으로 VPC쪽에 VGW(Virtual Private Gateway)를 구성하고 원격 네트워크에는 물리 VPN 장비를 구성해야 한다. VPC의 VPN Gateway와 Hardware VPN 연결 구성이 가능하다고 확인된 장비 리스트는 http://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/NetworkAdminGuide/Introduction.html#DevicesTested에서 확인 가능하다. VPC 쪽에 위치한 VGW의 경우는 AZ 장애에 대한 가용성을 보장하지만 원격 네트워크에 위치한 장비의 가용성은 직접 구성해야한다는 점과 VPC 당 VGW는 1개 만 생성할 수 있다는 점에 주의가 필요하다.



그림 28. 하드웨어 VPN 구성도


<참고URL>

11.2.2. Software VPN

원격 네트워크 환경에 물리 VPN 장비 도입이 어려운 경우, VPC내의 인스턴스와 원격 네트워크 환경의 서버에 VPN 솔루션을 설치해 VPN 연결을 구성할 수 있다. AWS Marketplace에서 소프트웨어 VPN이 설치된 AMI를 구입해 생성하거나 오픈 소스 솔루션을(ex. OpenVPN) 직접 구성해야하고 추가적으로 가용성 확보 방안 등이 고려되야 한다.



그림 29. 소프트웨어 VPN 구성도

11.3. Transit VPC 구성

개발/검증/운영 환경 별로 VPC를 분리해 운영하는 경우 Legacy 시스템과의 인터페이스 네트워크 환경이 필요하다면 각 VPC 별로 Legacy 시스템과 인터페이스 네트워크 환경 구성이 필요하다. 운영하는 VPC가 적을 때는 각 환경별 VPC 마다 인터페이스 네트워크 환경을 구성하는 것이 용이할 수 있으나 인터페이스 네트워크가 필요한 환경의 수가 증가할수록 관리/운영 상의 어려움이 증가하므로 Hub-and-spoke로 인터페이스 네트워크 환경을 구성하기 위해 Transit VPC 구성이 고려될 수 있다. 



그림 30. Transit VPC 구성도

<참고URL>

댓글

댓글 쓰기

이 블로그의 인기 게시물

파일처리(한번에 모두읽기, 라인단위로 읽기, 쓰기, 리스트처리, 특정길이만큼 읽기)

이미지
텍스트 파일 한 번에 모두 읽기 (Utility 타입)   대용량 파일일 때는 메모리가 부족할 수 있으므로 ' 텍스트 파일 라인 단위로 읽어서 처리 ' 방식을 사용 public static String read(String filePath) throws IOException {        StringBuilder  stringBuilder;      FileReader     fileReader     = null ;      BufferedReader bufferedReader = null ;      try {          stringBuilder  = new StringBuilder();          fileReader     = new FileReader(filePath);          bufferedReader = new BufferedReader(fileReader);          String line;          while ((line = bufferedReader.readLine()) != null )            ...
자세한 내용 보기

AWS 가용성,확장성

이미지
1.  개요 On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.  그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다. 따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다. 또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다. 본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다. 2.  가용성 확보 방안 2.1.  센터 On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다. 해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.  클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같...
자세한 내용 보기

Serverless computing 도입시 고려사항

이미지
  1.  공급업체 종속성 서버리스 컴퓨팅같은 PaaS 서비스는 공급업체 종속성 Vender Lock-in  을 피할 수 없다. PaaS 서비스를 사용하다가 다른 클라우드 업체나 On-Premise로 이전하는 것은 막대한 비용이 발생한다. 또한 서버리스 컴퓨팅 은 제공하는 업체별로 사용 방법이 다르고 트리거 서비스가 각 공급사 서비스별로 연계되지 않기에 멀티 클라우드 전략이 어렵다. 한 예로 AWS Kinesis 라는 데이터 스트림 서비스는 AWS Lambda 와 연결하여 사용하나 Azure Functions 나 Apache OpenWisky에는 연계할 수 없다. 또한 특정 국가에서는 시스템의 서버가 반드시 해당 국가에 위치해야 하는데 CSP의 데이터 센터는 모든 국가에 위치해있지는 않다. 이런 상황에서는 시스템 수출 시 서버리스 컴퓨팅 뿐만 아니라 다른 PaaS 서비스들도 직접 구현해야 할 상황이 발생할 수 있다. 공급업체 종속성을 피하려면 오픈소스 서버리스 컴퓨팅 플랫폼을 이용 해야 한다.  2.  공급업체 마다 상이한 SLA 서버리스 컴퓨팅의 장점 중 하나는 서버 설정 등의 관리를 공급업체에서 진행하는 것이다.  하지만 공급업체의 실수로 장애가 발생할 수 있다.  한 예로 AWS의 Lambda 서비스 초기엔 잘 사용하던 함수가 몇 시간 동안 동작하지 않은 적이 있었고 AWS의 최초 서비스인 S3도 2017년 2월에 장애가 발생하여 이에 연결된 Lambda가 동작하지 않은 적도 있었다. [1]  이런 상황에 대비가 필요하고 필요에 따라서 보상을 받기 위해 SLA나 이용약관을 확인해야 한다.  AWS Lambda는 SLA가 없어 AWS의 문제로 인해 장애가 발생해도 보상 받을 수 없다.  또한 AWS의 Lambda 서비스 이용 약관에는 “AWS Lambda에 업로드된 고객의 컨텐츠가3개월 간 실행되지 않으면 30일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기