[AWS] Private Subnet, NAT, ELB, Elastic IP, S3 (실습)

AWS 기초 - 6

Posted by owin2828 on 2020-01-16 17:12 · 5 mins read

들어가기 앞서


본 포스팅에서는 다음과 같은 구성요소들을 살펴볼 예정이다.

  • Private Subnet을 구성하는 방법
  • Bastion Host를 통해 Private Subnet에 접근하는 방법
  • NAT
  • ELB
  • Elastic IP
  • S3

1. Private Subnet 구성 및 접근


우선 구성하는 방법은 간단하다. 그냥 라우팅 테이블을 하나 만들고,
인터넷 게이트웨이를 설정하지 않으면 그만이다.

접근 또한 마찬가지로 어렵지 않은데, 우선 Bastion Host로 접속 후
다시 내부적으로 접속을 진행하면된다.

대략적으로 그려보면 다음과 같다.
외부 접속 –> Bastion Host –> Private Subnet

약간의 문제가 있다하면 ssh 접속을 위한 키 페어 관리인데,
내부 private subnet에 접속하기 위해 Bastion Host는 각 서브넷의
키 페어를 가지고 있어야 한다.

이런 경우, 관리자들이 적절한 보안 규칙을 세워 키 페어 관리를 해야한다.
그렇지 않으면 Bastion Host에 접속하여 모든 private subnet에 접근이 가능해,
그냥 모두 public으로 만든 것이랑 별반 다름이 없을 수 있기 때문이다.

2. NAT(Network Access Translation)


NAT는 설명했듯이, 인터넷 게이트웨이를 통해 outbound만 허용한다.
이는 AWS의 정책으로 외부에서 접근이 불가하다.

설정하는 방법은 다음과 같이 두 가지 방법이 존재한다.

  1. 인스턴스를 생성하여 설정
  2. 게이트웨이로 생성하여 설정

또한 Elastic IP를 설정하며 유료 서비스다.

Elastic IP를 사용하는 경우, 서버 재부팅 시에도 IP가 고정된다.

3. ELB(Elastic Load Balancer)



생성은 서비스에서 EC2를 검색 후, 좌측 메뉴에서 로드밸런서에서 할 수 있다.
생성 시, 3개 중 하나를 고르라고 하는데 기본적으로 Classic을 선택하면 된다.

그 후 대략 다음의 단계에 따라서 구성한다.

  1. 본인의 VPC와 서브넷을 잘 선택
  2. 보안그룹 할당: 기존그룹에서 생성한 그룹 선택
  3. EC2 인스턴스 추가: 이 단계에서 우리의 public 인스턴스를 추가한다.

위와 같은 설정의 이점은 EC2에 ELB를 거치치 않고 들어오는 경우를 막는 것이다.
즉, prviate EC2에 웹 프로토콜로 접속 시, ELB를 통해서 접근해야 한다.
이를 통해 다음과 같은 흐름으로 Inbound를 설정할 수 있다.

ACL –> ELB –> EC2
ELBBastion Host를 제외한 나머지 subnet은 private 설정을 해야한다.

또한 EC2는 다음과 같은 3가지 방법으로 구분이 되는데,

  1. private IP
  2. Public IP + address
  3. Unique ID(Instance ID)

이 중, 3번째 방법인 유니크한 ID가 ELB에 제공되어야 밸런싱을 잘 해준다고 한다.

4. Elastic IP(탄력적 IP)


AWS에서 Elastic IP를 가지고 있지 않은 리소스의 경우,
재부팅 시 IP의 변경이 일어난다.
이러한 현상을 막기 위해 Elastic IP를 설정하면 IP가 고정된다.

이러한 서비스는 Floating되어 있다고 한다.
무슨 말이나면, 특정 객체에 묶여있는 것이 아니라
상황에 따라 이리 붙었다 저리 붙었다가 가능하다는 뜻이다.

이러한 특징 때문에 특정 서비스가 다운되면 Elastic IP를
다른쪽으로 붙여서 트래픽을 그 쪽으로 유도해 장애에 대처할 수 있게 된다.

End-User에게 보여지는 IP는 고정된 IP이기 때문이다.

혹은 서비스를 이관할 때도 이 서비스를 이용하여
유동적으로 트래픽을 처리할 수 있게 된다.

5. S3(Simple Storage Service)



S3는 VPC 외부에 존재하는 서비스로써 Bucket 단위로 구분하며,
AWS에서 S3 서비스를 검색하여 시작할 수 있으며 다음과 같은 특징이 있다.

  1. S3는 내부적으로 2군데 더 미러링을 한다.
    현재 내 region에 1개 + 가장 가까운 region에 1개에 구성함으로써,
    어떤식으로 장애가 나더라도 대응 할 수 있는 구조이다.

  2. S3는 외부에 보여지지 않으므로, 버킷레벨로 권한을 설정하거나
    파일레벨로 권한을 설정할 수 있다.

  3. S3는 스토리지 서비스 이므로, DB와의 연동은 안된다.
    즉 S3에는 Static Data만 저장할 수 있다.
    이러한 특징으로 인해, 서버사이드 언어를 저장하고 돌려도 작동하지 않는다.

  4. S3는 AZ 밖에 존재하게 되므로,
    VPC 안에 있는 객체들과의 통신은 과금을 유발하게 된다.
    이 문제를 피하기 위해, S3에서 인증토큰을 이용하여 허용된 REST API만 받아주면 된다고 한다.


6. 끝마치며


AWS에 대해서 배워볼까? 로 시작했던 시리즈의 포스팅이 끝났다.
단순하고 짧게 쓰려고 했지만, 쓰다보니 점점 길어지게 되었다.

AWS는 늘 t2.micro 인스턴스 하나만 띡 만들어서 대충 써봤던게 전부였는데,
이번 기회로 새로운 눈이 뜨여지게 된 것 같다.

배웠으니 앞으로 어딘가에 적용하기를 기대하고,
누군가에게 이 글이 도움이 되었길 바라며 포스팅을 마친다.