AWS H01_Lesson02

VPC

---

왜 쓸까?

 

먼저 VPC가 출시되기 전 사용했던 EC2-Classsic에 대해 살펴보면,

EC2-Classic은 단일 네트워크에서 다른 사용자들과 함께 사용하는 공용 공간이다.

그렇기에 많은 고객의 인스턴스가 위치했고, 인스턴스 수가 많아지면 아래와 같은 문제점이 발생한다.

 

1. 관리의 복잡도 ↑

2. 새 인스턴스 추가 시 모든 라우팅 정보 변경

3. 외부에 노출되기 때문에 보안 ↓

 

그렇다고 사용자가 네트워크 환경을 직접 구축해야 한다면 번거롭고 복잡해진다.

그래서 '사용자별로 독립된 네트워크 공간을 만들어 그 안에서 리소스를 관리하자' 해서 출시된 것이 VPC이다.

 

Security Group vs NACL

	Security Group	NACL
적용 대상	인스턴스 단위	서브넷 단위
기본 정책	기본적으로 All Deny	규칙별로 All/Deny 설정
규칙 적용	한 번에 적용	규칙 번호가 낮은 순서대로
요청 정보	Stateful	Stateless

 

NACL

NACL은 Stateless하다.

Stateless는 Server가 Client의 상태를 보존하지 않는다는 뜻이다.

예를 들어, 현재 Inbound 규칙에 80번 포트가 허용돼있다.

 

Client가 외부에서 http를 통해 접속하면 Inbound 규칙에 의해 트래픽이 들어온다.

 

그러나 Outbount에서 80포트에 대해 지정해주지 않았기 때문에 요청에 대한 응답 트래픽은 Client에게 도달하지 못한다.

그렇기 때문에 NACL의 규칙 관리는 중요하다.

또 한가지 신경 쓸 것은 Ephemeral Port(임시포트)이다.

[ec2-user@ip-172-31-10-247 ~]$ cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

 

Ephemeral Port는 TCP Connection 시에 커널이 임의로 포트를 Binding 시키는 경우가 있는데,

Amazon AMI의 경우 위와 같이 32768 ~ 60999이다.

따라서 ACL의 Inbound/Outbound에 해당 포트를 허용시켜주는 것이 좋다.

 

Security Group

보안그룹은 적용 대상이 인스턴스 단위이다.

동일 Subnet에 위치한 인스턴스 간의 통신은 NACL의 영향을 받지 않는다.

Security Group은 Stateful하다.

요청 정보를 저장하기 때문에 Inbound 규칙만 적용해주면 Outbound 규칙을 신경쓰지 않아도 된다는 것이 특징이다.

 

 

IAM

---

IAM(Identity and Access Management)은 AWS 리소스에 대해 개별/그룹 액세스를 제어할 수 있는 AWS 서비스이다.

 

왜 필요할까?

 

AWS는 보통 계정 한 개를 가지고 공유하며 사용하는데 이때 모든 사용자가 Root 계정을 사용하면

보안, 사후책임 등 많은 부분에서 문제점이 발생한다.

그래서 Root 관리자를 두고 그 아래 각각의 필요한 권한을 부여한 사용자를 할당한다.

 

크게 사용자, 그룹, 정책, 역할로 나뉜다.

 

사용자 

• Root 계정 외에 임의의 사용자를 생성하고 필요한 권한만을 부여하여 사용

그룹

• 권한을 미리 부여하고 여러 사용자를 한 그룹으로 묶을 때 사용

정책

• 권한들의 모음. 권한을 직접 부여할 순 없고 권한들로 만든 정책을 적용해야 함

역할

• 어떤 객체에 정책을 부여하는 데 있어 사용자와 비슷하지만 그 객체가 사용자가 아닌 사용자가 아닌 서비스나 다른 AWS 계정의 사용자라는 점에 있어서 다름
• 예를 들어, EC2 인스턴스가 S3 버킷의 파일을 읽어오려면 S3Read와 관련된 권한을 주어야 하고 이와 관련된 Role을 만들어서 EC2에 역할을 부여해야 함