AWS VPC -1

CIDR

/32로 끝나는 IP주소는 IP하나만 나타냅니다.

만약 0.0.0.0.0이라면 모든 IP를 나타낸다.

192.168.0.0/26을 정의해보자면

화면에 보이듯 IP주소 64개를 나타낸다.

192.168.0.0 ~ 192.168.0.63 

 

CIDR 구성 요소는 두가지이다.

기본 IP

먼저 기본 IP란 범위에 포함된 IP이다. 일반적으로 범위의 시작이되는데

예시로 10.0.0.0 또는 192.168.0.0등이 있다.

 

서브넷 마스크

IP에서 변경 가능한 비트의 개수를 정의 합니다.

여기에는 /0, /24 그리고 /32까지 있는데 형식은 두가지이다.

예를들면 /8은 서브넷 마스크 255.0.0.0과 동일하다.

/16은 255.255.0.0과 같다.

 

/32라면 2의 0승으로 하나의 아이피만들 허용한다.

/31이라면 2의 1승으로 2개의 아이피만 허용한다.

192.168.0.0/31 -> 192.168.0.0 ~ 192.168.0.1 (2의1승) 32-31

192.168.0.0/30 -> 192.168.0.0 ~ 192.168.0.3 (2의 2승) 32-30

192.168.0.0/29 -> 192.168.0.0 ~ 192.168.0.7 (2의 3승) 32-29

192.168.0.0/28 -> 192.168.0.0 ~ 192.168.0.15 (2의 4승 ) 32-28 

...

192.168.0.0/24 -> 192.168.0.0 ~ 192.168.0.255 ( 2의 8승) 32-24

...

192.168.0.0/16 -> 192.168.0.0 ~ 192.168.255.255 (2의 16승) 32-16

...

192.168.0.0/0 -> 0.0.0.0 ~ 255.255.255.255

 

Default VPC

새로운 AWS 계정은 모두 기본 VPC가 있고 바로 사용할 수 있다.

ec2를 생성할 때 서브셋을 지정하지 않으면 기본 VPC에 실행된다.

어쨌든 계정을 시작하면 VPC는 하나만 생긴다. 

기본 VPC는 처음부터 인터넷에 연결되어있어 인스턴스가 인터넷에 엑세스하고 또 내부의 ec2인스턴스는 공용 ip주소를 얻는다.

ec2인스턴스를 생성하자마자 연결할 수 있는 이유가 바로 이 때문이다.

 

라우팅 테이블

라우팅 테이블은 트래픽이 VPC를 통해 경로를 선택하도록 돕는다.

기본적으로 로컬, 인터넷 게이트와 연결이 되어있는데

로컬은 해당 아이피 범위에 있는 요청들은 로컬로 연결되도록 하는 것이고.

그 외에 것들은 인터넷 게이트로 보내 외부로 보내는 것을 의미한다.

 

VPC - Virtual Private Cloud

리전당 최대 5개까지 VPC를 만들 수 있다.

VPC마다 할당된 CIDR은 다섯개이다.

각 CIDR의 최소 크기는 /28이다. 최대는 /16 사설 IPv4범위만 허용된다. 

 

VPC CIDR가 다른 VPC나 네트워크 혹은 기업 네트워크와 겹치지 않도록 주의해야한다.

함께 연결하려면 VPC혹은 CIDR IP주소가 다른 네트워크의 IP 주소 범위와 겹치지 않아야한다.

 

서브넷

서브넷이란 VPC내부에 있는 ip4의 주소 부분 범위이다.

이 범위 내에서 IP주소 다셧개를 AWS가 미리 예약해준다.

처음 4자리, 마지막 한개를 서브넷 마다 예약한다, 이런 IP주소는 사용도 안되고 할당도 안된다.

시험에서 29개의 아이피가 필요할 때 /27은 사용못한다는 걸 기억해야한다.

그 이유는 32-27 = 5 즉 2의5승만큼 사용 가능하여 32개인데, 거기서 5개를 빼면 27개이니까

/26을 해야 29개 아이피를 사용할 수 있게 된다.

 

인터넷 게이트웨이

Internet Gateway (IGW)는 VPC의 리소스를 (EC2 인스턴스나 람다 함수 등) 인터넷에 연결하도록 허용해준다.

수평으로 확장되고 가용성과 중복성이 높다.

VPC와는 별개로 생성해야하고 VPC는 인터넷 게이트 하나에만 연결되며 반대의 경우도 마찬가지이다.

인터넷 gate way 자체는 인터넷 액세스를 허용하지 않는다.

라우팅 테이블도 수정을 해야한다.

 

인터넷에 접속하기 위해선 공용 서브넷에 공용 인스턴스를 만들고 라우팅 테이블을 수정해서 ec2인스턴스를 라우터에 연결하고

인터넷 gateway에 연결해야한다.

 

Bastion Hosts

사용자가 프라이빗 서브넷에 있는  ec2 인스턴스에 액세스 하고자 한다.

이 때 배스천 호스트를 사용하면 외부에서 프라이빗 서버에 접속할 수 있다.

이 건 EC2이며 퍼블릭 서브넷에 있다는 점이 특징이다.

따라서 프라이빗 서브넷에 있는 EC2에 접속하기 위해선

퍼블릭 서브넷에 있는 베스천 호스트에 ssh로 먼저 연결하고, 그 다음 프라이빗 서브넷으로 연결하는 방법이다.

이렇게 하기 위해선 베스천 호스트는 외부의 아이피를 보안그룹에서 허용하고 프라이빗 ec2는 베스천 호스트의 프라이빗 아이피를 허용하거나, 베스천 호스트의 보안 그룹을 허용하면 될 것이다.

 

NAT instance

NAT = Natwork Address Translation

NAT는 네트워크 주소 변환을 뜻한다.

NAT 인스턴스는 사설 서브넷 EC2인스턴스가 인터넷에 연결되도록 허용한다.

NAT 인스턴스는 공용 서브넷에서 실행되어야 하고 공용 및 사설 서브넷을 연결한다/

비 활성화 해야하는 부분은 소스/목적지 확인이다.

또 NAT 인스턴스에는 고정된 탄력적 IP가 연결되어야 한다.

또 라우팅 테이블을 수정하여 사설 서브넷에 있는 EC2 인스턴스로 부터 NAT 인스턴스로 트래픽을 전송하도록 해야한다,

NAT 인스턴스를 통과하여 인터넷을 통해 외부 서버로 요청을 보내는 것이다.

 

NAT Gateway

Nat instance를 사용하면 가용성이 떨어지는 등 여러 단점이 존재하여 AWS에서는 사용을 권장하지 않고

NAT Gateway라는 서비스를 출시하여 그걸 사용하는 것을 권장한다,.

EC2 인스턴스와 같은 서브넷에서 사용할 수 없다.

다른 서브넷에서 액세스 할 때에만 사용가능하다,.

공용 서브넷에 NAT gateway를 만들고 사설 서브넷의 인스턴스와 연결하면 된다.

NAT gateway에는 인터넷 게이트웨이가 필요하다. ( 당연히 외부에 접속을 해야하니까 )

또한 보안그룹을 관리할 필요가 없다.

 

방법은 nat instance와 똑같다. 사설 서브넷의 라우트 테이블을 외부로 향하는 트래픽을 nat gateway로 보내면 된다.

 

NACL

네트워크 ACL 즉 NACL이다.

요청이 서브넷에 들어가기 전에 먼저 NACL로 이동한다. 여기엔 몇가지의 인바운드 룰이 정의되며

요청이 허용되지 않으면 내부로 들어갈 수 없다.

첫번째 요청이 

1.NACL에 접근 이후 통과하면

2.보안그룹 인바운드에 접근한다.

NACL은 무상태이고 보안 그룹은 상태 유지이다.,

이게 무슨 뜻이냐면 요청의 응답을 보낼 때 아웃바운드 규칙은 자동으로 보안 그룹 수준에서 허용된다.

그 이유는 보안 그룹의 특징이 상태 유지이기 때문이다.

즉 들어간 것은 전부 나올 수 있다.

 

내가 이해한 것은

NACL은 무상태이기 때문에 인바운드와 아웃바운드 규칙이 매번 평가된다.

SG는 특정 ec2에만 적용되는데 NACL은 서브넷에 적용되어 그 안에 있는 모든 ec2에 적용된다.

SG의 아웃바운드를 없애도 statefull이기때문에 외부에서 인바운드를 통해 들어오면 응답이 잘 간다

심지어 아웃바운드가 없는데도 말이다.

 

반대로 외부가 아닌 그 ec2에서 외부로 요청을 보낼 때에는 아웃바운드가 없기때문에 아무 요청이 안나갈 것이다.

 

 

 

우선순위에따라서 결정되며

예를들어 100에 특정 아이피가 허용되고

200에 그 아이피를 차단했다면 아이피는 허용된다.

NACL는 서브넷 마다 설정할 수 있다.

 

기본 NACL는 연결된 서브넷을 가지고 인바운드 아웃바운드의 모든 요청을 허용하는 특수성을 가진다.

기본 NACL을 수정하지 않는 것을 추천한다.

 

임시포트 : 서버도 응답을 하려면 클라이언트에 연결해야한다. 클라이언트는 기본적으로 개방된 포트가 없어서

클라이언트가 서버에 접속할 때 자체적으로 특정한 포트를 열게된다. 이 포트는 임시라서 클라이언트와 서버 간 연결이 유지 되는 동안만 열려 있다. 이건 OS에 따라 달라진다.

win 10 : 49152 ~ 65535

linux : 32768 ~ 60999

 

클라이언트가 요청을 보낼 때 자신의 아이피와 임시포트도 넣어서 보내서 서버는 그걸 바탕으로 응답을 보낸다.

 

VPC피어링

다양한 리전과 계정에서 VPC를 생성할 수 있는데 AWS 네트워크를 통해 연결하고 싶을 때 사용한다.

VPC가 모두 같은 네트워크에서 작동하도록 만들기 위해서이다.

다른 리전 또는 다른 계정에서 연결했을 때 CIDR가 겹치면 통신을 할 수 없기에 겹치면 안된다.

서로 다른 VPC끼리 통신하려면 VPC피어링을 활성화 해야한다,

 

A,B,C 세개의 VPC가 존재한다고 가정하고, 

AB BC를 피어링 했을 때 AC끼리 접속할 수 없다. AC또한 피어링을 해야 접속 가능하다.

 

같은 계정 뿐만 아니라 다른 계정간에서도 할 수 있다. 

단순히 피어링만 했다고 해서 연결되는 것이 아니라 라우트 테이블또한 연결해줘야한다.

 

VPC Endpoints

AWS에서 dynamoDB와 같은 서비스를 이용한다고 하면 퍼블릭 액세스가 가능한데

이것은 NAT gateway나 인터넷 게이트웨이를 통해 dynamoDB에 액세스 할 수 있다는 것이다.

하지만 이 모든 트래픽은 퍼블릭 인터넷을 거쳐서 온다. 

cloud watch나 s3을 이용할 때 프라이빗으로 접속을 원할경우 VPC엔드포인트를 사용하면 된다.

퍼블릭 인터넷을 사용하지 않고 바로 프라이빗 aws네트워크만 거쳐서 서비스에 액세스할 수 있다.

비용적으로도 절감이되고 훨씬 효율적인 방법이다. AWS 서비스가 private link라는 것을 가지고 있기에 프라이빗 내에서도 접근이 가능한 것이다.

 

VPC 엔드포인트는 VPC내에 배포된다. 프라이빗 서브넷에 있는 EC2 인스턴스를 VPC 엔드포인트를 거쳐 직접 Amazon SNS서비스에 연결할 수 있다. 이 때 네트워크가 AWS내에서만 이루어진다는 장점이 있다.

 

모든 AWS 서비스는 퍼블릭에 노출되어 있고 퍼블릭 URL을 갖는다.

VPC 엔드포인트를 사용하면 AWS private link를 통해 프라이빗으로 액세스 하므로 퍼블릭을 거치지 않고도 프라이빗 네트워크를 사용할 수 있다. 이렇게 되면 인터넷 게이트나 NAT 게이트 웨이가 없어도 AWS서비스에 액세스 할 수 있게 해주므로 네트워크 인프라를 상당히 간단하게 만들 수 있다. DNS 설정 해석이나 라우팅 테이블을 확인하면 된다.

 

엔드포인트의 종류는 2가지가 있는데

1. 인터페이스 엔드포인트이다.

ENI를 엔트리 포인트로써 프로비저닝 한다. private ip가 부여되며 보안그룹을 지정할 수 있다.

대부분의 aws서비스가 지원하고 private link를 사용한다. 프라이빗 서브넷 ec2 -> ENI -> SNS

요금은 시간당 청구된다.

 

2. 게이트웨이 엔드포인트

게이트웨이를 프로비저닝 하는데 이 때 게이트웨이는 반드시 라우팅 테이블의 대상이 되어야 한다.

IP주소를 사용하거나 보안 그룹을 사용하지 ㅇ낳고 라우팅 테이블의 대상이 될 뿐이다.

게이트웨이 엔드포인트 대상으로는 S3 DynamoDB 두 가지만 있다. 장점은 무료이다.

VPC Endpoint가 게이트웨이 역할을 하여 이걸 통해 접속한다.

프라이빗 서브넷 ec2 -> VPC Endpoint -> S3 or DynamoDB

 

S3, DynamoDB에 접속시 어떤 VPC엔드포인트를 사용 ?

시험에서는 게이트웨이 엔드포인트를 사용하는 것이 유리하자.

라우팅 테이블만 수정하면 되기 때문이다. 그리고 무료로 액세스 할 수 도 있다.

다만 인터페이스 엔드포인트가 권장되는 경우는 온프레미스에서 액세스해야할 필요가 있을 때 뿐이다.

혹은 다른 VPC에 연결할 때나.

 

VPC Flow Logs

인터페이스로 향하는 IP 트래픽 정보를 포착하는 것으로 VPC계층, 서브넷 계층 , Elastic Network Interface(ENI)계층 총 세가지 흐름 로그가 있다. 흐름 로그는 연결 문제를 모니터링하고 트러블 슈팅하는데 유용하다.

여기서 발생한 로그 데이터를 s3나 cloud watch logs에 전송할 수 있다.

 

srcaddr과 dstaddr로는 문제가 있는 IP를 식별할 수 있다. 한 IP가 지속적으로 거부되면 여기서 알아볼 수 있다.

IP에 문제가 있거나 특정 IP가 공격받았을 때도 여기서 알 수 있따.

action은 요청이 수락되었는지 거부되었는지를 나타내며 보안그룹이나 NACL계층에서 요청이 성공했는지 실패했는지 알려준다. VPC flow log를 s3에서 athena로 확인하거나 스트리밍 분석을 원할 땐 cloud watch logs insights를 사용한다.

 

Site-to-Site VPN

온프레미스 환경의 기업 데이터 센터를 AWS와 비공개로 연결하려면

온프레미스쪽에서는 고객 게이트웨이, VPC쪽에서는 VPN 게이트웨이를 사용하여

공용 인터넷을 통해 사설 site to site VPN을 연결해야한다. 

 

VPN에서는 두가지가 필요하다 

1. Virtual Private Gateway ( VGW ) 

VPN 연결에서 AWS 측에 있는 VPN 집선기(concentrator) 이다.

VGW가 생성되면 VPC에 연결된다. 

 

2.Customer Gateway (CGW)

이건 고객 게이트웨이이며 소프트웨어 혹은 물리적 장치로 VPN 연결에서 기업 데이터 센터 측(온프레미스)에 속한다.

고객 게이트웨이(public ip)가 있는 기업 데이터 센터와, VGW를 갖춘 VPC가 있다고 가정해보자.

고객 게이트웨이의 public ip를 사용해서 연결할 수있다.

고객 게이트 웨이가 private ip를 가질 수도 있다. 그럼 NAT device에 공용 ip가 있을 시 이 공용 ip를 CGW에 사용해야한다/.

 

서브넷의 VPC에서 라우트 전파를 활성화 해야 site to site VPN 연결이 실제로 작동한다

온프레미스에서 AWS로 EC2인스턴스 상태를 진단할 때 보안 그룹 인바운드  ICMP프로토콜이 활성화 됐는지 확인해야 한다. 그렇지 않으면 연결이 안된다.

 

만약 온프레미스가 여러개라면 cloud hub를 통해서 하나의 VGW와 여러 고객 게이트웨이를 연결할 수 있다. 이렇게 되면 고객 게이트웨이로 다른 온프레미스 간에 연결도 가능해진다.

 

VPN연결이므로 모든 트래픽이 공용인터넷을 통한다. 사설 네트워크로는 연결되지 않음 하지만 연결은 암호화 됨으로 안전하다/.

 

Direct Connect (DX)

VPC로의 전용 프라이빗 연결을 제공한다. Direct Connect를 사용할 때는 전용 연결을 생성해야 하고 AWS direct connect 로케이션을 사용한다. VPC에는 가상 프라이빗 게이트웨이 VGW를 설치해야 온프레미스 와 AWS간 연결이 가능하다.

 

큰 데이터 세트를 처리할 때 속도가 빨라진다. 퍼블릭 인터넷을 거치지 않기 때문이다.

또 프라이빗 연결을 사용하므로 비용도 절약된다. 퍼블릭으로도 연결을 할 수 있어 하이브리드 환경을 지원한다.

ipv4 ipv6둘 다 지원한다.

 

전부 수동으로 연결해야 하므로 새 연결을 만들려면 한달보다 길어질 때도 있으므로 시험에서 일우징ㄹ 안에 빠르게 데이터를 전송하고 싶다면 이 방법은 무리일 것이다.

암호화는 불가하지만 프라이빗으로 연결가능함으로 안전하다.

만약 암호화를 원한다면 VPN도 같이 설치하여 IPsec으로 암호회된 프라이빗 연결이 가능하다.

핵심 워크로드의 복원력을 높이기 위해서는 여러 Direct Connect를 설치하는 것이 좋다. 가령 기업 데이터 센터가 2개 있고 direct connect 로케이션도 두개를 만들면 하나가 고장나도 다른 하나가 예비로 남아있기에 복원력이 강해진다.

 

Direct connect와 site to site VPN을 같이 연결해두면 기본 연결에 문제가 발생했을 때 site to site VPN을 통해 퍼블릭 연결할 수 있으므로 안정성이 높아진다.