web-dev-qa-db-ja.com

AWS-URLをAPIバックエンドにマップします（Apache ProxyPass Like）

フロントエンドとしてApacheを使用し、バックエンドとしてNodejsを使用するWebアーキテクチャがあります。このアーキテクチャをAWSに移行したいと思います。 Node.jsはElasticBeanstalkになり、ApacheはAmazon S3に保存されます（静的ファイルのみが保存されます）。

これらのディレクティブを使用して、/ apiURLパスをApacheのバックエンドにマップします。

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

AWSでも同じメカニズムを使用したいと思います。 Amazon S3はストレージサービスにすぎないため、これを実行できないことがわかりました。

Amazon CloudFrontは複数のAmazon CloudFrontオリジンを使用できることがわかりました。オリジンはAmazon S3バケットまたはAmazon Elastic Load Balancersです。次に、Amazon EC2を使用して、Node.jsアプリケーションのバックエンドをAmazon Load Balancerでホストします。

最終的なアーキテクチャは次のようになります

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

このタイプのアーキテクチャは可能ですか？はいの場合、AWSでこの種のアーキテクチャを実現するための最良の方法ですか？

皆様のご回答ありがとうございます！

amazon-ec2amazon-web-servicesreverse-proxyamazon-s3amazon-cloudfront
1
DeadEye

はい... CloudFrontを使用します。

もちろん、その公式の目的はCDNのキャッシュとしてですが、パスに基づいて適切なOriginシステムにリクエストを選択的にルーティングする機能が組み込まれています。

したがって、デフォルトのパスをS3に設定すると、リクエストがバケットに送信されます。 ElasticBeanstalkデプロイメントの前にあるElasticLoadBalancerを指す2番目のオリジンを構成します。 /api/*のパスパターンを設定して、この2番目のオリジンにリクエストをルーティングします。

不要または不要な場合は、キャッシュ動作を無効にすることができます。

CloudFrontデプロイメントは、「ディストリビューション」と呼ばれます。

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

これは「最良の」アプローチですか？それはあなたの専門知識と創造性に依存します...しかし、利用可能なAWSコンポーネントを使用したい場合は、そうです、おそらくこれが進むべき道です。これは、http上のパスによるリクエストの本質的にメンテナンスフリーのルーティングを提供する唯一のコンポーネントです。 （もちろん、Amazon APIゲートウェイもパスをルーティングしますが、S3を「ワイルドカード」宛先とするこのアプリケーションには適していません。）

3
Michael - sqlbot