반응형

Default VPC Walkthrough

  • 새로운 AWS 계정은 모두 기본 VPC가 하나 생기고 바로 사용할 수 있다.
  • 새로운 EC2 인스턴스는 서브셋을 지정하지 않으면 기본 VPC에 실행된다.
  • 기본 VPC는 처음부터 인터넷에 연결돼 있어서 인스턴스가 인터넷에 액세스하고 내부의 EC2 인스턴스는 공용 IPv4 주소를 얻는다.
  • EC2 인스턴스를 위한 공용 및 사설 IPv4 DNS 이름도 얻는다.
  • 기본 VPC가 만들어졌을 때 CIDR 탭을 보면 CIDR에 IP 하나만 생성되고 VPC와 연결되어 있다.
  • 기본적으로 각 서브넷에는 고유 IPv4 CIDR가 있고 가용 영역을 확인하면 서브넷마다 다른 AZ에 위치한다.
  • CIDR 외부 트래픽 모두 인터넷 게이트웨이로 이동한다.
  • 인터넷 게이트웨이가 VPC에 연결되어 있고 VPC에 위치한 EC2 인스턴스에 인터넷 액세스를 제공한다.
  • 라우팅 테이블은 명시적으로 연결된 서브넷이 없어도 암시적으로 연결된 경우가 있다.

VPC in AWS (IPv4)

  • VPC(Virtual Private Cloud)
  • 단일 AWS 리전에 여러 VPC를 둘 수 있다.
  • 리전당 최대 5개까지 가능한데 엄격히 제한하지 않아서 더 늘릴 수 있다.
  • VPC마다 할당된 CIDR는 다섯 개
  • 각 CIDR의 최소 크기는 /28로 IP 주소는 최소 16개, 최대 크기는 /16으로 IP 주소는 최대 65,536개
  • VPC가 사설 리소스이기 때문에 사설 IPv4 범위만 허용
  • VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의해야 한다.
  • 함께 연결하려면 VPC 혹은 CIDR IP 주소가 다른 네트워크의 IP 주소 범위와 겹치지 않아야 한다.

Subnet (IPv4)

  • 서브넷이란 VPC 내부에 있는 IPv4 주소의 부분 범위
  • 이 범위 내에서 AWS가 IP 주소 다섯 개를 예약한다.
    • CIDR 블록 10.0.0.0/24가 있다면 일부는 예약된 IP 주소다.
    • 10.0.0.0 네트워크 주소
    • 10.0.0.1 VPC 라우터용
    • 10.0.0.2 Amazon 제공 DNS에 매핑
    • 10.0.0.3은 당장 사용되진 않지만 나중에 필요할지 모르니까 예약해 둔다.
    • 10.0.0.255 네트워크 브로드캐스트 주소 (AWS는 VPC에서 브로드캐스트를 지원하지 않기에 예약은 되지만 사용하는 건 안됨)
  • EC2 인스턴스 서브넷에서 IP 주소 29개가 필요할 때 /27 서브넷은 사용 못 한다는 걸 시험 볼 때 기억해야함

Internet Gateway

  • 인터넷 Gateway는 VPC의 리소스를 인터넷에 연결하도록 허용하는 EC2 인스턴스나 람다 함수 등
  • 수평으로 확장되고 가용성과 중복성이 높고 좋은 관리형 리소스
  • VPC와는 별개로 생성해야 하고 VPC는 인터넷 Gateway 하나에만 연결되며 반대의 경우도 마찬가지
  • 인터넷 Gateway 자체는 인터넷 액세스를 허용하지 않는다.
  • 작동을 위해 라우팅 테이블을 수정해야 한다.
  • 예를 들면 공용 서브넷에 공용 EC2 인스턴스를 만들고 라우팅 테이블을 수정해서 EC2 인스턴스를 라우터에 연결하고 인터넷 Gateway에 연결한다. 그러면 인터넷 Gateway가 인터넷과 연결될 수 있다.

Bastion Host

  • 퍼블릭 서브넷에 있는 EC2 인스턴스, 배스천 호스트로 프라이빗 서브넷에 있는 EC2 인스턴스에 액세스할 수 있다.
  • 프라이빗 서브넷에 있는 EC2 인스턴스에 액세스하려면 SSH를 배스천 호스트에 연결하고 이 배스천 호스트가 다시 SSH를 프라이빗 서브넷의 EC2 인스턴스에 연결해야 한다.
  • 이때 배스천 호스트는 반드시 퍼블릭 서브넷에 있어야 한다.
  • 배스천 호스트를 위해서는 보안 그룹이 반드시 인터넷 액세스를 허용해야 한다.
  • 하지만 모든 인터넷 액세스를 허용하면 보안상 위험이 크기 때문에 가령 기업의 퍼블릭 CIDR 액세스만 허용하거나 사용자의 인터넷 액세스만 허용하는 등 이를 제한하는 게 좋다.
  • 프라이빗 서브넷의 EC2 인스턴스 보안 그룹에서는 반드시 SSH 액세스를 허용해야 한다.

구형 NAT Instance

  • NAT 인스턴스는 사설 서브넷 EC2 인스턴스가 인터넷에 연결되도록 허용한다.
  • NAT 인스턴스는 공용 서브넷에서 실행되어야 하고, 공용 및 사설 서브넷을 연결한다.
  • 비활성화해야 하는 설정은 바로 소스/목적지 확인이다.
  • NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 한다.
  • 라우팅 테이블을 수정하여 사설 서브넷과 공용 서브넷의 두 서브넷에 있는 EC2 인스턴스로부터 NAT 인스턴스로 트래픽을 전송하도록 한다.
  • 그리고 인스턴스의 IP는 공용 서버로 액세스하는데 NAT 인스턴스를 통과해야 한다.
  • NAT 인스턴스의 작동 방식을 크게 보면 공용 서브넷에 NAT 인스턴스를 생성하고 거기에 탄력적 IP를 연결한다.
  • 그리고 라우팅 테이블을 통해 사설 인스턴스가 NAT 인스턴스에서 인터넷 Gateway까지 통신하도록 한다/
  • NAT 인스턴스를 보면, 사전 구성된 Amazon Linux AMI를 사용할 수 있었지만 2020년 12월 31일로 표준 지원이 종료되었기에 이제 NAT Gateway를 권장한다.
  • NAT 인스턴스는 가용성이 높지 않고 초기화 설정으로 복원할 수 없어서 여러 AZ에 ASG를 생성해야 하고 복원되는 사용자 데이터 스크립트가 필요하기에 꽤 복잡하다.
  • 그리고 작은 인스턴스는 큰 인스턴스에 비교해서 대역폭이 더 작다.
  • 보안 그룹과 규칙을 관리해야 한다.
  • 인바운드에서는, 사설 서브넷의 HTTP/HTTPS 트래픽을 허용하고 홈 네트워크의 SSH도 허용한다.
  • 아웃바운드에서도 트래픽이 나가도록 해야한다.

NAT Gateway

  • AWS의 관리형 NAT 인스턴스이며 높은 대역폭을 가지고 있다.
  • 가용성이 높으며 관리할 필요가 없다.
  • 사용량 및 NAT Gateway의 대역폭에 따라 청구된다.
  • NAT Gateway는 특정 AZ에서 생성되고 탄력적 IP를 이어받는다.
  • EC2 인스턴스와 같은 서브넷에서 사용할 수 없어서 다른 서브넷에서 액세스할 때만 NAT Gateway가 도움이 된다.
  • 대역폭은 초당 5GB이며 자동으로 초당 45GB까지 확장할 수 있다.
  • 그리고 보안 그룹을 관리할 필요가 없다.

NAT Gateway 고가용성

  • NAT Gateway은 단일 AZ에서 복원 가능
  • 단일 AZ 내에서만 중복되지만 AZ가 중지될 경우를 위해 다중 NAT Gateway를 여러 AZ에 두면 결함 허용을 할 수 있다.
  • 라우팅 테이블을 통해 AZ를 서로 연결할 필요는 없다.

NAT Gateway vs NAT Instance

  • AZ 전체에서 고가용성을 필요로 하는 경우 다른 AZ에 더 만들어야 한다. 반면 NAT 인스턴스는 인스턴스간 장애 조치 스크립트를 통해서 전체적인 관리를 해야 한다
  • 대역폭은 NAT Gateway마다 초당 최대 45GB. 인스턴스에서는 사용하는 EC2 인스턴스에 따라 다른데 고급 인스턴스 유형일수록 더 많은 처리량을 가진다.
  • 유지 보수의 경우 NAT Gateway는 관리형 서비스이며, NAT 인스턴스는 사용자가 하고, OS 패치 등 소프트웨어가 필요하다.
  • 비용의 경우 시간당 비용과 NAT Gateway의 데이터 전송량을 더하고 반면 NAT 인스턴스는 시간당 EC2 인스턴스가 청구되며 EC2 인스턴스 유형과 크기에 따라 달라진다.
  • 또 EC2 인스턴스를 통해 인터넷으로 나가는 네트워크 비용도 함께 청구된다.
  • NAT Gateway는 공용 IPv4와 사설 IPv4를 가지고 있으며 NAT 인스턴스도 같다.
  • NAT Gateway는 보안 그룹을 사용하지 않는다. NAT 인스턴스는 보안 그룹을 설정하여 맞는 포트에 작동하게 해야 한다.

Security Groups & NACL

  • 서브넷을 오가는 트래픽을 제어하는 방화벽과 비슷하다.
  • 서브넷마다 하나의 NACL이 있고 새로운 서브넷에는 기본 NACL이 할당된다.

NACL Rules

  • NACL 규칙 정의에서 규칙에는 숫자가 있고 범위는 1부터 32,766까지
  • 숫자가 낮을수록 우선순위가 높아서 우선순위가 제일 높은 것은 1 가장 낮은 것은 32,766
  • 첫 번째 규칙 비교로 결정된다. 예를 들어 CIDR에서 ALLOW 를 정의하고 같은 CIDR인 특정 IP를 DENY로 정의하면 ALLOW는 100이고 DENY가 200이니까 IP 주소는 허용된다. 100이 200보다 우선
  • 마지막 규칙은 별표인데, 일치하는 규칙이 없으면 모든 요청을 거부한다.
  • AWS는 규칙을 100씩 추가하는 것을 권장
  • 새로 만들어진 NACL은 기본적으로 모두를 거부
  • NACL 사용 사례를 들면 서브넷 수준에서 특정한 IP 주소를 차단하는데 적합

기본 NACL

  • 기본 NACL는 연결된 서브넷을 가지고 인바운드와 아웃바운드의 모든 요청을 허용하는 특수성을 가진다.
  • 이것이 IPv4를 지원하는 기본 NACL의 모습인데 모든 것이 나가고 들어올 수 있다.
  • NACL이 모든 것을 드나들도록 허용하지 않으면 AWS를 시작할 때 심각한 디버깅을 해야 한다.
  • 기본 NACL은 매우 개방적
  • 기본 NACL을 수정하지 않는 것을 추천

임시 포트

  • 클라이언트와 서버가 연결되면 포트를 사용해야 한다.
  • 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게 된다.
  • 이 포트는 임시라서 클라이언트와 서버 간 연결이 유지되는 동안만 열려 있다.
  • 임시포트는 OS에 따라 즉 운영 체제에 따라 포트 범위가 달라진다.
    • Windows 10을 사용하면, 49152에서 65,535까지가
    • Linux를 사용할 경우 범위는 32768에서 60999까지
  • 임시 포트라고 불리는 것은 연결 수명을 위해서만 할당되는 무작위 포트이기 때문입니다

보안 그룹과 NACL의 차이점

  • 보안 그룹은 인스턴스 수준에서 작동하는데 NACL은 서브넷 수준에서 작동
  • 보안 그룹은 허용 규칙을 지원하지만 NACL은 허용과 거부 규칙을 모두 지원
  • NACL에서는 특정 IP 주소를 거부할 수 있다.
  • 보안 그룹은 상태 유지이며 규칙과 무관하게 트래픽을 허용
  • NACL은 무상태이기 때문에 인바운드와 아웃바운드 규칙이 매번 평가되고 임시 포트를 리마인더로 생각하자.
  • 보안 그룹에서는 모든 규칙이 평가되고 트래픽 허용 여부를 결정하지만 NACL에서는 가장 높은 우선순위를 가진 것이 먼저 평가된다.
  • 보안 그룹은 누군가 지정할 때 EC2 인스턴스에 적용되지만 NACL은 거기에 연결된 서브넷의 모든 EC2 인스턴스에 적용된다.

VPC 피어링

  • VPC 피어링 연결을 추가해서 서로 다른 VPC를 연결한다. 즉 통신이 가능해진다.
  • 다양한 리전과 계정에서 VPC를 생성할 수 있는데 AWS 네트워크를 통해 연결하고 싶을 때 사용
  • 연결했을 때 CIDR가 겹치면 통신을 할 수 없다.
  • VPC 피어링은 두 VPC 간에 발생하며 전이되지 않습니다. (A, B 연결 완료. B, C 연결 완료. 이 상황에서 A,C 통신 불가)
  • VPC 피어링이 있을 때 활성화는 당연하고 VPC 서브넷 상의 루트 테이블도 업데이트해서 EC2 인스턴스가 서로 통신할 수 있게 해야 한다.
  • 다른 계정 간에도 VPC 피어링이 가능하다. 또한 리전 간 연결도 가능
  • 보안 그룹에서 다른 보안 그룹을 참조할 수 있었는데 동일 리전의 계정 간 VPC에서도 보안 그룹을 참조할 수도 있다.

VPC EndPoint

  • VPC 엔드포인트를 사용하면 퍼블릭 인터넷을 거치지 않고도 인스턴스에 액세스할 수 있다.
  • 프라이빗 AWS 네트워크만 거쳐서 바로 해당 서비스에 액세스할 수 있다.
  • VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 프라이빗으로 액세스하므로 AWS에 있는 모든 서비스에 액세스할 때 퍼블릭 인터넷을 거치지 않고도 프라이빗 네트워크를 사용할 수 있다.
  • VPC 엔드포인트는 중복과 수평 확장이 가능하고 인터넷 게이트웨이나 NAT Gateway 없이도 AWS 서비스에 액세스할 수 있게 해주므로 네트워크 인프라를 상당히 간단하게 만들 수 있다.
  • 문제가 발생하면 VPC에서 DNS 설정 해석이나 라우팅 테이블을 확인하면 된다.

VPC EndPoin 유형

  • VPC 엔드포인트 유형은 2가지가 있다.
  • PrivateLink를 이용하는 인터페이스(Interface) 엔드포인트와 게이트웨이(Gateway) 엔드포인트

인터페이스(Interface) 엔드포인트

  • 인터페이스 엔드포인트는 ENI를 프로비저닝하는데 ENI는 VPC의 프라이빗 IP 주소이자 AWS의 엔트리 포인트
  • ENI가 있으므로 반드시 보안 그룹을 연결해야 한다.
  • 대부분의 AWS 서비스를 지원하고 청구되는 요금은 시간 단위 또는 처리되는 데이터 GB 단위로 청구
  • 이 방법은 모든 서비스에서 사용할 수 있다.

게이트웨이(Gateway) 엔드포인트

  • 게이트웨이 엔드포인트는 특이하게 게이트웨이를 프로비저닝하는데 이때 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 한다.
  • IP 주소를 사용하거나 보안 그룹을 사용하지 않고 라우팅 테이블의 대상이 될 뿐 (중요)
  • 게이트웨이 엔드포인트 대상으로는 Amazon S3와 DynamoDB 두 가지가 있고 장점은 요금이 무료이고 라우팅 테이블 액세스일 뿐이므로 자동으로 확장된다는 점
  • 시험에서는 게이트웨이 엔드포인트를 선택하시는 것이 유리. (라우팅 테이블만 수정하면 되므로 또한 무료)

정리

  • 게이트웨이 엔드포인트는 비용이 들지 않고 확장성이 더 높지만 인터페이스 엔드포인트를 사용하면 비용이 발생
  • 게이트웨이 엔드포인트보다 인터페이스 엔드포인트가 권장되는 경우는 온프레미스에서 액세스해야 할 필요가 있을 때 뿐
  • 온프레미스에 있는 데이터 센터에 프라이빗으로 액세스해야 하는 경우 Site-to-Site VPN이나 직접 연결 방법이 있다.
  • 혹은 다른 VPC에 연결할 때도 인터페이스 엔드포인트 유형을 사용하는 편이 좋다.
  • 대부분 Amazon S3에서는 게이트웨이 엔드포인트가 유리

VPC Flow log

  • VPC 흐름 로그는 인터페이스로 향하는 IP 트래픽 정보를 포착하는 것
  • VPC 계층, 서브넷 계층 Elastic Network Interface(ENI) 계층 총 세 가지 흐름 로그가 있다.
  • 흐름 로그는 연결 문제를 모니터링하고 트러블 슈팅하는 데 유용
  • 로그 데이터는 Amazon S3와 CloudWatch Logs에 전송할 수 있고 그리고 AWS 관리형 인터페이스 즉 ELB, RDS, ElastiCache Redshift, Workspaces NAT Gateway, Transit Gateway의 정보를 포착한다.
  • 정해진 형식에 따라 version, account-id interface-id가 있으며 소스 주소(srcaddr), 대상 주소(dstaddr) 소스 포트(srcport), 대상 포트(dstport), 프로토콜(protocol) 패킷 수(packets), 바이트 수(bytes) 시작 동작(start action), 로그 상태(log-status) 등이 있다.
    • srcaddr과 dstaddr로는 문제가 있는 IP를 식별할 수 있다. 한 IP가 지속적으로 거부되면 여기서 알아볼 수 있다. IP에 문제가 있거나 특정 IP가 공격받았을 때도 여기서 알 수 있다.
    • srcport와 dstport에서는 문제가 있는 포트를 식별할 수 있다
    • action은 요청이 수락되었는지 거부되었는지를 나타내며 보안 그룹이나 NACL 계층에서 요청이 성공했는지 실패했는지를 알려 준다.
  • 이러한 VPC 흐름 로그는 사용량 패턴 분석이나 악성 행동 감지 포트 스캔 등에 사용할 수 있다.

Site-to-Site VPN

  • 기업 온프레미스를 AWS와 비공개로 연결하려면 기업은 고객 게이트웨이를 VPC는 VPN 게이트웨이를 갖춰야 한다.
  • 공용 인터넷을 통해 사설 Site-to-Site VPN을 연결해야한다.
  • 공용 인터넷을 거치긴 하지만 VPN 연결이라서 암호화돼 있다.

가상 프라이빗 게이트웨이 (VGW)

  • VPN 연결에서 AWS 측에 있는 VPN 집선기(concentrator).
  • AWS VPC 엔드포인트
  • VGW는 생성되면 VPC에 연결된다. 
  • ASN을 지정할 수도 있다.

고객 게이트웨이 (CGW)

  • 소프트웨어 혹은 물리적 장치로 VPN 연결에서 온프레미스 측에 속한다.

Site-to-Site VPN Connections

  • 고객 게이트웨이가 있는 온프레미스와 가상 프라이빗 게이트웨이를 갖춘 VPC가 있다고 가정
  • 고객 게이트웨이가 공용이라면 인터넷 라우팅이 가능한 IP 주소가 고객 게이트웨이 장치에 있다.
  • 그럼 고객 게이트웨이의 공용 IP를 사용해서 사용해서 VGW와 CGW를 연결. 
  • 고객 게이트웨이를 비공개로 남겨 사설 IP를 가질 수도 있다.
  • 그런 경우 대부분 NAT-T를 활성화하는 NAT 장치 뒤에 있다.
  • NAT 장치에 공용 IP가 있을 시 이 공용 IP를 CGW에 사용해야 한다.
  • 서브넷의 VPC에서 라우트 전파를 활성화해야 Site-to-Site VPN 연결이 실제로 작동한다
  • 온프레미스에서 AWS로 EC2 인스턴스 상태를 진단할 때 보안 그룹 인바운드 ICMP 프로토콜이 활성화됐는지 확인해야 한다.

AWS VPN CloudHub

  • CloudHub는 여러 VPN 연결을 통해 모든 사이트 간 안전한 소통을 보장
  • 비용이 적게 드는 허브 및 스포크 모델(hub&spoke)로 VPN만을 활용해 서로 다른 지역 사이 기본 및 보조 네트워크 연결성에 사용
  • VPC 내 CGW와 VGW 하나 사이에 Site-to-Site VPN을 생성하게 되는 것
  • 이렇게 연결되면 고객 네트워크는 VPN 연결을 통해 서로 소통할 수 있게 된다,
  • VPN 연결이므로 모든 트래픽이 공용 인터넷을 통한다.
  • 사설 네트워크로는 연결되지 않는다. 공용 인터넷을 통하지만 VPN 연결은 당연히 암호화된다.
  • 설치 방법은 가상 프라이빗 게이트웨이 하나에 Site-to-Site VPN 연결을 여러 개 만들어 동적 라우팅을 활성화하고 라우팅 테이블을 구성하면 된다.

Direct Connect(DX)

  • Direct Connect는 원격 네트워크로부터 VPC로의 전용 프라이빗 연결을 제공
  • Direct Connect를 사용할 때는 전용 연결을 생성해야 하고 AWS Direct Connect 로케이션을 사용
  • VPC에는 가상 프라이빗 게이트웨이를 설치해야 온프레미스 데이터 센터와 AWS 간 연결이 가능
  • 같은 연결상에서 Amazon S3 등의 퍼블릭 리소스와 EC2 인스턴스 등의 프라이빗 리소스에 퍼블릭 및 프라이빗 VIF를 사용해 액세스할 수 있다.
  • Direct Connect를 사용하면 대역폭 처리량이 증가할 때 큰 데이터 세트를 처리할 때 속도가 빨라진다.
  • 퍼블릭 인터넷 연결에 문제가 발생해도 Direct Connect를 사용하면 연결 상태를 유지할 수 있다.
  • 실시간 데이터 피드를 사용하는 애플리케이션에 유용
  • 또 하이브리드 환경을 지원하는데 이는 온프레미스 데이터 센터와 클라우드가 연결되어 있기 때문
  • IPv4와 IPv6 둘 다 지원
  •  만약 다른 리전에 있는 하나 이상의 VPC와 연결하고 싶다면 Direct Connect Gateway를 써야 한다.

Direct Connect 유형

전용 연결 용량

  • 초당 1Gbp 혹은 10Gbp이 한도
  • 고객은 물리적 전용 이더넷 포트를 할당받는다.
  • 먼저 AWS에 요청을 보내면 AWS Direct Connect 파트너가 처리를 완료한다.

호스팅 연결

  • 초당 50Mbp, 500Mbp에서 10Gbp까지 다양하다.
  • AWS Direct Connect 파트너를 통해 또 다시 연결을 요청한다.
  • 필요하면 언제든지 용량을 추가하거나 제거하면 되므로 전용 연결보다는 유연하다.
  • 선택한 로케이션에서 초당 1, 2, 5, 10Gbp 이용이 가능하고 전용 연결이든 호스팅 연결이든 새 연결을 만들려면 리드 타임이 한 달보다 길어질 때도 있다.

암호화

  • Direct Connect에는 암호화 기능이 없어서 데이터가 암호화되지 않지만 프라이빗 연결이므로 보안을 유지할 수 있다.
  • 만약 암호화를 원한다면 Direct Connect과 함께 VPN을 설치해서 IPsec으로 암호화된 프라이빗 연결이 가능하다.
  • 추가로 보안을 확보하면 좋지만 구현이 복잡하다는 단점이 있다.

복원력

  • 핵심 워크로드의 복원력을 높이기 위해서는 여러 Direct Connect를 설치하는 것이 좋다.
  • 가령 기업 데이터 센터가 두 개 있고 Direct Connect 로케이션도 둘이라고 했을 때 중복이 발생
  • 프라이빗 VIF가 하나 있는데 다른 데 또 있다면 하나의 연결을 여러 로케이션에 수립한 것이므로 Direct Connect 하나가 망가져도 다른 하나가 예비로 남아 있기 때문에 복원력이 강해진다. 따라서 핵심 워크로드에 적합
  • 어쨌든 그러려면 각 Direct Connect 로케이션에 독립적인 연결을 두 개씩 수립하면 복원력을 최대로 만들 수 있다.

Transit Gateway

  • 전이적 피어링 연결이 VPC 수천 개와 온프레미스 데이터 센터 Site-to-Site VPN, Direct Connect 허브와 스포크 간 스타형 연결 사이에 생기는 것이다.
  • Transit Gateway를 통해 VPC 여러 개를 연결할 수 있다.
  • VPC를 모두 피어링할 필요가 없으며 Transit Gateway를 통해 전이적으로 연결된다.
  • 모든 VPC가 서로 통신할 수 있는데 Direct Connect Gateway를 Transit Gateway에 연결하면 Direct Connect 연결이 각기 다른 VPC에 직접 연결된다.
  • 만약 Site-to-Site VPN과 VPN 연결을 선호한다면 고객 게이트웨이와 VPN 연결을 Transit Gateway에 연결할 수 있다.
  • 리전 리소스이며 리전 간에 작동한다.
  • Transit Gateway를 계정 간에 공유하려면 Resource Access Manager를 사용하고요
  • 리전 간 Transit Gateway를 피어링할 수도 있다.
  • Transit Gateway에 라우팅 테이블을 생성해서 어느 VPC가 누구와 통신할지 어떤 연결이 액세스할지 제한한다.
  • Transit Gateway 내 모든 트래픽 경로를 제어해서 네트워크 보안을 제공하는 것이다.
  • Direct Connect Gateway 및 VPN 연결과 함께 작동하고 AWS에서 유일하게 IP 멀티캐스트를 지원하는 서비스로 만약 시험에 IP 멀티캐스트가 나오면 Transit Gateway를 사용해야 한다.

Site-to-Site VPN ECMP

  • 등가 다중 경로 라우팅을 뜻하는 ECMP는 여러 최적 경로를 통해 패킷을 전달하는 라우팅 전략
  •  Site-to-Site VPN 연결을 많이 생성해서 AWS로의 연결 대역폭을 늘릴 때 사용

트래픽 미러링

  • VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 기능
  • 관리 중인 보안 어플라이언스로 트래픽을 라우팅
  • 따라서 트래픽을 수집해 수집하려는 트래픽이 있는 소스 ENI를 정의
  • 또한 어디로 트래픽을 보낼지 대상을 정의해야 한다. (ENI나 NLB)
  • 모든 정보가 아닌 일부만 얻고 싶다면 선택적으로 필터를 사용할 수도 있다.
  • 동일한 VPC에 소스와 대상이 있어야 한다.
  • 다른 VPC에 걸쳐 있기도 한데,  VPC 피어링을 활성화한 경우
  • VPC 트래픽 미러링 사용 사례로는 콘텐츠 검사와 위협 모니터링 네트워킹 문제 해결 등이 있다.

IPv6 in VPC

  • VPC에서 IPv6 지원을 활성화할 수 있다.
  • VPC와 서브넷에서 IPv4 비활성은 불가능.
  • IPv6를 활성화할 수 있다. 공용 IP 주소이며 듀얼 스택 모드로 작동합
  • EC2 인스턴스가 VPC에서 실행되면 최소 사설 내부 IPv4 하나와 공용 IPv6 하나를 얻게 되고 IPv4나 IPv6를 사용해서 인터넷 게이트웨이를 통해 인터넷에 통신할 수 있다.
  • 시험 팁: 실행을 거듭해서 IPv4 공간이 전부 소진된다면 사용자가 새 EC2 인스턴스를 생성할 시 오류가 발생한다. IPv6 때문이 아니라 서브넷이나 VPC에 IPv4 공간이 없으므로 이런 경우에는 서브넷의 VPC에 새로운 CIDR를 추가하면 된다.
  • 새 EC2 인스턴스를 시작하고 해당 IP를 위한 다른 IPv4 주소 범위를 얻도록

이그레스 전용 인터넷 Gateway

  • IPv6 트래픽에만 사용되며 NAT Gateway와 비슷하지만 IPv6 전용
  • VPC 인스턴스에서 IPv6상 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결을 시작하지 못하게 막는다.
  • 그러려면 라우팅 테이블을 업데이트해야 한다.

정리

  • CIDR는 IP 범위
  • VPC는 가상 사설 클라우드로 IPv4와 IPv6용으로 작동한다.
  • 서브넷은 CIDR가 정의된 AZ에 연결되며 공용 및 사설 서브넷이 있다.
  • 공용 서브넷을 구축하려면 인터넷 게이트웨이를 연결해서 공용 서브넷에서 인터넷 게이트웨이로 경로를 만들면 된다. 활성화되면 IPv4 및 IPv6에 인터넷 액세스를 제공
  • 라우팅 테이블은 대체 게이트웨이나 VPC 피어링 연결 VPC 엔드 포인트로 향하는 라우트를 갖도록 편집되고 네트워크가 VPC 내부에서 흐르도록 돕는 중요한 기능
  • 배스천 호스트는 공용 EC2 인스턴스로 SSH를 수행하며 사설 서브넷의 다른 EC2로 SSH 연결을 사용할 수 있다.
  • NAT 인스턴스는 EC2 인스턴스이며 사설 및 공용 서브넷에 배포되어 사설 서브넷의 EC2 인스턴스에 인터넷 액세스를 제공한다. 오래돼서 더는 사용하지 않는다. 소스/목적지 검사 플래그를 비활성화해야 작동한다. 또 보안 그룹 규칙을 수정해야 한다.
  • 지금은 NAT Gateway를 쓴다. 성능이 훨씬 좋고 AWS에서 관리한다. 사설 EC2 인스턴스에 확장 가능한 인터넷 액세스를 제공하고 IPv4에서만 작동한다.
  • Route 53를 통해 사설 DNS를 쓰려면 DNS 변환과 DNS 호스트 이름 설정을 VPC에서 활성화해야 한다. 활성화할 설정이 총 두 개
  • NACL은 네트워크 ACL은 방화벽 규칙이다.
  • 인바운드와 아웃바운드 액세스를 서브넷 레벨에서 정의한다. 임시 포트 NACL이 무상태이므로 인바운드와 아웃바운드 규칙이 항상 평가된다.
  • 반면 보안 그룹 규칙은 상태가 유지된다. 인바운드 허용 시 아웃바운드도 바로 허용되고 반대로도 마찬가지다.  또한 보안 그룹 규칙은 EC2 인스턴스 레벨에서 적용됩니다
  • VPC Reachability Analyzer는 여러 AWS 리소스 사이에서 네트워크 연결을 시험하고 디버깅을 수행한다.
  • VPC 피어링은 두 VPC를 연결할 때 유용한데 CIDR가 겹치지 않는 경우에만 가능
  • VPC 피어링 연결은 비전이적이므로 VPC 세 개를 연결하려면 VPC 피어링 연결도 세 개가 필요하다.
  • VPC 엔드 포인트는 AWS 서비스에 사설 액세스를 제공하는데 Amazon S3, DynamoDB CloudFormation, SSM 등 VPC 내 모든 서비스에서 가능하다.
  • Amazon S3와 DynamoDB를 위한 게이트웨이 엔드 포인트로 사용되고 나머지는 모두 인터페이스 엔드 포인트.
  • VPC 플로우 로그는 VPC 내 모든 패킷과 관련해 일정 레벨의 메타데이터를 얻는 방법
  • ACCEPT 및 REJECT 트래픽 정보가 있다. VPC 플로우 로그는 VPC 서브넷이나 ENI 레벨에서 생성할 수 있으며 분석 과정 후 Amazon S3로 전송된다.
  • 이어서 Athena로 분석하거나 CloudWatch Logs로 보내 CloudWatch Logs Insights로 분석하기도 한다.
  • VPC를 데이터 센터에 연결하려면 두 가지 옵션이 있는데 먼저 Site-to-Site VPN은 공용 인터넷을 지나는 VPN 연결로 AWS에는 가상 프라이빗 게이트웨이를 데이터 센터에는 고객 게이트웨이를 생성하고 나서 VPN 연결을 구축한다.
  • 가상 프라이빗 게이트웨이를 사용해 VPC 연결을 여러 개 생성하려면 VPN CloudHub를 활용해서 허브와 스포크 간 VPN 모델로 사이트에 연결한다.
  • 데이터 센터에 연결하는 또 다른 방법은 Direct Connect를 사용해 완전히 비공개로 연결하는 것이다. 공용 인터넷을 통과하지 않는데 구축하는 데 시간이 걸린다. 데이터 센터를 Direct Connect 로케이션과 연결해 줘야 작동한다.
  • Direct Connect Gateway는 다양한 AWS 리전의 수많은 VPC에 Direct Connect를 설정한다.
  • PrivateLink 또는 VPC 엔드 포인트 서비스는 고객 VPC에 만든 자체 VPC의 내부 서비스에 비공개로 연결되며 장점을 꼽자면 VPC 피어링, 공용 인터넷 NAT Gateway 라우팅 테이블은 필요 없다.
  • 네트워크 로드 밸런서와 ENI만 주로 함께 사용된다.
  • VPC가 있는 서비스를 수백, 수천 고객 VPC에 노출할 수 있다. 네트워크를 드러내지 않은 채
  • Transit Gateway는 VPC와 VPN Direct Connect를 위한 전이적 피어링 연결. 모두 이곳을 지난다는 게 장점
  • 트래픽 미러링이란 추가 분석을 위해 ENI 등에서 네트워크 트래픽을 복사하는 것

Network Firewall

  • 전체 VPC를 보호할 수 있는 수준 높은 방법은 AWS Network Firewall 이는 전체 VPC를 방화벽으로 보호하는 서비스로 VPC가 있으면 이 전체에 방화벽을 두르는 것이다.
  • AWS Network Firewall은 계층 3에서 계층 7까지 보호하는데 모든 방향에서 들어오는 모든 트래픽을 검사한다.
  • VPC 간 트래픽 인터넷 아웃바운드, 인터넷 인바운드 Direct Connect나 Site to Site VPN 연결까지 포함된다.
  • 규칙을 정의하기만 하면 모든 동작을 제어할 수 있다.
  • 내부적으로 Network Firewall은 AWS Gateway Load Balancer를 사용한다.
  • 단, 타사 어플라이언스가 아니라 AWS에서 자체 어플라이언스를 통해 트래픽을 관리하므로 Network Firewall에 자체 규칙을 갖추고 있다.
  • 이 규칙들 역시 중앙 집중식으로 관리되며 여러 계정과 VPC에 적용된다.
  • Network Firewall에서는 네트워크 트래픽을 세부적으로 관리한다.
    • VPC 수준에서 수천 개의 규칙을 지원하고 수만 IP를 IP와 포트별로 필터링할 수 있다.
    • 프로토콜별로도 필터링할 수 있다. 아웃바운드 통신에서는 SMB 프로토콜을 비활성화하는 식으로
    • 도메인별로도 필터링할 수 있어서 VPC의 아웃바운드 트래픽에 대해서는 기업 도메인에만 액세스를 허용하거나 타사 소프트웨어 리포지토리에만 액세스를 허용할 수도 있다.
    • regex 등을 이용해서 일반 패턴 매칭도 가능
    • 트래픽 허용, 차단, 알림 등을 설정해서 설정한 규칙에 맞는 트래픽을 필터링할 수도 있다.
    • 활성 플로우 검사를 통해 침입 방지 능력을 갖출 수 있다.
  • 모든 규칙 일치는 Amazon S3와 CloudWatch Logs 및 Kinesis Data Firehose로 전송해 분석할 수 있다.
  • 방화벽은 VPC 수준에서 설정할 수 있다는 점이 중요하고, 트래픽 필터링과 플로우 검사를 지원한다는 점도 중요하다.
반응형

티스토리툴바