[AWS] AWS 3-Tier 아키텍처 실습기

오늘은 AWS 3-Tier 아키텍처를 만들어보는 실습에 대한 후기를 남기려고 한다.

 

AWS 3-Tier 아키텍처는 다음과 같이 설계해보았다.

 

---

1. 아키텍처 구조 잡기

우선 VPC 서브넷을 총 6개의 서브넷으로 구성했다.

1. public Subnet 2개

2. private subnet 2개

3. DB subnet 2개

 

2개씩 만든 이유는 고가용성(HA)을 위해 설계하였다. 여기서 말한 고가용성은 한쪽 서버에 완전히 장애가 생겨도 물리적으로 먼 거리에 있는 서버 2개를 사용하기 때문에 서비스는 정상적으로 작동하는 것이다.

 

private subvet에는 중요한 정보가 있기 때문에 외부 사용자는 private subvet에 바로 접속 못하고 로드밸런서를 통해서만 접속하게 했다. public subnet에는 Bastion Host를 만들어 외부에서 내부에 접속할 수 있는 유일한 통로를 만들었다.

 

다시말해

• 서비스 정문 (ALB, 80번): 일반 사용자가 드나드는 곳이다. 누구든 HTTP 요청은 환영이다.
• 관리자 쪽문 (Bastion, 22번): 오직 나(관리자)만 아는 문이다. 내 PC의 IP를 가진 사람만 열 수 있다.

실제 서버(Private EC2)는 이 두 문을 통해서만 접근이 가능하고, 데이터베이스는 그 서버에서만 접근이 가능하다. 마치 왕궁처럼 성벽(VPC) → 정문·쪽문(Public Subnet) → 내실(Private Subnet) → 금고(DB Subnet) 순서로 겹겹이 둘러싸인 구조라고 생각하면 된다.

---

2. 보안 그룹 설정하기

보안 그룹을 설정하다 보면 이런 순간이 온다.

"Private EC2의 80번 포트를 ALB한테 열어줘야 하는데, ALB의 IP를 넣으면 되나?"

이렇게 하면 안 된다. 이유는 하나다.

클라우드 서버의 IP는 휘발성이기 때문이다.

ALB를 만들면 지금 이 순간 IP는 3.34.12.56일 수 있다. 그런데 트래픽 폭주로 스케일 아웃되면 IP가 바뀔 수 있고, ALB를 지웠다가 다시 만들면 당연히 IP가 바뀐다. 그 순간 보안 그룹 규칙에 써있는 3.34.12.56은 유령 IP가 되고, 서비스는 다운된다.

 

반면 보안 그룹 ID(sg-xxxxxxxx)는 논리적 식별자라서 IP가 바뀌든 인스턴스가 교체되든 상관없다. AWS가 알아서 해당 보안 그룹에 속한 리소스의 IP를 실시간으로 추적해주기 때문이다.

 

쉽게 비유하면 이렇다.

❌ IP 방식: 얼굴만 아는 친구 — 성형수술 하면 못 알아본다
✅ 보안 그룹 ID 방식: 사원증으로 입장 — 사람이 바뀌어도 사원증만 있으면 OK

설정 정리는 아래와 같다.

대상 서버포트소스

Bastion Host	22	내 PC 공인 IP (x.x.x.x/32)
ALB	80	0.0.0.0/0 (전체 공개)
Private EC2	22	Bastion의 보안 그룹 ID
Private EC2	80	ALB의 보안 그룹 ID

---

3. Bastion Host로 징검다리 SSH 접속하기

배스천 호스트는 관리자의 징검다리 역할을 한다. 내 PC → 배스천 → Private EC2, 이렇게 두 번 SSH를 타야 하는 구조이다.

여기서 처음 떠오르는 자연스러운 생각이 있다.

"배스천에서 Private EC2로 접속할 때도 키가 필요하겠네? 그럼 배스천 서버에 .pem 파일 올려놓으면 되겠다!"

하지만 이렇게 하면 안 됐다. 이렇게 한다면 배스천은 의미가 없어질 것이다.

배스천에는 public ip가 있기 때문에 인터넷에 노출된 서버라 항상 공격 대상이 될 수 있다. 만약 누군가 배스천을 뚫었을 때를 생각해보자.

• 배스천에 키 파일이 없다면: "배스천은 뚫었는데 더 이상 못 들어가겠네." ✅
• 배스천에 키 파일이 있다면: "어, Private EC2 키까지 여기 있네? 감사합니다." ❌

배스천에 키를 두는 건 금고 열쇠를 금고 위에 올려두는 것과 같다. 쪽문을 뚫으면 내실까지 한 번에 털리는 구조가 되는 것이다.

이를 해결하는 방법이 바로 SSH 에이전트 포워딩이다. 키 파일 자체를 전달하는 게 아니라, '이 키로 서명할 수 있는 능력'을 임시로 빌려주는 것이라고 생각하면 된다. 실제로 키 파일은 내 PC를 절대 떠나지 않는다.

명령어 순서는 아래와 같다.

 

 

bash

# Step 1: 내 PC에서 SSH 키 관리자(에이전트) 실행
eval $(ssh-agent -s)

# Step 2: 에이전트에게 내 키 등록
ssh-add [키이름].pem

# Step 3: 배스천 접속 시 -A 옵션으로 에이전트 권한 전달
ssh -A ec2-user@[배스천_공인IP]

# Step 4: 배스천 안에서 추가 설정 없이 Private EC2 접속
ssh ec2-user@[프라이빗_사설IP]
```

`-A` 옵션 하나가 전부다. 이 한 글자가 "키 복사"와 "에이전트 포워딩"의 차이를 만들어낸다.

---

## 🚨 트러블슈팅

### `Permission denied (publickey)` 에러가 난다면?

배스천까지는 접속이 됐는데 Private EC2로 넘어가려니 아래 에러가 뜨는 경우가 있다.
```
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

범인은 거의 항상 셋 중 하나다.

1. ssh-agent를 실행하지 않았다 → eval $(ssh-agent -s) 먼저 했는지 확인하자.
2. ssh-add를 빠뜨렸다 → 에이전트를 켰어도 키를 등록하지 않으면 빈 에이전트이다.
3. -A 옵션을 빠뜨렸다 → 배스천 접속 시 -A가 없으면 포워딩이 일어나지 않는다.

이 세 가지만 체크하면 거의 해결된다.

---

마무리

AWS 보안 설정은 처음엔 그냥 외우는 것처럼 느껴졌다. 그런데 "왜 이렇게 해야 하는가"를 이해하고 나면 설정 하나하나가 의도를 가진 결정처럼 보이기 시작한다.

 

앞으로 최소한의 권한을 줘서 만약 해킹을 당하더라도 피해를 최소화 할 수 있을 것 같다. 이걸 보안 용어로는 최소 권한 원칙(Principle of Least Privilege) 이라고 한다. 이번 3-Tier 실습은 그 원칙을 아키텍처 전체에 적용해본 좋은 연습이었다.

 

다음 실습에서는 NAT Gateway를 붙여서 Private EC2가 외부 패키지를 설치할 수 있게 만들거나, HTTPS를 위한 ACM 인증서 설정으로 이어가 볼 것이다.