클라우드 보안

[기본 탐구] EC2 파먹기

수달정보보호 2026. 3. 10. 12:38

EC2란 '안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 웹 서비스'라 정의된다. 클라우드와 완전 초면인 사람에게 이렇게 설명한다면 아마 알아듣지 못할 것이다. 쉽게 말하면, EC2는 모든 인프라의 기본 단위인 것이다.

 

우리가 노트북을 산다고 했을 때, 사람들은 스펙을 따지기 이전에 그 목적이 무엇인지부터 확정짓곤 한다. 단순 학습용인지, 업무용인지, 취미용인지, 수달 동영상 감상용인지, 고사양 게임용인지, AI 구축을 위한 것인지에 따라 적절한 스펙의 범위가 정해지곤 하기 때문이다. EC2도 마찬가지다. EC2도 그래서 종류가 다양하다. 100개는 그냥 넘어가니 말이다. 그리고 우리가 EC2를 고를 때에도 목적이 있을 것이다. 범용, 컴퓨팅 최적화, 메모리 최적화, 컴퓨팅 가속화, 스토리지 최적화 같이 말이다.

 

m5.large를 예시로 들면, 여기 이름에 많은 정보가 포함되어 있다. m은 패밀리 단위로, 여기서는 범용을 의미하고, 5는 5세대 모델이라는 것을 의미한다. 그러니 숫자가 높을수록 최신이라는 말이 되겠다. 다음 large는 사이즈를 말하는 것으로, CPU, RAM 같은 것들의 용량이 어느 수준인지를 말한다. 평생 S, M만 입은 내게 라지는 충분히 큰 사이즈지만, AWS 세계관에서 LARGE는 약자 그자체다. XL, 2XL, 4XL, 8XL, 12XL, 16XL, 24XL 등이 있으니 말이다. 그러니 m5.large는 무난무난한 스펙을 그렇게 데이터량이 방대하지 않은 곳에서 사용하고 싶다면 적절한 선택이 될 것이다. MySQL, PostgreSQL, Redis 서버를 올릴 때 등 말이다. 따라서 수없이 많은 인스턴스 중에 목적이 무엇이냐에 따라 패밀리, 세대, 사이즈의 스펙을 결정짓는 것이다.

 

그 다음에 알아야 하는 것이 EBS다. EC2가 본체라면, EBS는 외장 SSD라 할 수 있다. EBS는 EC2와 네트워크로 연결되어 있고, 그렇기에 EC2 인스턴스가 고장나서 삭제되어도 EBS만 똑 떼어내서 다른 EC2에 붙일 수 있다. 컴퓨터 본체가 고장나면 버리겠지만, 연결되어 있던 외장 하드를 새로운 컴퓨터에 꽂으면 계속 작업을 할 수 있는 것과 같다. EC2에 문제가 생겨도 데이터 보존에는 문제가 없다는 것이다. 그러니까 EBS는 EC2 내부에 박혀있는 것이 아니며, 보통 서버를 운영할 때 OS가 깔린 C드라이브 외에 실제 중요한 데이터만 담는 D드라이브를 따로 만드는 개념이다. 그리고 EBS에는 스냅샷 기능이 있는데, 이 스냅샷은 현재 상태를 그대로 복제해서 S3라는 더욱 안전한 저장소에 백업하는 기능이다. EBS 자체가 물리적으로 망가지는 매우매우 극단적인 상황이 있을 경우에도, 이 스냅샷만 있으면 1분 만에 똑같은 내용의 EBS를 새로 찍어낼 수 있다. 그리고 물론 SSD도 종류와 스펙이 다양하듯, EBS도 타입이 다양하다. 가장 범용적인 gp3, 빠른 입출력이 필요한 대규모 DB용인 IO2, 보통 로그 분석용으로 많이 쓰이는 st1 등이 있다. 

 

그다음엔 EC2를 어디에 둘 건지를 결정해야 할 것이다. VPC는 AWS 안에서 나만이 소유한 가상 사유지 같은 개념이다. 이 사유지를 효율적으로 관리하기 위해 용도별로 땅을 나누는 것이 서브넷의 개념이다. 서브넷은 퍼블릭과 프라이빗이 나뉘는데, 퍼블릭은 이름에서도 알 수 있듯, 인터넷 게이트웨이와 연결되어 있어 외부 인터넷과 직접 통신이 가능하다. 보통 웹 서버, 로드 밸런서처럼 유저가 직접 접속해야 하는 서비스를 두는 곳인데, 여기에 있는 EC2는 반드시 퍼블릭 IP 또는 탄력적 IP를 가져야 밖에서 찾아올 수 있다. 반면, 프라이빗 서브넷은 외부 인터넷과는 차단된 곳으로, DB나 사내 기밀 처리 서버 등 외부 노출을 금지하는 서비스를 두곤 한다. 그리고 그곳과는 NAT Gateway라는 장치를 통해 안에서 밖으로 나가는 것만 허용하고, 밖에서 안으로 들어오는 것은 여전히 차단한다.

 

그리고 Security Group과 네트워크 ACL에 대해서도 고려해야 할텐데, 이 2가지는 모두 보편적으로 방화벽의 역할을 수행한다 볼 수 있지만, 지키는 위치와 성격이 완전히 다르다. Security Group은 개별 EC2 인스턴스 하나하나를 직접 지키는 것이며, Allow Only를 따른다. 그러니까 80번 포트 열어줘! 라고 규칙을 적는다면, 나머지는 자동으로 막는 것이다. 대상이 누구인지와는 다르게 말이다. 그리고 Stateful이 있는데, 들어올 때 검사 통과했다면, 나갈 때는 검사 안하고 그냥 보내준다는 것이다. 아웃바운드를 별도로 관리할 필요가 없어 관리에 편하지만, 제로 트러스트와는 다소 거리가 있는.. 그런 느낌인 것이다. 반면, 네트워크 ACL은 특정 서브넷 전체를 보호하는 것으로, Allow&Deny 모두가 설정된다. 특정 IP 대역을 아예 Deny하는 블랙리스트 설정이 가능하다. 그리고 Stateless를 따르는데, 아무리 들어올 때 검사했다고 하더라도, 아웃바운드 규칙이 없으면 못 나간다. 양방향을 다 신경써야 하기 때문에 설정이 까다롭지만, 보안은 그렇기에 더 철저한 것이다.

 

그리고 나서 고려해야 될 것이 비용 최적화다. 온디맨드, 예약 인스턴스, 예약 플랜, 스팟 인스턴스 등 최적의 전략을 선택해야 하는 것이다.

728x90

'클라우드 보안' 카테고리의 다른 글

S3 이름의 함정  (0) 2026.03.17
[기본 탐구] Security Group 파먹기  (0) 2026.03.11
AWS Technical Essentials #5  (1) 2025.11.27
AWS Technical Essentials #4  (0) 2025.11.26
AWS Technical Essentials #3  (1) 2025.11.25