VPC: 논리적으로 격리된 가상의 네트워크 영역
SubNet: 논리적으로 격리된 가상의 네트워크 영역을 부분적으로 나누어 놓은 하위 네트워크 영역
InternetGateWay: VPC와 Internet을 연결해주는 요소(관문)
RouteTable: 트래픽의 이동 경로를 규칙이 설정되어 있는 테이블

• IPAM-allocated IPv4 CIDR block : 아마존 VPC IP 관리자 주소 서비스 사용 여부
• Tenancy : 이 VPC에서 EC2 인스턴스 만들때 전용 하드웨어 사용할지 여부

• Enable ENS HostName : VPC 안에서 만들어지는 리소스가 Public DNS HostName을 수신하는지 여부 체크

인터넷게이트웨이

• VPC 내부에 있는 리소스가 외부와 통신하기위해 필요한것

• VPC와 IGW 를 연결 해줘야 Attached 상태가됨(사용가능)

서브넷

• 서브넷은 VPC의 IP대역을 나누는 것이기 떄문에 이 VPC 하위네트워크인 서브넷을 만들때는 이 서브넷의 CIDI블록이 VPC의 CIDI블록보다 작아야 함

EC2

• 키페어 : ec2에 접속하기 위한 키

• auto-assign public Ip : 자동으로 퍼블릭 IP 지정 여부
  

• 인바운드 설정 ( 몇번 포트로 접속요청 허용할것인지)

• 생성된 ec2에다 Elastic IP로 public IP 할당해주기
• Elastic Ip에 연결하고자 하는 private Ip가 있는경우 설정 가능
• Reassociation : EIP 가 이미 리소스에 연결되어 있는 상태에서 다른 리소스에 연결하면 에러남 그때 강제로 EIP를 가져와 연결하는 설정

라우트 테이블

• vpc-igw 처럼, 라우트 테이블도 어떤 서브넷의 경로를 설정해줄지 정해야한다.

• edit subnet assiciation

• Destination : 트래픽이 이동하고자 하는 목적지
• Target: destination으로 트래픽 전송시 사용하는 네트워크 연결요소

• 외부로 향하는 트래픽은 igw를 통해 내보낸다는 뜻

ssh 접속(mac)

• 윈도우는 putty를 통해 pem키 변환하구 등등 복잡하다 하지만 맥은 간단하다
  

• ami default user name

• pem 키 위치에서 ssh -i pem키 userName@public ip

• 외부로 통신가능한 Ec2 완성

SecurityGroup

• 인스턴스 레벨에서 네트워크 트래픽을 제어하기 위한 보안 요소
  

• sg에서 인스턴스내부로 들어오는 트래픽을 허용할지 안할지 설정 가능하다(인바운드)

• 시큐리티 그룹은 트래픽의 상태와 정보를 저장하는 Stateful 특성을 가지고 있기때문에 한번 인바운드 룰의 검증을 통과하여 들어간 트래픽은 다시 시큐리티 그룹을 나올때 아웃바운드 룰에 관계 없이 통과가능(= 아웃바운드 룰이 없어도 통과 가능)

• 하지만 아웃바운드 룰이 없는상태에서 ec2안에서 외부와 통신을 시도하면 (ping google.com) 아웃바운드 룰이 없기때문에 통신이 안된다.

NACL

• subnet 레벨에서 네트워크 트래픽을 제어하기 위한 보안요소
  

• nacl 은 따로 설정하지 않아도 vpc - subnet을 만들면 자동으로 연결된다.

SG vs NACL

• sg와 다르게 우선순위가 있다. 룰넘버가 낮을수록 우선순위가 높은것

• sg는 허용하는것 빼고는 자동으로 거부지만 nacl에서는 allow와 deny로 설정 가능

• sg와 다르게 nacl은 트래픽의 상태와 정보를 저장하지 않는 stateless 라는점 그래서 인바운드 룰을 통과해도 아웃바운드 룰을 따로 통과해야함!

Elastic IP

• 고정적인 Public Ip 주소를 할당해주는 서비스
  

• Disassociation ,association으로 자유롭게 ip를 다른 인스턴스에 결 할 수 있다.

Elastic Network Interface

• 네트워크 연결을 제어하고 구성하는 가상의 인터페이스

• 인스턴스가 만들어질때 자동으로 만들어 진다.

• eni는 영역단위로 동작하기 때문에 특정 가용영역에서 생성하면 해당 가용영역에서 생성하는 리소스에서만 사용 가능, 즉 다른 영역에서 생성된 인스턴스에 접근 불가

• IPv4 prefix delegation : IPv4 주소를 그룹처럼 모아놓은 프리픽스를 자동으로 할당함으로써 eni를 생성할때 IPv4 충돌을 방지함

• Idle connection tracking timeout : 연결상태가 유휴 상태일때 얼마동안 유지될지를 설정

• 새로만든 eni + sg를 vpc와 인스턴스에 적용시킨다

• 예전(기본으로 생성되는)eni 에 붙어있다.
  
  

• eip에서 떼고 다시 새롭게 붙여주자
  

• 이렇게 해야 새로운 http접속 방식이 적용된다.(eni+eip+sg)

-> eni를 다른 인스턴스에 연결하면 동일한 ip지만 다른 인스턴스에서도 사용 가능하다

-> public ip를 포함한 인스턴스의 네트워크 연결 정보는 인스턴스 자체에 설정되는 것이 아니라 네트워크 인터페이스에 설정이 되고 네트워크 인터페이스의 연결 정보를 통해 인스턴스와 통신을 할 수 있다.

Application Load Balancer

• 네트워크의 부하를 분산시키는 서비스인 Elastic Load Balancer의 한 종류

TargetGroup

• 로드밸런스를 통해 트래픽을 받는대상

• 여기서 protocol은 어플리케이션 로드밸런스와 타켓이 되는 인스턴스 사이의 통신 설정, 여기서는 타겟이 이 포트의 설정만 받겠다라는 뜻

• 타켓인스턴스 헬스체크

• 로드 밸런스의 트래픽을 받을 인스턴스 선택

• 타겟 그룹으 만들었지만 아직 로드밸런서가 없어 실질적으로 사용하지 않는 상태라 Unused가 2인 상태

• internet-facing이면 로드밸런스가 인터넷과 통신하기 때문에 여기서 선택한 서브넷 라우트 테이블은 인터넷게이트웨이를 통해 외부와 통신가능한 상태여야 한다

ALB생성

• 외부에서 들어온 트래픽을 분산시키는거라 Internet-facing을 선택 해준다.

• alb sg도 하나 생성해 준다.

• 리스너가 로드 밸런서로들어온 트래픽을 받아서 어느 타겟그룹으로 갈지 결정한다

ALB 경로기반 라우팅

• 똑같이 targetgroup 만들고 타겟그룹에 특정 인스턴스 등록후

• 로드밸런스 -> 리스너 -> edit listner -> add rules

• 다양한 컨디션들중 선택(여기서는 경로기반)

• 알맞은 액션 선택 후

• 경로기반 alb 특정 라우팅 완성

• 결과를 보면 특정 조건 a1 경로로오면(condition) 특정 tg 타겟 그룹으로 트래픽을 보낸다. 위에서 타겟그룹 생성하고 특정 인스턴스에 걸어뒀기 때문에 alb에 특정조건에 따라 특정 인스턴스에 트래픽이 간다.

ALB 고정세션 라우팅

• 일정시간 동안 고정된 타겟으로 라우팅 시키는 방법

• 타겟그룹 -> attribute -> edit
  

• alb에서 나온 쿠키를 기반으로 세션을 고정시킬지 아니면 서버에서 제공하는 어플리케이션에서 나온 쿠키를 기반으로 세션을 고정시킬지(일반적으로 첫번째꺼 사용)

• 밑에 옵션을 얼마나 고정 시킬지

NAT

• 사설 네트워크에서 public ip와 통신하기 위해 사용되는 네트워크 기술
• private ip를 public ip로 or public ip를 private ip로 변환

NAT 게이트웨이 vs NAT 인스턴스

• 둘다 private subnet에 있는 인스턴스를 외부와 통신할 수 있게 해준다

• 인스턴스는 sg 등등 해줘야 하는것도 많고 리소스가 많이든다. 하지만 트래픽이 크지 않으면 비용이 저렴함

• 게이트웨이는 이런 번거로운 작업을 aws에서 해주지만 비용이 크다.

  
  

• 예전에 만들었던 public 라우터 테이블은 igw와 연동되 외부와 통신가능

• 하지만 private으로 만든 라우터 테이블은 외부와 통신이 불가능

NAT GateWay활용

• 새롭게 생성된 private subnet에 인스턴스를 생성해준다

• public 인스턴스에서 -> private 인스턴스에 접속하기위해 public 인스턴스에 pem키를 만들어주고 그걸 이용해 private에 접속해준다

• 이때 public 인스턴스는 private에 들어가기 위한 중계서버 역활을 하는데 이걸 BastionHost라고 부른다
  

• private 서브넷에 연결된 라우터테이블은 외부와 통신할수있는 igw와 연결되 있지 않기 때문에 외부와 통신이 안된다.

• NAT gateway 생성시 서브넷은 외부와 통신 가능한 서브넷이여야 함

• Elastic IP allocation ID : NAT gateway에 ip할당

• 이제 이 NAT gateway를 private 라우터테이블에 적용시켜 통신 가능 하도록 만들어준다

• 외부통신 가능

• 프라이빗 서브넷의 라우트 테이블 경로에 따라서 트래픽이 NAT 게이트웨이로 보내지고 이 트래픽은 다시 퍼블릭 서브넷의 라우터 테이블 경로에 따라서 인터넷 게이트웨이를 통해 웹으로 나가게되고 통신이 가능해진것

VPC EndPoint

• VPC EndPoint: VPC와 AWS의 서비스를 외부 인터넷을 통하지 않고 연결해주는 서비스
  1.Gateway EndPoint: 특정 IP대역을 Route table을 참조하여 AWS 서비스와 연결 (s3 , DynamonoDB)
  2.Interface Endpoint: ENI의 네트워크 연결 정보를 통해 AWS 서비스와 연결(API Gateway, SNS )

• AWS CloudFormation: AWS 인프라를 코드로 생성 및 관리하는 서비스
• AWS CLI : 명령을 사용하여 AWS의 서비스와 통신할 수 있는 도구

• s3와 cloudFormation 에 Ec2가 접근할 수 도록 role을 만든다.

• private 인스턴스를 아마존 서비스에 연결시킬 예정이라 private 인스턴스에 방금만든 role을 적용 시켜준다.

CLI

• 오른쪽 상단Security credentials -> access key 생성

• private instance 에서 aws configure 명령어 입력후 accesskey 입력

-> 이상태에서 외부 s3와 통신을 하면 통신이 private라 통신이 불가함. endpoint 필요

Gateway endPoint 생성

• service 영역에서는 tpye이 gateway인걸 선택

• private 서브넷의 인스턴스와 s3를 연결할꺼니까 private subnet 선택

• 그러면 private subnet rt에 pl-blabla가 생긴다(특정 IP로 트래픽을 열어주는것)

• destination pl-blabla를 열어보면 서울리전의 s3가 사용하는 public ip들이 있다.

• 타켓에는 우리가 만든 s3가 있다.

->즉, private subnet에서 서울 리전의 S3 IP대역(destination)으로 향하는 트래픽은 s3 엔드포인트(target)를 통해 이동하라는 뜻

• private subnet instance 에서 s3 통신가능

Interface EndPoint + CloudFormation

• private ec2에서 -> cloudFormation에 접근 가능하도록 설정

• private subnet을 포함한 엔드포인트 생성

• InterfaceEndpoint는 라우터 테이블이 아닌 특정 접점 에서의 연결 포인트를 제공해주기 떄문에 이 엔드포인트에서 사용할 sg를 하나 생성 해준다.

• 엔드포인트를 만들었으면 Private 인스턴스 에서 이 엔드포인트를 통해 cloudFormation access할 준비가 되어 있는 상태임

VPC Peering

• VPC Peering을 이용해 동일 Account 및 Region 내에 위치한 2개의 서로다른 vpc 연결통신이 가능한 네트워크 구성

• vpc 01 과 동일하게 vpc 02 생성

• 새로 생성한 vpc 02 에 igw02를 새로 만들어서 붙여준다

• vpc 02 에 private, public subnet 각각 한개씩 생성

• 새롭게 생성한 라우트 테이블을 새롭게 생성한 public subnet에 붙여준다

• edit route -> public subnet에 라우트 테이블이기 때문에 igw도 추가해준다

• 똑같은 방법으로 private subnet 에 private rout table을 연결 해준다.

• public ec2 , private ec2를 만들어준다 (public 는 다 디폴트값만 설정, 사진은 private ec2)

• private ec2에서는 VPC Peering + ping 으로 연결테스트를 하기위해 ICMP(Internet Controll Messager protocol)를 설정 해준다

• vpc-01-private 에도 vpc 02로부터 올 ping을 위해 sg를 수정 해준다.

• vpc -> vpc peering

• vpcID는 peering 요청을 보내는쪽 ( 위 예제에서는 01 ->02)

• 반대로 받는쪽 설정, account와 리전으로 다르게 설정 가능

• accpet request 까지해줘야 vpc peering 연결이 완성된다.

VPC peering sg

• 인스턴스에서 출발한 트래픽이 peering 을 통해 반대편으로 요청이 가도록 router table을 수정해 준다.

• private-subnet-rt-01 -> 02로 라우팅

• 반대로 private-subnet-rt-02 -> 01로 라우팅

-> ping 테스트를 하려면 icmp 설정 + sg가 필요함

TransitGateWay

• TransitGateWay : 복수의 VPC 사이에 트래픽을 주고 받을 수 있도록 해주는 네트워크 서비스

• vpc 01, 02, 03 ... 다 peering으로 연결되 있으면 너무 많은 peering connection이 필요함

• VPC , IGW 생성후 public,private subnet을 만들어 준다. subnet을 만든후 라우트 테이블을 만들어 연결시켜준다.

(두번째 사진 인바운드 롤 잘못해서 수정함 현재 vpc 03 인스턴스 sg)

• public subnet에 Ec2하나 , private subnet에 ec2 하나를 넣어준다

• 서로 다른 vpc(01,02) 에서 ping 테스트를 위해 icmp 설정을 해준다.

  

• 같은 방법으로 각각 vpc 01과 vpc 02 private instance에 icmp 를 설정함(서로 핑 통신이 되야하니까)

• 현재 설정 상태로는 peering 이 되있지않아 서로간의 통신이 불가능함

TransitGateWay 설정

• VPN ECMP : 여러 vpn을 연결해서 vpn 터널간에 다중경로 라우팅 지원 여부

TransitGateWay attachments 설정

• transitGateway와 vpc or vpn 등과 같은 다른 네트워크 리소스 사이의 연결을 정의하기 위해서 사용되는 요소

• 여러 vpc가 하나의 transitGateway에 연결을 하면 각각 vpc에서 transitGateway attachment를 생성해서 연결해준다.
  

• subent은 private을 선택

• 같은 방법으로 각각 vpc01/vpc02/vpc03 transitgateway attachment를 생성해준다.

TransitGateway RouteTable 설정

• TransitGateway 로 들어온 트래픽이 TransitGateway routtable 경로에 설정된 TransitGateway attatchment로 전달됨

• TransitGateway 라우트 테이블에 TransitGateway attachment 각각 붙이기

• TransitGateway 라우트 테이블에 associate 된 TransitGateway attachment 에 대한 스태틱 라우트 vpc01 vpc02 vpc03 에 대한 스태틱 라우트를 만들어준다.

• 스태틱 라우트 : 해당 crdi블록 즉 특정 ip대역으로 향하는 트래픽을 특정 attachment로 보내도록 지시하는 것을 의미

• 여기서 끝이 아니라, 인스턴스가 위치한 서브넷의 라우팅 테이블에도 다른 vpc 네트워크로 이동할 떄 관련 경로가 설정 되 있어야 한다.

• 여기까지 설정 해주면 private Subnet에 있는 각각 인스턴스들이 TransitGateway 를 통해 서로 통신이 가능하다

TransitGateway 통신제어

• TransitGateway routetable 에서 blakchole 로 설정 해주면 이 vpc 대역으로 가는 트래픽을 차단 시켜준다

• private 인스턴스 ip/32 : 여기서 32가 붙으면 이 ip 대역의 호스트가 1개이기 때문에 결국 cidi블록은 vpc 02 ec2 의 주소가 된다고 보면된다.(현재 vpc 02 차단상태임)

• attachment는 vpc 02

• 해당 vpc로의 통신은 제한하지만 private 인스턴스 통신만 허용하도록 설정

Site to Site VPN

• Customer GateWay : VPN 연결에 사용되는 요소이며, Customer 네트워크의 Gateway 역활을 수행

• Virtual Private Gate way : VPN 연결에 사용되는 요소이며, AWS 네트워크의 Gateway 역활을 수행

• VPN Connection : AWS와 이보 네트워크 간의 VPN 연결을 구성 및 설정해주는 요소

• 하나는 서울리전 private subnet 인스턴스 , 하나는 도쿄 public subnet 인스턴스로 구성 해 준다.

CustomerGateway 생성

• ip 주소는 도쿄 인스턴스 퍼블릭 ip

Virtual private gateway 생성

• VPC 내의 리소스가 VPN을 통해 다른 외부 네트워크와 통신을 하기 위해서는
  Virtual private gateway 가 VPC에 attach 되어야함

site to site VPN 생성

• 서울리전 쪽에서 생성

• static iP 커스터머 사이드의 ip를 입력하면 된다. 지금은 도쿄리전의 VPC

• VPN을 통해 통신을 허용할 ip, Local은 커스터머 사이드, Remote는 AWS사이드의 ip를 적어준다.

• vpn 연결 구성과 설정은 커스터머 사이드에서 하게 되는데 이를 위해서 도쿄 리전의 퍼블릭 인스턴스에 libreswan 설치하고 다운받은 컨피그 파일을 참고해서 site to site vpn을 완성 시킨다

• 도쿄리전 인스턴스에 dnf install libreswan -y 명령어를 통해 libreswan 을 다운받아 준다

• 이런 식으로 컨피그 파일설정을 도쿄리전 인스턴스에 적용시켜준다.

• left/ leftId = 커스터머 게이트웨이 정보(도쿄리전 인스턴스 public ip)

• right/rightId = 터널에 할당된 IP 주소

• leftsubnet은 커스터머사이드 즉, 도쿄리전 vpc

• rightsubnet은 AWS 사이드 즉, 서울리전 vpc

• overlapip=yes

• 기본적으로 커넥션은 두 개의 터널이 있는데 한 개의 터널에 우선적으로 커스터머 게이트웨이의 연결이 구성된다. 한 개 터널에 커스터머 게이트웨이가 연결이 되면 일단 해당 커스터머 게이트웨이가 사용중이기 때문에 다른 터널의 연결 요청에는 응답을 하지 않는다. 이렇게 되면 나머지 설정을 완료하더라도 두개의 터널중 한개만 활성화가 됨. 그래서 다중 터널 구성을 해서 같은 커스터머 게이트웨이의 ip 주소를 사용할 수 있도록 설정 해주면 두개 터널이 모두 활성화가 됨
  

• 터널에 대한 설정이 다끝나고 IPsec터널에서 인증을 위한 키값 정보를 설정해 준다.(터널1, 터널2)

• ipsec설정 까지 끝났으면 -> service ipsec start / chkconfig ipsec on / 명령어를 순서대로 입력 해준다.

• 서울리전 라우트테이블을 도쿄리전의 vpc와 통신할수 있도록 수정해 준다.

• 여기까지 설정하면 site to site vpn으로 통신이 가능하다