AWS활용 계획

⭐ 아엔 Aen (개발자지망생)·2026년 1월 19일

DNS ElastiCache IAM S3 aws cloudfront ec2 lambda rds route53 데브코스

데브코스

목록 보기

125/131

AWS 주요 서비스, 한 번에 이해하기

AWS에 서비스가 200개가 넘는다. 근데 실제로 대부분의 서비스는 10개 안팎의 핵심 서비스로 돌아간다. 뭐가 뭔지만 알아도 "이 상황엔 이걸 쓰면 되겠다"가 바로 보임. 핵심부터 한 줄로 정리하면 이렇다.

AWS = 서버·저장소·DB·네트워크 등 인프라를 필요한 만큼 골라 쓰는 클라우드 플랫폼

쉽게 비유하면

AWS는 레고 세트라고 생각하면 됨! EC2(서버), S3(저장소), RDS(DB) 같은 블록들을 골라서 조립하면 서비스가 완성된다. 블록마다 역할이 다르고, 어떤 블록을 조합하느냐에 따라 만들어지는 결과물이 달라진다.

혼자 서버를 사는 건 레고 대신 나무 깎아서 직접 만드는 거다. AWS 쓰면 블록이 다 준비돼 있으니까, 조립에만 집중하면 된다는 게 핵심 같음!

자세히 — 서비스별 역할과 언제 쓰나

⚙️ EC2 (Elastic Compute Cloud) — 가상 서버

한 줄 요약: 클라우드에서 빌리는 컴퓨터

윈도우/리눅스 서버를 원하는 사양으로 만들고, OS부터 직접 설치·운영
백엔드 서버, API 서버, 배치 작업 등 거의 모든 걸 돌릴 수 있음
사양(CPU·RAM)을 언제든 바꿀 수 있고, 안 쓸 땐 꺼서 비용 절약 가능

언제 써? 커스터마이징이 필요한 서버가 필요할 때. "뭔가 돌릴 서버가 필요해"의 기본 선택지 같음!

🗂️ S3 (Simple Storage Service) — 파일 저장소

한 줄 요약: 인터넷에서 접근 가능한 무제한 파일 창고

이미지, 동영상, 문서, 로그 파일 등 뭐든 저장 가능
용량 제한 없음. 쓴 만큼만 요금 냄
URL로 외부에서 직접 접근 가능하게 설정할 수 있음

언제 써? 유저가 업로드하는 이미지, 정적 파일(CSS·JS·HTML), 백업 파일 등 어디선가 파일을 저장해야 할 때 거의 무조건 S3가 1순위 같음!

🗄️ RDS (Relational Database Service) — 관계형 DB

한 줄 요약: PostgreSQL, MySQL 같은 DB를 관리형으로 띄워주는 서비스

직접 DB 설치·운영 안 해도 됨. AWS가 백업, 패치, 장애 복구 알아서 해줌
PostgreSQL, MySQL, Aurora 등 선택 가능

언제 써? 회원 정보, 게시글, 주문 내역처럼 관계가 명확한 데이터를 다룰 때. DB를 직접 EC2에 깔 수도 있지만, 관리 편의성 때문에 RDS 쓰는 게 훨씬 나음 같음!

⚡ ElastiCache — 인메모리 캐시

한 줄 요약: Redis나 Memcached를 관리형으로 띄워주는 서비스

자주 쓰는 데이터를 메모리에 올려두고 초고속으로 꺼냄 (메모리 편 참고)
RDS가 느릴 때 앞에 캐시 레이어로 붙이는 용도

언제 써? 세션 저장, 실시간 랭킹, 자주 조회되는 데이터 캐싱. 다만 메모리 기반이라 비용이 꽤 나오니까, 진짜 필요한 곳에만 쓰는 게 좋음!

🌐 CloudFront — CDN (콘텐츠 전송 네트워크)

한 줄 요약: 전 세계 곳곳에 파일을 복사해두고 가까운 서버에서 빠르게 전달

서울 서버에 있는 파일을 미국 유저가 받으면 느림. CloudFront가 중간에서 미국 서버에서 전달해줌
주로 S3에 올린 이미지나 정적 파일 앞에 붙임

언제 써? 글로벌 서비스거나, 이미지·영상처럼 용량 큰 파일을 빠르게 전달해야 할 때!

🔀 Route 53 — DNS

한 줄 요약: 도메인 이름을 실제 서버 IP로 연결해주는 서비스

myapp.com 치면 EC2 서버로 연결되게 해주는 게 Route 53
헬스 체크 기능이 있어서 서버가 다운되면 다른 서버로 자동 전환 가능

언제 써? 도메인 사서 서버에 연결할 때. AWS 서비스끼리 연동이 자연스러워서 Route 53 많이 씀 같음!

🔒 IAM (Identity and Access Management) — 권한 관리

한 줄 요약: "누가 뭘 할 수 있는지" 관리하는 서비스

AWS 계정 안에서 팀원별로 권한을 다르게 줄 수 있음
"이 서버는 S3에만 접근 가능"처럼 서비스끼리 권한도 설정 가능

언제 써? 항상. AWS 쓰면 IAM은 기본 중의 기본이다. 권한 설정 잘못하면 보안 사고로 이어지니까 제일 먼저 제대로 배워야 할 것 같음!

🚀 Lambda — 서버리스 함수

한 줄 요약: 서버 없이 코드만 올려서 필요할 때만 실행

EC2처럼 서버를 계속 켜두지 않아도 됨. 요청 올 때만 실행되고, 안 쓰면 비용 없음
이미지 업로드 시 자동 리사이징, 특정 이벤트에 반응하는 자동화 작업에 많이 씀

언제 써? 간단한 자동화 작업, 이벤트 기반 처리, 트래픽이 들쭉날쭉할 때. 서버 관리 부담 없애고 싶을 때 대안 같음!

실사용 — 서비스를 만든다면 이렇게 조합함

전형적인 웹 서비스 하나를 올린다면 이런 그림이 된다.

유저 접속
  → Route 53 (도메인 연결)
  → CloudFront (정적 파일 빠르게 전달)
  → EC2 (백엔드 API 서버)
  → RDS (회원·게시글 등 주요 데이터)
  → ElastiCache (자주 조회되는 데이터 캐싱)
  → S3 (이미지·파일 저장)
  → IAM (권한 관리, 전체에 걸쳐)

서비스 규모별로 달라지기도 한다.

사이드 프로젝트 초기 → EC2 + RDS + S3만으로도 충분. ElastiCache는 트래픽 생기면 그때 붙여도 됨
트래픽 늘어날 때 → CloudFront 붙이고, EC2를 여러 대로 늘리고(로드밸런서 추가), RDS는 읽기 전용 복제본 추가
비용 줄이고 싶을 때 → 간단한 기능은 EC2 대신 Lambda로 대체

한 방 정리

서비스	역할	언제
EC2	가상 서버	뭔가 돌릴 서버 필요할 때
S3	파일 저장소	이미지·파일·정적 자산 저장
RDS	관계형 DB	회원·게시글 등 구조화된 데이터
ElastiCache	인메모리 캐시	빠른 조회가 필요한 데이터
CloudFront	CDN	정적 파일 빠르게 전달
Route 53	DNS	도메인 → 서버 연결
IAM	권한 관리	항상. 제일 먼저 세팅
Lambda	서버리스 함수	이벤트 기반 자동화