다량의 액세스가 있어 리퀘스트 수가 스파이크 했을 경우, ELB의 스케일 해 대응한다.
그러나 너무 급격하고 스케일이 시간에 맞지 않으면 스케일 할 때까지 503을 반환합니다.
스파이크 액세스시에 503을 돌려주고 싶지 않다고 하는 경우의 대응 방법을 정리해 보았다.
실수가 있거나 다른 좋은 방법이 있으면 츳코미 희망 데스.

참조 사이트

[AWS 마이스터 시리즈] Amazon Elastic Load Balancing (ELB)

AWS - Cross-Zone Load Balancing을 활성화하지 않을 이유가없는 경우 - Qiita

ELB를 (가능한 한) 사용하지 마십시오.

갑자기 ELB에서 승부하지 않는 방법.
가능한 한 ELB 이외로 액세스를 받고 ELB에 액세스가 오지 않거나, 적게 하면 서비스로서의 스파이크가 있어도 ELB에의 영향은 적게 할 수 있다.
다음과 같은 S3와의 연계 방법 등으로 ELB에 대한 액세스를 줄인다.

AWS의 정적 콘텐츠 전송 패턴 카탈로그 (안티 패턴 포함) | Developers.IO

CDP:Direct Object Upload 패턴 - AWS-CloudDesignPattern

CDP:Web Storage 패턴 - AWS-CloudDesignPattern

ELB의 Pre-Warming 활용

AWS 지원에 부탁하여 ELB를 스케일 해 둡니다.
비즈니스 혹은 엔터프라이즈 서포트에 가입하고 있어, 사전에 스파이크를 예상할 수 있는 것이 조건.

ELB Pre-Warming을 수동으로 수행

지원을 요청하지 않고 스스로 ELB에 요청하여 예상되는 스파이크에 대해 ELB를 확장합니다.
스스로의 요구에 의한 스케일링중에 예상되지 않는 스파이크가 발생하면 위험할 것 같다.

ELB에서 사용하는 AZ 증가

ELB에서 사용하는 AZ를 늘리면 ELB의 인스턴스가 각 AZ에 배치되어 라운드 로빈되므로 액세스가 분산되어야 한다.
이용하는 AZ가 1개보다 2개, 2개보다 3개가 ELB 인스턴스가 늘어나 스파이크에 강해질 것.

DNS 라운드 로빈을 이용하여 ELB를 여러 연결

Route53 등에서 DNS 라운드 로빈 기능을 이용하여 복수 ELB를 연결하면 액세스는 분산될 것이다(각 ELB의 배후는 같은 EC2 구성).
운용면에서 관리하는 것이 늘어나는 단점이 있을 것 같다.