728x90
반응형




CIDR (Classless Inter-Domain Routing)

  • CIDR (Classless Inter-Domain Routing) : ip주소를 할당하는 방법 (ex. 122.149.196.85/32, 0.0.0.0/0 등)


  • 구성요소

  1. Base IP

  2. Subnet Mask


  3. Private IP : IANA (The Internet Assigned Numbers Authority)에서 생성한 IP 주소

    • AWS VPC Private IP : 172.16.0.0 ~ 172.31.255.255 (172.16.0.0/12)
    • Home networks : 192.168.0.0 ~ 192.168.255.255 (192.168.0.0/16)


Default VPC

  • 특징
  1. AWS 계정은 Default VPC가 1개씩 있음
  2. EC2 인스턴스를 생성할 때, 서브넷을 지정하지 않으면 기본 VPC에 생성됨
  3. 처음부터 인터넷에 연결되어 있음 -> 해당 VPC에 생성되는 EC2는 public IP, public/private DNS를 할당받게 됨


VPC

  • 특징
  1. 단일 region에 여러 VPC 생성 가능 (region당 최대 5개)
  2. VPC마다 CIDR 5개 할당
  3. 각 CIDR의 최소크기는 /28, 최대크기는 /16
  4. VPC내부에서는 private IP만 허용
  5. VPC에 CIDR설정 시, 다른 VPC네트워크나 기업 네트워크와 겹치지않도록 주의해야 함


Subnets

  • Subnets : VPC 내부에 있는 IP주소 범위의 일부


  • 특징

  1. Subnet마다 AWS가 IP주소 5개를 미리 지정함 (처음 4개, 마지막 1개) -> 해당IP는 사용도 안되고 인스턴스에 할당도 안됨
    • 첫번째 : Network Address
    • 두번째 : VPC Router용
    • 세번째 : Amazon 제공 DNS에 매핑
    • 네번째 : 예비
    • 마지막 : 브로드캐스트용 (실제로 사용은 불가)
  2. public Subnet크기는 작을수록 좋음


Internet Gateway

  • Internet Gateway : Subnet에 인터넷을 연결하기 위한 EC2 또는 Lambda


  • 특징

  1. 수평 확장 가능
  2. 가용성 및 중복성이 좋음
  3. VPC와 별도 생성 필요
  4. 하나의 VPC는 하나의 Internet Gateway만 연결 가능
  5. Internet Gateway에 Internet을 허용하기 위해 별도 설정 필요 -> EC2인스턴스에 public IP 자동할당해도 Internet Gateway가 없으면 인터넷 연결 불가
  6. Subnet내부의 인스턴스와 Internet Gateway를 연결하기 위해 라우팅 테이블 설정 필요 -> EC2 인스턴스와 라우터 연결 후, 해당 라우터를 Internet Gateway에 연결
    • 라우팅 테이블 생성 후, 서브넷에 할당
    • 라우팅 테이블에서 인터넷상 모든 IP를 Internet Gateway에 연결




Bastion Hosts

  • Bastion Hosts : Bastion Host라는 보안 그룹으로 설정된 public subnet에 있는 EC2 인스턴스 -> 동일 VPC 내부의 private subnet의 EC2에 접근하기 위함




  • 특징
  1. Bastion Host 보안 그룹은 반드시 인터넷 엑세스를 허용해야 함
  2. private Subnet 내부의 보안 그룹은 Bastion Host의 트래픽을 허용해야 함


NAT Instance (구형)

  • NAT : Network Address Transition
  • NAT Instance : private Subnet상의 EC2 인스턴스가 인터넷에 연결될 수 있도록 허용




  • 특징
  1. public Subnet에서 실행되어야 함
  2. Source/Destination Check 비활성화 필요 -> NAT 인스턴스에서 네트워크 패킷을 재작성해야하기 때문
  3. Elastic IP 할당 필요 -> VPC 외부로 트래픽이 전달될 때, Source IP가 할당된 Elastic IP가 됨 -> NAT 인스턴스의 네트워크 패킷 재작성
  4. 라우팅 테이블을 수정하여 public/private Subnet 상의 EC2 트래픽이 NAT 인스턴스로 전송되도록 함 -> Destination이 어디일 때, Target으로 NAT Instance 설정
  5. 현재는 NAT Gateway 서비스 권장 -> 가용성이 좋지 않기 때문
  6. 보안그룹 및 규칙 관리 필요
  7. EC2 인스턴스로 생성할 때, NAT 전용 AMI가 있음


NAT Gateway

  • NAT Gateway : AWS 관리형 NAT Instance


  • 특징

  1. 고가용성
  2. 관리할 필요 없음
  3. 특정 AZ에 생성되고 Elastic IP를 할당받음
  4. EC2 인스턴스와 같은 Subnet에서 사용할 수 없음 -> 다른 Subnet에서 접근할 때 도움됨
    • 일반적인 case : Private Subnet -> NAT Gateway -> Internet Gateway
  5. 대역폭은 초당 5Gbps, 최대 45Gbps까지 확장 가능
  6. 보안그룹 관리 필요 x
  7. private Subnet의 Route Table을 수정하여 트래픽이 NAT Gateway로 갈 수 있게끔 설정




  • NAT Gateway의 고가용성
  1. 단일 AZ에서 복원 가능 -> AZ가 중단되었을 경우를 대비하여 Multi-AZ 배치 가능
  2. Multi-AZ일 때, AZ간 서로 연결할 필요 없음




  • NAT Gateway vs NAT Instance




Security Groups and NACL (Network ACL)

  • NACL : Subnet 보안 Level, Subnet을 오가는 트래픽을 제어하는 방화벽이라 보면될 듯


  • Incoming Request : 요청이 Subnet으로 들어가기 전에 NACL로 이동 (요청이 허용되지 않으면 Subnet으로 못들어감) -> NACL을 통과하면 Security Group 인바운드 규칙 검증

  • Outbound Request : Security Group 아웃바운드 규칙 검증 -> Security Group을 통과하면 NACL 아웃바운드 규칙 검증




  • 특징
  1. NACL은 무상태 Security Group은 상태유지 -> Inbound 규칙이 허용되면 Outbound 규칙은 자동으로 허용됨 (상태유지) -> NACL Outbound 규칙은 검증 필요 (무상태)
  2. Subnet마다 1개의 NACL 할당 -> 새로운 Subnet 생성 시, Default NACL 할당
  3. NACL의 우선순위는 index가 낮을수록 높음
  4. Subnet 수준에서 특정 IP를 제한하는 데 적합함
  5. 우선순위가 높은 Rule중 맞는 Rule이 있다면, 후순위의 Rule은 검증하지 않음
  6. 마지막 우선순위 Rule은 모든 요청을 제한하는 Rule


  • Default NACL
  1. 인바운드와 아웃바운드에 대한 모든 요청을 허용
  2. 수정하지 않는 것을 권장


  • 임시포트
  1. 클라이언트는 규정된 포트로 접근 (ex. HTTP : 80)
  2. 서버가 클라이언트에 응답을 주려면 포트가 있어야하는데, 클라이언트는 기본적으로 개방된 포트가 없어서 클라이언트가 서버에 접속할 때 자체적으로 특정 포트를 열게됨 -> 임시포트, 연결되는 동안만 열려있음
  3. 운영체제에 따라 임시포트의 범위는 달라짐 (ex. Windows 10 : 49152 ~ 65535)




  • NACL with 임시포트
    : client측에서 server의 응답을 받기 위해 client측 Subnet Inbound Rule에 임시포트 범위를 허용하고, server측 Subnet Outbound Rule에 임시포트 범위를 허용해야 함




  • Security Group vs NACL




VPC Peering

  • VPC Peering : 다양한 region/계정에서 생성되는 VPC를 AWS 네트워크를 통해 연결하고 싶을 때 활용 -> 연결되는 VPC가 모두 같은 네트워크에 있을 수 있도록 함


  • 특징

  1. VPC Peering이 필요하다면 CIDR이 겹치지않도록 설정해야 함
  2. VPC Peering은 무조건 직접 연결되어 있어야 함
  3. VPC Peering 이후 Subnet마다 Route Table을 업데이트 해야 Subnet 내부의 EC2 인스턴스간 통신이 가능해짐
  4. 다른 계정간에도 통신 가능
  5. Security Group 참조 가능




VPC Endpoints

  • VPC Endpoints : AWS 네트워크를 통해 VPC에서 AWS 서비스를 이용할 수 있도록 해주는 서비스




  • 특징
  1. public internet이 아닌 AWS 네트워크를 통해 AWS 서비스 접근 가능 (AWS PrivateLink)
  2. 거쳐가는 노드가 적기 때문에 internet보다는 비용 효율적
  3. 에러 발생 시, VPC DNS 설정이나 Route Table 확인하면 됨


  • Types of Endpoints
  1. Interface Endpoints (PrivateLink)
    • ENI 프로비저닝
    • ENI : VPC의 Private IP Address, AWS의 Entry Point -> Security Group 설정 필요
    • ENI 비용 청구는 시간 단위의 데이터 처리량에 따라 달라짐
  2. Gateway Endpoints
    • Gateway 프로비저닝
    • Gateway는 Route Table의 대상 (IP or Security Group or Gateway)
    • Amazon S3와 DynamoDB에 활용 가능 -> 해당 서비스에서 Interface Endpoint가 권장되는 경우는 온프레미스 or 다른 VPC에 접근해야할 경우
    • 요금은 무료
    • Auto Scale 가능 -> Route Table만 수정하면 됨




VPC Flow Logs

  • VPC Flow Logs : Interface로 들어오는 IP 트래픽에서 정보를 확인할 수 있음 (VPC/Subnet/ENI level)


  • 특징

  1. S3, CloudWatch Logs, Kinesis Data Firehose에 전송 가능
  2. AWS 서비스로의 트래픽으로부터 정보를 캡처 (ELB, RDS, ElastiCache, Redshift, NATGW 등)
  3. VPC Flow Logs에 쿼리하는 방법 : Athena + S3, CloudWatch Logs Insights (스트리밍 분석)


  • VPC Flow logs Syntax




  • VPC Flow logs를 이용하여 Security Group과 NACL issues 해결하는 방법
  1. ACTION 필드 확인
    • Inbound REJECT : 외부로부터 EC2 인스턴스로 들어오는 트래픽이 제한됨 -> NACL or SG이 거부
    • Inbound ACCEPT, Outbound REJECT : NACL issue -> SG는 상태유지


  • VPC Flow logs Architecture




Site-to-Site VPN

  • Site-to-Site VPN : AWS 외부 온프레미스 Data Center와 VPC를 private으로 연결하기 위한 VPN




  • 특징
  1. public internet을 거치지만, VPN연결이므로 암호화되어 있음
  2. 필요한 것
    • Virtual Private Gateway (VPG) : VPN역할을 하는 Gateway로 VPC에 연결됨
      • 해당 Subnet Route Table의 Route Propogation 활성화 필요
    • Customer Gateway (CGW) : VPN에 연결하기 위한 고객측 Gateway -> AWS에서 생성
      • IP주소 확인 (VPG와 연결할 용도) -> private으로 유지하고 싶다면 NAT 장치를 활용하게 됨 (NAT 장치의 IP가 public용도로 활용됨)


  • AWS VPN CloudHub
  1. 여러 VPN연결을 통해 안전한 통신을 보장
  2. 저비용의 Hub&Spoke 모델
  3. 고객 네트워크 간에도 VPN을 통해 통신 가능
  4. 모든 트래픽은 public internet을 경유
  5. 방법 : VGW에 여러 VPN연결을 생성한 후에 동적 Routing을 활성화하고 Route Table을 설정하면 됨




Direct Connect (DX)

  • Direct Connect (DX) : 사설 Data Center에서 VPC로의 전용 private connect 제공




  • 특징
  1. 방법 : VPC에 Virtual Private Gateway (VPG) 생성 -> Direct Connect (DX) 생성 -> 외부 온프레미스에서 DX를 통해 private AWS Resource 접근 가능
  2. public internet을 거치지 않음
  3. 큰 데이터를 처리할 때 속도가 빠름
  4. 비용 절약 가능
  5. IPv4, IPv6 모두 지원
  6. private resource에 접근할 때에는 Private Virtual Interface 사용
  7. public resource에 접근할 때에는 Public Virtual Interface 사용
  8. 암호화 기능이 없지만, private 전송은 보장됨 -> 암호화가 필요할 경우, DX + VPN 결합 방법이 있음


  • Direct Connect Gateway
    : 다른 region에 있는 하나 이상의 VPC와 연결해야할 때 활용




  • Connection Types : 연결을 새로 만들 때, 최소 한달이상 걸림
  1. Dedicated Connection
    • 1Gbps ~ 100Gbps 용량
    • 물리적 전용 이더넷 포트 할당
  2. Hosted Connection
    • 50Mbps ~ 10Gbps 용량
    • 필요 시, 용량을 증설하거나 감축시킬 수 있음


  • Resilincy (복원력)
    : Multiple DX 설치 (Multiple Connection Location and Multiple Connection)




  • VPC + DX의 backup
    : VPC, DX 둘 중 하나가 문제가 생기면 서로 전환하면서 장애복구 가능




Transit Gateway

  • Transit Gateway : 여러 VPC를 연결하기 위한 Gateway -> VPC간 peering 때문에 야기되는 복잡한 AWS 네트워크 토폴로지를 보완 (mesh -> 중앙집중형?)


  • 특징

  1. region간 활용 가능
  2. 계정간 활용 필요할 시에는 Resource Access Manager 설정
  3. Transit Gateway의 Route Table을 통해 Routing 설정 가능
  4. AWS 유일 IP Multicast 지원




  • Use case1 : ECMP 활용하여 Site-to-Site VPN 대역폭 늘리기
    => ECMP (Equal-cost multi-path, 여러 최적 경로를 통해 패킷을 전달하는 Routing 전략) : Site-to-Site VPN을 활용할 때 VPC에 있는 두 개의 터널중 하나만 사용하지만, Transit Gateway를 경유하는 경우에는 두 개의 터널을 동시에 사용함 (Transit Gateway의 전이특성 때문) -> Transit Gateway를 이용하면 다수의 VPN을 만들 수 있고, 두 번째 VPN을 만드는 경우에는 4개의 터널이 생김 -> 연결 처리량 증가




  • Use case2 : 계정간 Direct Connect (DX) 공유 (Transit Gateway의 계정 공유 특성 활용)




Traffic Mirroring

  • Traffic Mirroring : VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 기능




  • 특징
  1. 관리중인 Security Appliance대로 트래픽을 라우팅 (Traffic Mirroring Routing 설정) -> 수집하려는 트래픽이 있는 Source측 ENI 정보를 정의하고, 어디로 트래픽을 보낼지 Target ENI or NLB 정의해야 함 -> Target에는 트래픽을 분석하는 Software가 있음


VPC용 IPv6

  • IPv6 특징
  1. private 전용 ip가 따로 있진 않음


  • 특징
  1. private IPv4 주소, public IPv6 주소를 만들어 동시에 사용 가능


Egress-only Internet Gateway (송신 전용)

  • Egress-only Internet Gateway : IPv6 아웃바운드 연결을 허용하고 동시에 인터넷이 인스턴스로 IPv6 연결이 불가하도록 제한함




  • 특징
  1. IPv6 트래픽에만 사용 가능
  2. 라우팅 테이블 업데이트 필요


  • IPv6 라우팅




AWS 네트워크 비용

  1. public internet 보단 private AWS 인프라가 네트워크 비용이 절감됨
  2. 동일 가용영역 내에서는 네트워크 비용 무료




  1. AWS에서 public으로 보내는 트래픽은 비용발생
  2. public에서 AWS로 들어오는 트래픽은 무료




  1. Transfer acceleration 기능은 추가비용 발생
  2. S3 -> CloudFront 비용은 무료
  3. CloudFront에서 인터넷으로 보내는 비용(GB당 0.085달러)이 S3에서 인터넷으로 보내는 비용(GB당 0.09달러)보다 저렴




  1. NAT Gateway vs Gateway VPC Endpoint




AWS Network Firewall

  • AWS에서 제공하는 네트워크 보호 방법
  1. NACL
  2. VPC Security Group
  3. AWS WAF (취약점 공격 보호)
  4. AWS Sheild (DDoS 공격 보호)
  5. AWS Firewall Manager


  • AWS Network Firewall : VPC의 Inbound/Outbound 트래픽을 모두 감시함




  • 특징
  1. 내부적으로 AWS Gateway Load Balancer 사용
  2. 네트워크 3계층부터 7계층까지 모두 보호
  3. 여러 계정과 여러 VPC에 모두 적용
  4. 수천개의 규칙을 생성할 수 있음
  5. IP/Port/Protocol/도메인별 필터링 가능
  6. 패턴매칭 방식으로 필터링 가능
반응형

'개발 > AWS' 카테고리의 다른 글

[AWS] AWS 보안 및 암호화  (1) 2024.06.30
[AWS] IAM 고급  (0) 2024.06.25
[AWS] CloudWatch and CloudTail  (1) 2024.06.11
[AWS] AWS Database  (0) 2024.06.08
[AWS] Serverless (Lambda/DynamoDB/API Gateway)  (1) 2024.06.08

+ Recent posts