개발자이너

실수로 VPC 가용영역을 1개로 설정해 버렸다..... 고쳐야한다ㅠㅠ

보통 위와 같이 못해도 두개의 AZ를 두고 만든다. 근데 ? 나는 하나로 했지 ㅋㅋㅋㅋ

결론 부터 말하면 VPC 자체만으로는 가용영역을 변경할수 없다. 그래나 언제나 도망갈 구멍은 있는법. 

VPC에 새로운 서브넷 추가하기

가용 영역은 서브넷 단위로 지정되기 때문에, 새 가용 영역을 추가하려면 새로운 서브넷을 만들면 된다.

1. AWS Management Console로 이동.
2. VPC 대시보드 → 서브넷(Subnets) 선택.
3. 새 서브넷 생성 클릭:
   • VPC 선택: 기존의 VPC를 선택.
   • 가용 영역: 새롭게 추가하고자 하는 가용 영역 선택.
   • CIDR 블록: 기존 VPC CIDR 대역에서 사용하지 않는 범위를 지정.
4. 서브넷 생성 완료 후 ELB, EC2 등의 자원에 이 서브넷을 연결

ALB에 새로운 서브넷 추가

ALB는 다중 AZ를 지원하므로, VPC에 새 AZ를 추가한 후 ALB 설정에서 해당 서브넷을 연결하면 됩니다.

1. AWS Management Console → EC2 대시보드 → 로드 밸런서 → ALB 선택.
2. 로드 밸런서 서브넷 설정 편집:
   • 새롭게 생성한 서브넷 추가.
   • ALB가 다중 가용 영역을 사용하도록 설정.

기존 서브넷 수정

기존 서브넷은 가용 영역(AZ)을 변경할 수 없기 때문에, 기존 서브넷을 삭제하고 새로운 서브넷을 생성해야 합니다.

주의:

• 기존 서브넷을 삭제하면 해당 서브넷과 연결된 모든 자원(EC2, ALB 등)이 영향을 받습니다.
• 서브넷 변경이 필요할 경우 새로운 서브넷을 추가한 뒤, 자원들을 새로운 서브넷으로 이전하는 방식이 안전합니다.

새로운 VPC 생성

마지막으로 VPC를 그냥 새로 만든다...

먼저 둘을 각각 설명함에 앞서 간단하게 설명해 보겠습니다

네트워크 ACL(Network ACL)과 보안 그룹(Security Group)은 AWS Virtual Private Cloud(VPC) 내에서 네트워크 트래픽을 제어하기 위해 사용되는 네트워크 보안 메커니즘입니다. 이 두 가지는 VPC에서 애플리케이션과 데이터를 보호하기 위해 다양한 레벨에서 트래픽을 필터링하는 데 사용됩니다.

네트워크 ACL(Network ACL)

1. 네트워크 ACL이란?

네트워크 ACL(Network Access Control List)은 VPC의 서브넷 레벨에서 작동하는 보안 계층으로, 들어오는(Inbound) 및 나가는(Outbound) 트래픽을 허용하거나 거부하는 규칙을 설정할 수 있습니다. 이를 통해 서브넷 수준에서 트래픽을 제어할 수 있습니다.

• 특징:
  • 스테이트리스(Stateless): 요청과 응답을 따로 처리하며, 들어오는 트래픽과 나가는 트래픽에 대해 각각 명시적으로 규칙을 설정해야 합니다.
  • 서브넷 단위로 작동.
  • 규칙이 번호 순서(낮은 숫자부터)로 평가됩니다.

2. 네트워크 ACL의 사용법

• 기본 ACL: 새로 생성한 VPC에는 자동으로 기본 네트워크 ACL이 생성됩니다.
  • 기본적으로 모든 트래픽을 허용(Allow)합니다.
• 커스텀 ACL 생성:
  1. AWS 콘솔 > VPC > 네트워크 ACL 생성.
  2. 서브넷에 네트워크 ACL 연결.
  3. 인바운드 및 아웃바운드 규칙 추가(규칙 번호, 소스/목적지, 프로토콜, 포트 범위, 동작 설정).

예제 규칙:

규칙 번호유형프로토콜소스동작

3. 네트워크 ACL을 사용하는 경우

• 대규모 서브넷 보안이 필요한 경우: 서브넷 내 모든 인스턴스에 공통으로 적용되는 보안 규칙이 필요한 경우.
• 트래픽에 대한 기본적인 필터링: 여러 인스턴스에 대해 일괄적인 허용/거부 규칙을 설정하고 싶을 때.
• 스테이트리스 방식이 필요한 경우: 요청과 응답 트래픽을 각각 제어하고 싶을 때.

보안 그룹(Security Group)

1. 보안 그룹이란?

보안 그룹(Security Group)은 VPC에서 인스턴스 수준에서 작동하는 보안 계층으로, 특정 인스턴스에 들어오고 나가는 네트워크 트래픽을 제어합니다.

• 특징:
  • 스테이트풀(Stateful): 들어오는 트래픽이 허용되면 해당 트래픽의 응답은 자동으로 허용됩니다.
  • 인스턴스 단위로 작동.
  • 규칙 번호가 없으며, 모든 규칙이 동시에 평가됩니다.

2. 보안 그룹의 사용법

• 기본 보안 그룹: 새로 생성된 VPC에는 기본 보안 그룹이 생성됩니다.
  • 기본적으로 모든 인바운드 트래픽은 차단되고, 모든 아웃바운드 트래픽은 허용됩니다.
• 커스텀 보안 그룹 생성:
  1. AWS 콘솔 > EC2 > 보안 그룹 생성.
  2. 보안 그룹을 EC2 인스턴스에 연결.
  3. 인바운드 및 아웃바운드 규칙 추가(프로토콜, 포트 범위, 소스/목적지 설정).

예제 규칙:

유형프로토콜포트 범위소스

3. 보안 그룹을 사용하는 경우

• 개별 인스턴스 보안이 필요한 경우: 특정 인스턴스별로 세밀한 보안 규칙을 적용해야 할 때.
• 스테이트풀 방식이 필요한 경우: 응답 트래픽을 자동으로 허용하는 동작이 필요한 경우.
• 유연한 설정: 규칙이 동시에 평가되므로 규칙 설정이 단순하고 이해하기 쉽습니다.

네트워크 ACL과 보안 그룹 비교

특징네트워크 ACL보안 그룹

언제 무엇을 사용해야 할까?

1. 네트워크 ACL을 사용하는 경우:
   • 여러 인스턴스가 포함된 서브넷에 대해 공통 보안 규칙을 적용하려는 경우.
   • 트래픽의 기본적인 차단/허용이 필요한 경우.
   • 규칙을 더 세밀하게(예: 요청/응답 따로) 관리하고 싶은 경우.
2. 보안 그룹을 사용하는 경우:
   • 인스턴스별로 세부적인 보안을 설정하고 싶은 경우.
   • 응답 트래픽을 자동으로 처리하는 스테이트풀 동작이 필요한 경우.
   • 규칙을 직관적으로 관리하고 싶은 경우.
3. 둘을 조합해서 사용하는 경우:
   • 서브넷 레벨의 기본 보안은 네트워크 ACL로 설정하고, 개별 인스턴스의 세부 보안은 보안 그룹으로 설정.
   • 예: 네트워크 ACL에서 서브넷 내 기본 트래픽을 차단하고, 보안 그룹에서 특정 트래픽만 허용.

왜 하나의 서버에 하나의 IP만 쓰지 않고 여러개의 사설IP를 부여하는걸까?

예을 들어 하나의 ec2 서버를 만든다고 가정하자.

그럼 보통 하나의 ec2 인스턴스에 하나의 web서버만 띄우므로 하나의 ip만 지정해주면 된다 근데 보통 여러개의 ip를 할당해 준다 왜 그런걸까? 

여러 대역의 IP 할당 이유

IP 대역은 클라우드 환경에서는 VPC안에 서브넷을 정의할 때, 사설 IP대역을 미리 정의합니다.

예를 들어, 10.0.118.0/29 라는 작은 서브넷을 할당하면, 8 개의 IP주소가 생성됩니다.

그럼 8개의 주소를 모두 사용할 수 있을것 같지만 그렇지 않습니다.

실은 6개의 주소만 사용이 가능합니다.

- 사용 가능한 IP : 10.0.0118.1 ~ 10.0.118.6

- 예약된 IP : 10.0.118.0(네트워크 주소), 10.0.118.7(브로드캐스트 주소)

또 AWS에서 IP 주소 예약에도 사용됩니다.

- 첫번째 IP : VPC 내부 라우터 주소

- 두번째 IP : AWS에서 DNS를 위한 주소

- 마지막 IP : 브로드캐스트 용도로 예약

하나의 서버에 하나의 IP만 사용하지 않는 이유

위는 ip 기준으로 대역을 설정하는 이유를 설명했습니다.

위의 조건을 봐도 그럼 3개의 ip만 할당하면 되는데 더 할당하는 이유를 알아보겠습니다.

확장성을 고려한 설계

서버가 한 대만 존재하는 환경은 드뭅니다. 일반적으로 네트워크는 여러 서버, 서비스, 장비가 함께 동작됩니다.

그런 이유로 대역을 미리 할당해 놓으면 새로운 서버를 추가하거나 서비스를 확장할 때 추가 IP를 쉽게 사용할 수 있습니다.

하나의 서버에 여러 인터페이스가 필요할 수 있음

프라이빗 IP : 내부 DB 용

퍼블릭 IP : 외부 인터넷 통신(웹 요청)

관리 네트워크 : 서버 관리와 모니터링용 별도 네트워크

로드 밸런싱과 고가용성

여러 서버가 하나의 서비스를 제공하는 경우, 로드 밸런싱을 통해 트래픽을 분산해야 합니다.

이때, 여러 서버가 같은 네트워크 대역세 속해 있어야 통신이 원활합니다.

인터넷 게이트웨이와 라우팅 테이블을 이용해서 외부 인터넷과 통신하는 방법을 알아 보았다. 

그렇다면 private한 리소스가 외부의 리소스(인터넷)으로 액세스 할수 있는 방법은 무엇일까??? 

그때 바로 nat 게이트웨이를 쓴다.

NAT 게이트웨이란?

- 프라이빗 서브넷의 리소스(예 : EC2 인스턴스) 가 공인 IP를 통해 인터넷에 나갈 수 있도록 허용합니다.

- 인터넷에서 프라이빗 서브넷으로 들어오는 트래픽은 차단됩니다.

- AWS에서 완전 관리형으로 제공되는 서비스로, 사용자가 직접 NAT 장치를 설정하지 않아도 됩니다.

- NAT를 이용하는 이유는 대게 사설 네트워크에 속한 여러 개의 호스트가 하나의 공인 IP 주소를 사용하여 인터넷에 접속하기 위함이다.

내가 생각하기에는 이 마지막 설명이 중요한것 같다.

예를 들어 내가 집에서 사용하는 IPv4 주소는 172.16.0.0 으로 할당 받았다고 가정한다.

그럼 나는 172.16.0.0 은 사설 ip이고 만약 다른 가정이나 카페, 회사에서  나랑 같은 ip가 존재할수 있다. 

그럼 인터넷에 요청을 하고 받을때 어떻게 내 주소를 찾는 것일까?

그때 바로 NAT가 필요하다. NAT가 내 사설 ip를 기억하고 nat는 실제로 인터넷과 통신할때는 공인 ip로 변환해서 나가고 다시 데이터를 받을 떄 NAT가 가지고 있던 주소로 오는것이다

위와 같이 나는 private subnet을 두고 내부에서만 사용하고 싶다. 근데 RDS가 외부 인터넷을 통해 업데이트를 해야 할 일이 생긴다면 어떻게 해야 할까? 그때 공인 ip를 따로 만들어서 IGW를 연결해줘야 할까?

위의 경우에 NAT gateway 를 사용한다. 인터넷 접속이 가능한 public subnet에 NAT Gateway를 생성해두고 private subnet이 외부 인터넷으로 나갈 경우에만 라이팅을 추가한다. NAT Gateway는 내부에서 외부로의 접속만 가능하며 외부에서 NAT Gateway를 이용하여 접속하는 것은 불가능하다.

위의 nat 게이트웨이에 들어가서 생성을 한다

이렇게 되면 할당된 탄력적 IP(공인 IP)로 subnet에 있는 리소스 들이 나갈수 있게 됩니다.

위와 같이 설정하면 결국

private subnet -> nat gateway -> internet gateway -> 인터넷 

으로 나가게 됩니다.

이번에는 VPC와 subnet 을 실질적으로 인터넷 또는 subnet끼리의 통신을 위한 AWS 라이팅 테이블(Routing table)과 인터넷 게이트웨이(Internet Gateway)에 대해 알아보겠습니다.

AWS 네트워크 설계의 핵심 요수 중 하나는 라우팅 테이블과 인터넷 게이트웨이입니다.이 두가지는 VPC(가상 사설 클라우드) 내부의 트래픽 흐름을 제어하고, 외부 네트워크와의 연결을 가능하게 합니다. 

라우팅 테이블(Routing Table)

라우팅 테이블은 VPC내에서 트래픽이 어디로 가야 할지 결정하는 규칙의 집합입니다. 각 서브넷은 하나의 라우팅 테이블과 연결되며, 라우팅 테이블을 통해 트래픽이 서브넷 간, 또는 외부 네트워크로 전달됩니다.

라우팅 테이블의 구성요소

라우팅 테이블은 다음과 같은 두 가지 주요 요소로 구성됩니다.

 - 대상(Target) : 트래픽의 목적지 IP 주소 범위(CIDR)

 - 타겟(Target) : 해당 트래픽이 전달되어야 할 대상(인터넷 게이트웨이, nat 게이트웨이, 피어링 연결 등)

라우팅 테이블의 기본 동작

1. VPC를 생성하면 자동으로 기본 라우팅 테이블이 생성됩니다.

2. 기본 라우팅 테이블은 해당 VPC 내부의 모든 서브넷 간 트래픽을 허용합니다.

3. 외부 트래픽을 처리하려면 명시적으로 경로를 추가해야 합니다.

* VPC 피어링 연결은 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결입니다. 

인터넷 게이트웨이(Internet Gateway)

인터넷 게이트웨이는 VPC(Virtual Private Cloud)와 외부 인터넷을 연결해주는 중요한 네트워크 구성 요소로, 크랄우드 환경에서 서버가 외부와 통신하기 위해 꼭 필요한 기능을 담당합니다.

인터넷 게이트웨이의 역활

1. VPC 내부 리소스가 인터넷과 양방향으로 통신할 수 있도록 지원합니다.

2.퍼블릭 ip 주소를 통해 인터넷에 접근하거나 외부에서 접근 가능하도록 설정합니다.

3. 네트워크 주소 변환(NAT)를 통해 VPC 내부 사설 IP와 퍼블릭 IP간의 트래픽을 매핑합니다.

인터넷 게이트웨이와 NAT 게이트웨이의 차이점

IGW는 퍼블릭 서브넷에서 주로 사용되며, 인터넷과 양방향 트래픽을 허용합니다.

반면, NAT 게이트웨이는 프라이빗 서브넷에서 사용되어 내부 리소스가 외부로 트래픽을 보낼 수는 있지만 외부에서 접근은 허용하지 않습니다.

이제 실제 만들어보자

라우팅 테이블(Routing Table) 만들기

라우팅 테이블은 기본 vpc를 만들고 서브넷을 만들경우 자동으로 만들어 진다. 이유는 aws에서 vpc 내부 통신을 위한 로컬 라우팅이 자동 생성되기 때문이다. 그래서 기본적으로 하나의 vpc아래에 있다면 로컬 라우팅 테이블을 이용하여 통신이 가능하다.

이제 인터넷 게이트웨이를 만들어서 vpc와 연동해야 외부 인터넷과 통신 할 수 있다.

먼저 인터넷 게이트 웨이를 태그 이름으로 설정하고 

우측 상단에서 내가 사용중인 vpc에 연결만 해주면 끝난다. 

하나의 vpc는 하나의 게이트웨이와만 연결이 가능하다.

여러 vpc에서 인터넷 트래픽이 필요하다면, 각 vpc에 별도의 인터넷게이트웨이를 생성해야 한다.

1. Security Group (SG): 가상 방화벽

• 역할: EC2 인스턴스, RDS, Lambda 등 AWS 리소스에 대한 인바운드(Inbound) 및 아웃바운드(Outbound) 트래픽을 제어.
• 특징:
  • 상태 기반(Stateful): 인바운드 요청을 허용하면, 이에 대한 응답은 자동으로 허용.
  • 규칙은 허용만 가능(Deny는 설정 불가).
  • 특정 IP, CIDR 범위, 포트, 프로토콜 기반으로 제어 가능.
• 사용 예:
  • 포트 80(HTTP)과 443(HTTPS)을 허용.
  • 내부 VPC 네트워크에서만 특정 리소스 접근 허용.

2. Network ACL (NACL): 네트워크 레벨의 ACL

• 역할: 서브넷 수준에서 트래픽을 제어.
• 특징:
  • 비상태 기반(Stateless): 인바운드와 아웃바운드 규칙을 별도로 설정해야 함.
  • 허용(Allow)과 거부(Deny) 규칙 모두 가능.
  • 규칙은 번호순으로 평가(숫자가 낮은 규칙이 우선 적용).
  • 서브넷에 연결된 모든 리소스에 적용됨.
• 사용 예:
  • 서브넷 레벨에서 특정 IP의 접근을 완전히 차단.
  • 서브넷에서의 아웃바운드 트래픽을 제한.

3. AWS WAF (Web Application Firewall): 애플리케이션 방화벽

• 역할: ALB, API Gateway, CloudFront 등의 HTTP/HTTPS 트래픽을 보호.
• 특징:
  • SQL Injection, XSS(크로스 사이트 스크립팅) 등 웹 공격 차단.
  • IP 허용/차단, 요청 속도 제한(Rate Limiting).
  • 커스텀 규칙 및 AWS Managed 규칙 제공.
• 사용 예:
  • 악성 요청 차단.
  • IP 블랙리스트/화이트리스트 설정.

4. IAM (Identity and Access Management): AWS 리소스 접근 제어

• 역할: AWS 서비스와 리소스에 대한 사용자 및 서비스의 권한을 관리.
• 특징:
  • 사용자, 그룹, 역할(Role)을 기반으로 정책 설정.
  • 특정 서비스(API) 호출만 허용하거나 제한.
  • 리소스 기반 정책(S3, Lambda, API Gateway 등)과도 통합.
• 사용 예:
  • EC2 인스턴스에서 S3 버킷에 접근하도록 허용.
  • 특정 사용자만 DynamoDB에 쓰기 작업 허용.

5. VPC Endpoint Policy: PrivateLink를 통한 접근 제어

• 역할: 특정 서비스(S3, DynamoDB 등)에 대한 VPC 내부 트래픽을 제어.
• 특징:
  • 엔드포인트에 정책을 설정하여 특정 작업(API 호출)을 허용/차단.
  • 인터넷을 거치지 않고 AWS 리소스에 직접 연결.
• 사용 예:
  • S3 버킷에 대한 VPC 내부에서의 특정 IP 접근만 허용.

6. CloudFront Geo-Restriction 및 Origin Access Control (OAC)

• 역할: 콘텐츠 배포를 제한하고, S3 등 백엔드 리소스를 보호.
• 특징:
  • Geo-Restriction: 특정 국가나 지역에서의 접근 차단.
  • OAC: S3 버킷에 CloudFront만 접근하도록 설정.
• 사용 예:
  • 한국 외 지역에서의 콘텐츠 접근 차단.
  • S3 정적 콘텐츠를 CloudFront로만 서빙.

7. AWS Shield 및 AWS Firewall Manager

AWS Shield

• 역할: DDoS 공격 방어.
• 특징:
  • AWS Shield Standard는 모든 계정에서 기본 제공.
  • AWS Shield Advanced는 더 강력한 보호 및 비용 방지 기능 제공.
• 사용 예:
  • ALB나 CloudFront의 DDoS 공격 보호.

AWS Firewall Manager

• 역할: 여러 AWS 계정과 리소스에 대한 방화벽 정책 중앙 관리.
• 특징:
  • WAF, Security Group, VPC NACL 규칙을 계정 단위로 관리.
• 사용 예:
  • 여러 계정에서 WAF 규칙을 일괄 적용.

8. Elastic Load Balancer (ELB) Listener 및 Rule

• 역할: 요청의 URL 경로, 도메인, IP에 따라 트래픽 라우팅.
• 특징:
  • ALB에서 경로 기반(/api, /web) 및 호스트 기반(api.example.com) 라우팅 설정.
  • HTTPS 인증서로 보안 트래픽 처리.
• 사용 예:
  • /api 요청은 Lambda로, /web 요청은 EC2로 전달.

9. S3 Bucket Policy 및 CORS

• 역할: S3 버킷에 대한 접근을 제어.
• 특징:
  • 특정 IAM 사용자, 역할, IP만 허용 가능.
  • CORS 설정을 통해 다른 도메인에서의 액세스를 허용.
• 사용 예:
  • 특정 VPC에서만 S3 객체 읽기/쓰기 허용.

10. RDS 및 ElastiCache의 Network-Level 접근 제어

• 역할: 데이터베이스의 네트워크 접근을 제어.
• 특징:
  • RDS와 ElastiCache는 Security Group으로 접근 제어.
  • 특정 IP 또는 애플리케이션만 데이터베이스에 연결 허용.
• 사용 예:
  • RDS 데이터베이스에 내부 애플리케이션 서버만 접근 허용.

11. Lambda Function URL

• 역할: Lambda 함수에 대한 HTTP(S) 엔드포인트 제공.
• 특징:
  • CORS 설정으로 도메인별 접근 제어.
  • IAM 정책과 연동하여 인증 설정.
• 사용 예:
  • 특정 사용자만 Lambda URL 호출 허용.

정리

AWS에서 ACL과 Security Group과 같은 역할을 수행하는 도구는 다양한 계층에서 접근과 보안을 관리합니다:

• 네트워크 계층: Security Group, NACL.
• 애플리케이션 계층: WAF, API Gateway.
• 리소스 레벨: IAM, S3 Bucket Policy.
• 글로벌/배포 레벨: Route 53, CloudFront, Firewall Manager

1. Security Group (SG): 가상 방화벽

• 역할: EC2 인스턴스, RDS, Lambda 등 AWS 리소스에 대한 인바운드(Inbound) 및 아웃바운드(Outbound) 트래픽을 제어.
• 특징:
  • 상태 기반(Stateful): 인바운드 요청을 허용하면, 이에 대한 응답은 자동으로 허용.
  • 규칙은 허용만 가능(Deny는 설정 불가).
  • 특정 IP, CIDR 범위, 포트, 프로토콜 기반으로 제어 가능.
• 사용 예:
  • 포트 80(HTTP)과 443(HTTPS)을 허용.
  • 내부 VPC 네트워크에서만 특정 리소스 접근 허용.

2. Network ACL (NACL): 네트워크 레벨의 ACL

• 역할: 서브넷 수준에서 트래픽을 제어.
• 특징:
  • 비상태 기반(Stateless): 인바운드와 아웃바운드 규칙을 별도로 설정해야 함.
  • 허용(Allow)과 거부(Deny) 규칙 모두 가능.
  • 규칙은 번호순으로 평가(숫자가 낮은 규칙이 우선 적용).
  • 서브넷에 연결된 모든 리소스에 적용됨.
• 사용 예:
  • 서브넷 레벨에서 특정 IP의 접근을 완전히 차단.
  • 서브넷에서의 아웃바운드 트래픽을 제한.

3. AWS WAF (Web Application Firewall): 애플리케이션 방화벽

• 역할: ALB, API Gateway, CloudFront 등의 HTTP/HTTPS 트래픽을 보호.
• 특징:
  • SQL Injection, XSS(크로스 사이트 스크립팅) 등 웹 공격 차단.
  • IP 허용/차단, 요청 속도 제한(Rate Limiting).
  • 커스텀 규칙 및 AWS Managed 규칙 제공.
• 사용 예:
  • 악성 요청 차단.
  • IP 블랙리스트/화이트리스트 설정.

4. IAM (Identity and Access Management): AWS 리소스 접근 제어

• 역할: AWS 서비스와 리소스에 대한 사용자 및 서비스의 권한을 관리.
• 특징:
  • 사용자, 그룹, 역할(Role)을 기반으로 정책 설정.
  • 특정 서비스(API) 호출만 허용하거나 제한.
  • 리소스 기반 정책(S3, Lambda, API Gateway 등)과도 통합.
• 사용 예:
  • EC2 인스턴스에서 S3 버킷에 접근하도록 허용.
  • 특정 사용자만 DynamoDB에 쓰기 작업 허용.

5. VPC Endpoint Policy: PrivateLink를 통한 접근 제어

• 역할: 특정 서비스(S3, DynamoDB 등)에 대한 VPC 내부 트래픽을 제어.
• 특징:
  • 엔드포인트에 정책을 설정하여 특정 작업(API 호출)을 허용/차단.
  • 인터넷을 거치지 않고 AWS 리소스에 직접 연결.
• 사용 예:
  • S3 버킷에 대한 VPC 내부에서의 특정 IP 접근만 허용.

6. CloudFront Geo-Restriction 및 Origin Access Control (OAC)

• 역할: 콘텐츠 배포를 제한하고, S3 등 백엔드 리소스를 보호.
• 특징:
  • Geo-Restriction: 특정 국가나 지역에서의 접근 차단.
  • OAC: S3 버킷에 CloudFront만 접근하도록 설정.
• 사용 예:
  • 한국 외 지역에서의 콘텐츠 접근 차단.
  • S3 정적 콘텐츠를 CloudFront로만 서빙.

7. AWS Shield 및 AWS Firewall Manager

AWS Shield

• 역할: DDoS 공격 방어.
• 특징:
  • AWS Shield Standard는 모든 계정에서 기본 제공.
  • AWS Shield Advanced는 더 강력한 보호 및 비용 방지 기능 제공.
• 사용 예:
  • ALB나 CloudFront의 DDoS 공격 보호.

AWS Firewall Manager

• 역할: 여러 AWS 계정과 리소스에 대한 방화벽 정책 중앙 관리.
• 특징:
  • WAF, Security Group, VPC NACL 규칙을 계정 단위로 관리.
• 사용 예:
  • 여러 계정에서 WAF 규칙을 일괄 적용.

8. Elastic Load Balancer (ELB) Listener 및 Rule

• 역할: 요청의 URL 경로, 도메인, IP에 따라 트래픽 라우팅.
• 특징:
  • ALB에서 경로 기반(/api, /web) 및 호스트 기반(api.example.com) 라우팅 설정.
  • HTTPS 인증서로 보안 트래픽 처리.
• 사용 예:
  • /api 요청은 Lambda로, /web 요청은 EC2로 전달.

9. S3 Bucket Policy 및 CORS

• 역할: S3 버킷에 대한 접근을 제어.
• 특징:
  • 특정 IAM 사용자, 역할, IP만 허용 가능.
  • CORS 설정을 통해 다른 도메인에서의 액세스를 허용.
• 사용 예:
  • 특정 VPC에서만 S3 객체 읽기/쓰기 허용.

10. RDS 및 ElastiCache의 Network-Level 접근 제어

• 역할: 데이터베이스의 네트워크 접근을 제어.
• 특징:
  • RDS와 ElastiCache는 Security Group으로 접근 제어.
  • 특정 IP 또는 애플리케이션만 데이터베이스에 연결 허용.
• 사용 예:
  • RDS 데이터베이스에 내부 애플리케이션 서버만 접근 허용.

11. Lambda Function URL

• 역할: Lambda 함수에 대한 HTTP(S) 엔드포인트 제공.
• 특징:
  • CORS 설정으로 도메인별 접근 제어.
  • IAM 정책과 연동하여 인증 설정.
• 사용 예:
  • 특정 사용자만 Lambda URL 호출 허용.

정리

AWS에서 ACL과 Security Group과 같은 역할을 수행하는 도구는 다양한 계층에서 접근과 보안을 관리합니다:

• 네트워크 계층: Security Group, NACL.
• 애플리케이션 계층: WAF, API Gateway.
• 리소스 레벨: IAM, S3 Bucket Policy.
• 글로벌/배포 레벨: Route 53, CloudFront, Firewall Manager

aws에서 ip설정을 하다 보니까 왜 10.x.x.x를 쓰는곳이 있고 왜 172.x.x.x를 쓰는 곳이 있을까 뭐가 다르지? 라는 생각을 해봤다.

RFC 1918의 사설 IP 범위

사실 결론부터 말하자면 네트워크의 범위의 차이이지 사용성이나 기능은 똑같다

둘다 IPv4 블록에서 프라이빗 IP 주소를 위한 범위이며, 모두 RFC 1918 에 따라서 사설 네트워크에서 사용할 수 있는 주모 범위이다. 

즉 인터넷에서는 라우팅되지 않는다.

10.x.x.x 와 172.x.x.x의 차이

그래서 둘의 큰 차이가 뭐냐고 하면 주소 범위의 차이, 주소 사용성, IP 충돌 가능성의 문제이다.

주소 범위

10.x.x.x 

- 10.0.0.0 ~ 10.255.255.255

- /8의 크기로 사용되며 가장 큰 범위를 제공

- 넓은 네트워크 범위가 필요할 때 유용

172.x.x.x

- 172.16.0.0 ~ 172.31.255.255

- /12의 크기로 사용되며 제한적

- 중간 크기의 네트워크에 적합

주소 사용성

10.x.x.x 

- 가장 널리 사용되며, 특히 대규모 기업 네트워크 및 클라우드 환경에서 선호

- AWS VPC에서 기본적으로 추천되는 CIDR 범위입니다.

- 범위가 크기 때문에 충돌 가능성이 적습니다.

172.x.x.x

- 대규모 네트워크보다는 중간 크기 또는 특정 영역에서 선호됩니다.

- 일부 네트워크 설계자는 10.x.x.x와 구분하기 위해 사용하기도 합니다.

IP 충돌 가능성

중복의 가능성 떄문에 10.x.x.x는 중복 가능성이 적고 172.x.x.x는 중복 가능성이 높습니다.

요약

항목10.x.x.x172.x.x.x