☰

AWS - API 백엔드에 URL 매핑(Apache ProxyPass 유사)

tag-icon • tag-icon amazon-ec2 amazon-web-services reverse-proxy amazon-s3 amazon-cloudfront
AWS - API 백엔드에 URL 매핑(Apache ProxyPass 유사)

저는 Apache를 프런트엔드로 사용하고 Nodejs를 백엔드로 사용하는 웹 아키텍처를 가지고 있습니다. 이 아키텍처를 AWS로 마이그레이션하고 싶습니다. Node.js는 Elastic Beanstalk가 될 것이며 Apache는 Amazon S3에 저장될 것입니다(정적 파일만 저장함).

이 지시문을 사용하여 /api URL 경로를 Apache의 백엔드에 매핑합니다.

<Location /api>
    ProxyPass http://localhost:8081/api
</Location>

AWS에서도 동일한 메커니즘을 사용하고 싶습니다. Amazon S3는 스토리지 서비스일 뿐이기 때문에 이렇게 할 수 없다는 것을 알게 되었습니다.

버킷 Amazon CloudFront또는 .Amazon CloudFront​Amazon S3​ Amazon Elastic Load Balancers그런 다음,를 사용하여 Amazon EC2Node.js 애플리케이션 백엔드를 호스팅합니다.Amazon Load Balancer

그러면 최종 아키텍처는 다음과 같습니다.

                        - Amazon Elastic Load Balancer -> Amazon EC2
                 /api  /
                      /
-->Amazon CloudFront-<
                      \
                 else  \
                        - Amazon S3

이런 유형의 아키텍처가 가능합니까? 그렇다면 이것이 AWS에서 이러한 아키텍처를 달성하는 가장 좋은 방법입니까?

귀하의 응답에 감사드립니다!

답변1

예... CloudFront를 사용하세요.

물론 공식적인 목적은 캐싱 CDN이지만 경로에 따라 요청을 적절한 원본 시스템으로 선택적으로 라우팅하는 기능이 내장되어 있습니다.

따라서 기본 경로를 S3으로 구성하면 요청이 버킷으로 전송됩니다. Elastic Beanstalk 배포 앞에 Elastic Load Balancer를 가리키는 두 번째 오리진을 구성합니다. /api/*요청을 이 두 번째 원본으로 라우팅하도록 경로 패턴을 설정합니다 .

필요하지 않거나 원하지 않는 경우 캐싱 동작을 비활성화할 수 있습니다.

CloudFront 배포를 "배포"라고 합니다.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web.html

이것이 "최상의" 접근 방식입니까? 이는 귀하의 전문성과 창의성에 달려 있습니다. 그러나 사용 가능한 AWS 구성 요소를 사용하고 싶다면 그렇습니다. 아마도 이것이 갈 길일 것입니다. 이는 본질적으로 유지 관리가 필요 없는 http 경로별 요청 라우팅을 제공하는 유일한 구성 요소입니다. (물론 Amazon API 게이트웨이도 경로를 통해 라우팅하지만 S3를 "와일드카드" 대상으로 사용하는 이 애플리케이션에는 적합하지 않습니다.)

관련 정보