Notice
Recent Posts
Link
Tags
- 문자열
- springboot
- Docker
- 스프링
- select
- 자바
- spring
- DI
- spring boot
- join
- spring mvc
- java
- sql
- PYTHON
- 스프링부트
- AWS
- 프로그래머스
- Django
- mysql
- nginx
- string
- spring security 6
- jpa
- @transactional
- ORM
- hibernate
- 1차원 배열
- 데이터베이스
- SSL
- static
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Archives
개발하는 자몽
잊기 전에 남겨두는 Amazon API Gateway 사용 이유 본문
AWS Lambda 사용법을 조사하다가 Amazon API Gateway가 같이 언급되는 글이 많길래 왜 그런가 찾아봤다. 결론은 Lambda가 특별히 API Gateway가 필요해서 같이 붙어 다니는 건 아니었다.
Lambda는 특성상 무거운 프로그램의 서버보다는, 한 가지 목적에 집중하는 가벼운 프로그램의 서버로 적합하다. 각 기능(인증, 스케쥴링, 모니터링 등)을 여러 개의 Lambda로 분리해서 API Gateway로 연결하는 편이 좋다.
다음은 API Gateway를 사용했을 때 얻을 수 있는 이점이다.
Reusability
Lambda 유무와 관계없이 API Gateway를 사용하면 새 프로젝트 시작할 때마다 인증 기능을 구현할 필요도 없다. 인증 기능이 배포된 서버를 API Gateway에 연결해서 사용하면 되기 때문이다.
예를 들어, 클라이언트가 게이트웨이에서 한 번 인증을 하면, 인증된 요청들은 적절한 백엔드로 라우팅 된다. 따라서 각 백엔드는 인증을 처리할 필요가 없다.
Decoupling Clients from the Backend → Abstracting Backend Infrastructure
또한 API Gateway은 클라이언트 요청에 대해 단일 도메인을 제공하므로, 클라이언트는 각 기능이 배포된 서버의 endnpoint를 알 필요가 없다. 오로지 API Gateway의 도메인만 알면 된다.
'Architecture & Tool > AWS' 카테고리의 다른 글
[AWS & Docker] Docker 컨테이너 로그를 AWS CloudWatch로 보내기 (1) | 2025.01.04 |
---|---|
[TIL] ACM(ELB)와 NGINX (0) | 2024.04.07 |
[AWS] ACM을 이용한 HTTPS 적용 (0) | 2024.04.05 |
[AWS] ELB 생성 (0) | 2024.04.05 |
[AWS] EC2 인스턴스 용량 확장 (0) | 2024.03.29 |
Comments