s3 웹서버 방식 (서버리스, 요청 건수 당 요금)

• 사용할 때만 요금이 나감
  

ec2 웹서버 방식 (시간 당 요금)

• nginx 기능들을 사용함
  

서비스 특정 시간에만 사용자가 폭발적으로 늘어나는 서비스

배달

• 배달이 전혀 없는 시간대에도 ec2는 폭발적일때와 마찬가지로 요금이 똑같이 나감.
  • s3는 cpu와 메모리를 고려할 필요 없음. aws에서 무한히 제공해줌. 배달이 없을 때에는 요청이 없기 때문에 요금이 안나감

24시간 내내 일정 사용자가 유지되는 서비스

게임

• ec2가 더 유리함.
  

보통 뭐가 더 좋다라기 보다는, 배달도 새벽에도 이용가능하기 때문에 ec2도 만들어 놓고 배달이 많을 때에는 ec2를 사용하면서 부하분산 시키고, 배달이 별로 없는 시간대에는 s3로 분산시킴.

람다

• cpu와 메모리 같은건 걱정하지마. 우리가 알아서 처리할께.
• 특정 언어로 함수를 만든 후, API Gateway와 같이 연결한다면 통신 가능!
• 쉽게 말하면 API Gateway의 REST API는 장고의 urls.py와 같은 것.
• 람다는 aws에서 직접 함수를 실행시켜주는 인터프리터

• AWS의 람다를 파이썬으로 작성하고, API Gateway와 연결하는 것은 Django에서 views.py와 urls.py를 작성하는 것과 유사한 개념.

• 람다 함수는 클라이언트로부터 호출될 때 실행되는 코드이며, 이 경우에는 API Gateway를 통해 호출.

• API Gateway는 클라이언트의 요청을 받아서 해당 요청을 처리할 람다 함수를 호출하고, 그 결과를 클라이언트에게 반환.

• 따라서, 이러한 구성에서 람다 함수는 Django의 views.py와 비슷한 역할을 수행하고, API Gateway는 Django의 urls.py와 비슷한 역할을 수행.

• views.py는 URL에 대한 처리 로직을 구현하고, urls.py는 요청 URL을 뷰 함수와 매핑.

• 마찬가지로, 람다 함수는 클라이언트의 요청에 대한 처리 로직을 구현하고, API Gateway는 클라이언트의 요청 URL을 람다 함수와 매핑.

• 하지만, AWS Lambda와 API Gateway는 Django의 views.py와 urls.py와는 다른 방식으로 동작하며, 다른 구성 요소도 사용.

• 따라서 이러한 구성을 완전히 대체할 수는 없지만, 비슷한 역할을 수행할 수 있다.