AWS Fargate는 Amazon ECS(Elastic Container Service)나 EKS(Kubernetes)에서 컨테이너를 실행할 때, 그 기반이 되는 EC2 인스턴스를 사용자가 관리하지 않도록 해주는 서버리스 컴퓨팅 엔진이다.

1. EC2 vs Fargate 비교

비교 항목	EC2 기반 컨테이너 (ECS/EKS)	AWS Fargate (서버리스)
관리 주체	사용자가 OS, 패치, 스토리지 관리	AWS가 하드웨어 및 OS 관리
확장성(Scaling)	EC2 개수와 컨테이너 개수 둘 다 조절 필요	컨테이너(Task) 개수만 조절하면 끝
비용 모델	서버를 켜놓은 시간당 과금 (사용률 낮아도 지불)	컨테이너가 점유한 CPU/메모리 양만큼 초 단위 과금
보안	사용자가 OS 보안 설정 책임	AWS가 인프라 수준의 격리 보장

---

2. Fargate의 작동 원리

1. 컨테이너 이미지 준비: Dockerfile을 작성하고 빌드하여 ECR(Amazon Container Registry)에 업로드한다.
2. 작업 정의(Task Definition): "이 컨테이너는 CPU 1개, 메모리 1GB를 사용하고 8080포트를 열 것이다."라고 명세서를 작성한다.
3. 실행: 실행 환경을 FARGATE로 선택하면 AWS가 어딘가에 있는 리소스에서 내 컨테이너를 즉시 실행한다. 우리는 그 컨테이너가 돌아가는 실제 서버의 IP나 사양을 고민할 필요가 엇다.

---

3. 백엔드 개발자가 얻는 이점

3.1. 인프라 관리 부담 감소

• OS 업데이터, 보안 패치, Docker 데몬 관리 등 귀찮은 업무에서 해방된다. 개발자는 오직 코드와 컨테이너 이미지에만 집중하면 된다.

3.2. 쉬운 오토스케일링

• 트래픽이 몰릴 때 서버(EC2) 대수를 늘리는 작업은 복잡하고 시간이 걸린다.
• Fargate는 '작업(Task)'단위로 빠르게 늘어난다. 설정한 CPU 점유율이 높으면 자동으로 컨테이너를 더 띄우도록 설정하기 매우 쉽다.

3.3. 강력한 격리 보안

• 각 Fargate 작업은 자체 격리된 커널 환경에서 실행된다.
• 다른 사용자의 컨테이너나 심지어 내 계정의 다른 컨테이너와도 커널 수준에서 격리되므로 보안성이 매우 높다.

---

4. 실무 고려 사항 (주의점)

4.1. 고정 IP 사용의 어려움

• Fargate 컨테이너는 떴다 사라질 대마다 사설 IP가 바뀐다. 따라서 반드시 ALB 뒤에 배치하여 고정된 접속 지점을 만들어야 한다.

4.2. 비용 최적화

• 24시간 내내 100% 가동되는 대규모 서버이ㅡ 경우 잘 관리된 EC2보다 Fargate 비용이 조금 더 비쌀 수 있다.
• 하지만 관리 인건비와 유연성을 고려하면 중소규모나 트래픽 변동이 심한 서비스에는 훨씬 경재적이다.
• Fargate Spot: EC2 Spot 처럼 남는 자원을 활용해 비용을 70% 이상 절감할 수 있는 옵션도 있다.

4.3. 상태 비저장(Stateless) 아키텍처

• 컨테이너가 재시작되면 내부 데이터는 삭제된다. 따라서 로그는 CloudWatch Logs로 보내고 파일 업로드는 S3, 세션 관리는 Redis같은 외부 서비스를 사용해야 한다.

---

5. 백엔드 배포 흐름 예시

1. Code: Springboot 앱 구현
2. Dockerize: docker build -t my-api
3. Push: docker push [AWS_ACCOUNT_ID].dkr.ecr.[REGION].amazonaws.com/my-api
4. Deploy: ECS 서비스 업데이트 (Fargate 타입 선택) -> 새로운 버전의 컨테이너가 뜨고 ALB에 자동으로 연결됨