AWS IP 주소
- IPv4: 43억 개의 주소를 가지고 있음
- 공인 IPv4: 인터넷에서 사용할 수 있는 IP 주소
- EC2 인스턴스를 생성하면 공인 IPv4를 얻음
- 사설 IPv4: 내부 AWS VPC와 같은 사설 네트워크에서만 사용할 수 있는 IP
- EC2 인스턴스를 중지 후 다시 시작해도 인스턴스의 수명 동안 동일하게 유지됨
- 공인 IPv4: 인터넷에서 사용할 수 있는 IP 주소
- 탄력적 IP: 공인된 IPv4 주소를 EC2 인스턴스로 가져오는 것으로 인스턴스를 중지했다가 다시 시작해도 동일한 공인 IPv4를 갖게 됨
- IPv6: 새로운 인터넷 프로토콜 버전으로 더 많은 주소를 가지고 있다.
- AWS IPv6의 모든 IP 주소는 공인 IP이고, 사설 영역이 없다.
가격
- AWS의 모든 공인 IPv4: 시간 당 0.005 달러
- 공인 IPv4와 탄력적 IP가 포함되어 있음
- 프리 티어로 매월 750 시간 사용할 수 있음
- AWS의 IPv6: 무료
- 인터넷 IP 관점에서 볼 때 사용자의 서비스를 무료로 노출하려면 IPv6를 사용해야 한다.
VPC & Subnets Primer
VPC는 Virtual Private Cloud의 약자로 논리적으로 격리된 사용자 전용 가상 네트워크이다. 쉽게 말해서 AWS의 리소스들이 위치할 네트워크 망이다. 여러 리전이 있으면 여러 VPC를 가질 수 있으며, 여러 개의 서브넷으로 이뤄져 있다.
가상 네트워크를 이용하여 물리적으로는 다른 곳에 위치하지만 같은 사설망 IP 대역에 위치하게 만들어 리소스들끼리 통신할 수 있게 만들어주는 기술이다.
Subnet은 VPC의 일부로 네트워크의 파티션이며 가용 영역과 연결된다. VPC의 영역 안에서 망을 더 쪼개는 행위라고 생각할 수 있지만 VPC와는 달리 지역적으로 나누기 때문에 여러 가용 영역에 걸쳐있는 것이 아닌 단일 가용 영역에 위치한다.
Subnet은 Public Subnet과 Private Subnet으로 나눌 수 있는데 Public Subnet의 경우 외부와의 자유로운 통신이 가능하고, Private Subnet의 경우 외부에서 직접 접근할 수 없다.
인터넷과 서브넷 사이의 액세스를 정의할 때 Route Table을 사용한다.
예를 들어, AWS 클라우드가 있고, 리전 안에는 VPC가 있다. 그리고 VPC에는 CIDR 범위가 있는데 이는 VPC에서 허용되는 IP 주소의 범위이다.
VPC는 2, 3개의 가용 영역에 있을 수 있다. 따라서 두 가용 영역에 각각 공용 서브넷과 사설 서브넷이 있다. 그리고 각 서브넷에서 EC2 인스턴스를 실행할 수 있다.
인터넷에 액세스 할 수 있는 공용 서브넷에 EC2 인스턴스가 있으며, 인터넷 게이트웨이는 VPC 인스턴스가 인터넷에 바로 연결되도록 한다. 간단하게 인터넷 게이트웨이와 인터넷 게이트웨이로의 라우트가 있으면 서브넷이 공용 서브넷이 되는 것이다.
또한 NAT 게이트웨이를 생성해서 사설 서브넷의 인스턴스에 인터넷 액세스 권한을 부여할 수도 있다. 이 경우 사설 서브넷 내의 인스턴스가 사설인 상태를 유지하면서 인터넷에 액세스 하도록 한다.
Network ACL & Security Groups
Network ACL
EC2 인스턴스를 위한 첫 번째 방어선은 NACL, 즉 네트워크 ACL로 서브넷으로 들어오고 나가는 트래픽을 제어하는 방화벽이다. 따라서 서브넷 수준에 연결되어 규칙을 정의, 허용 또는 거부할 수 있고, 규칙에는 IP 주소만 포함될 수 있다.
Security Groups
두 번째 방어선은 보안 그룹이다. 이는 EC2 인스턴스로 들어오고 나가는 트래픽을 제어하는 방화벽이다. 그리고 보안 그룹은 허용 규칙만 가질 수 있다. 보안 그룹은 IP 주소나 다른 보안 그룹을 참조할 수 있다. 예시에선 EC2 인스턴스 주변에 보안 그룹이 있고, 인스턴스를 드나드는 트래픽을 제어한다.
차이점
- NACL
- 서브넷 수준에서 작동한다.
- 허용 규칙과 거부 규칙을 지원
- 연결 상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 한다.
- 보안 그룹
- 인스턴스 수준에서 작동
- 허용 규칙만 지원
- 연결 상태 저장: 어떤 규칙이든 관계없이 반환 트래픽이 자동으로 허용된다.
VPC Flow Logs & VPC Peering
VPC Flow Logs
VPC Flow Logs는 인터페이스를 통과하는 모든 IP 트래픽에 대한 로그이다. VPC Flow Logs, Subnet Flow Logs, Elastic Network Interface Flow Logs를 통해 EC2 인스턴스로 들어오고 나가는 트래픽을 확인할 수 있다.
플로우 로그를 활성화하면 연결 문제를 모니터링하고 해결할 수 있다.
- 서브넷이 인터넷에 연결할 수 없는 경우
- 서브넷이 다른 서브넷에 연결할 수 없는 경우
- 인터넷이 서브넷에 연결할 수 없는 경우
VPC Flow Logs는 EC2 인스턴스 외에도 ELB, ElasiCache, RDS, Aurora 등에 대한 정보를 얻을 수 있고, S3, CloudWatch Logs, Kinesis Data Firehose로 갈 수 있다.
VPC Peering
VPC Peering은 AWS의 네트워크를 사용해 두 VPC를 프라이빗으로 연결함으로써 마치 동일한 네트워크인 것처럼 동작하도록 하는 것이다.
예시로 위 사진처럼 VPC A와 VPC B, VPC C가 있을 때, 이것들을 서로 피어링 할 수 있다. 피어링이 완료되면 동일한 네트워크에 있거나, 마치 동일한 네트워크에 있는 것처럼 동작한다. 이를 위해선 IP 주소 범위가 겹치면 안된다. 또한 VPC 피어링 연결은 전이적이지 않는다. 따라서 VPC B와 VPC C는 서로 통신할 수 없다.
VPC Endpoints - 인터페이스 및 게이트웨이
VPC Endpoints
지금까지 사용한 AWS 서비스는 모두 공용이다. 서비스에 연결하면 공용으로 연결된다는 의미이다.
하지만 VPC Endpoints를 사용하면 공용 인터넷 네트워크 대신 사설 AWS 네트워크를 사용한다. 더 나은 보안을 제공하기 때문이다. 이는 공용 인터넷을 사용하지 않기 때문이며 네트워크 홉(Hop)을 통해 액세스하지 않아 지연 시간이 짧기 때문이다.
예시로 VPC와 사설 서브넷이 있고 사설 서브넷 안에 EC2 인스턴스가 있으며 S3나 DynamoDB에 연결하려면 게이트웨이의 VPC 엔드 포인트를 생성해야 한다. 이때 게이트웨이 엔트 포인트는 S3와 DynamoDB 전용이다. EC2 인스턴스로 게이트웨이를 통해 S3와 DynamoDB에 비공개로 연결할 수 있다.
다른 유형의 엔드 포인트는 VPC 엔드 포인트 인터페이스로 AWS의 다른 모든 서비스와 연결할 수 있다. EC2 인스턴스에서 CloudWatch로 사용자 지정 지표를 푸시하는 경우 VPC 엔드 포인트 인터페이스를 사용하면 EC2 인스턴스에 연결되고 CloudWatch에 연결된다.
