タグ付けされた質問 「amazon-cloudfront」

Cloudfrontを介してS3バケットを配布しようとしていますが、何らかの理由で唯一の応答は次のようなAccessDenied XMLドキュメントです。 <Error> <Code>AccessDenied</Code> <Message>Access Denied</Message> <RequestId>89F25EB47DDA64D5</RequestId> <HostId>Z2xAduhEswbdBqTB/cgCggm/jVG24dPZjy1GScs9ak0w95rF4I0SnDnJrUKHHQC</HostId> </Error> 使用している設定は次のとおりです。 そして、これがバケットのポリシーです { "Version": "2008-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Sid": "1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity *********" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::x***-logos/*" } ] }

91 permissions  amazon-web-services  amazon-s3  amazon-cloudfront 

jQueryを使用してS3からCloudFront CDNを介していくつかのSVGファイルをロードするWebページ（https://smartystreets.com/contact）があります。 Chromeでは、コンソールだけでなくシークレットウィンドウも開きます。次に、ページをロードします。ページがロードされると、通常、コンソールに次のような6〜8個のメッセージが表示されます。 XMLHttpRequest cannot load https://d79i1fxsrar4t.cloudfront.net/assets/img/feature-icons/documentation.08e71af6.svg. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://smartystreets.com' is therefore not allowed access. ページの標準的な再読み込みを複数回行っても、同じエラーが引き続き発生します。そうすればCommand+Shift+R、ほとんどの、時にはすべての画像がXMLHttpRequestエラーなしでロードされます。 時々、画像が読み込まれた後でも更新され、1つ以上の画像が読み込まれず、XMLHttpRequestエラーが再び返されます。 S3とCloudfrontの設定を確認、変更、再確認しました。S3では、私のCORS設定は次のようになります。 <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedOrigin>http://*</AllowedOrigin> <AllowedOrigin>https://*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <MaxAgeSeconds>3000</MaxAgeSeconds> <AllowedHeader>Authorization</AllowedHeader> </CORSRule> </CORSConfiguration> （注：最初は<AllowedOrigin>*</AllowedOrigin>同じ問題しかありませんでした。） CloudFrontでは、ディストリビューションの動作はHTTPメソッドを許可するように設定されていますGET, HEAD, OPTIONS。キャッシュされたメソッドは同じです。Forward Headersは「Whitelist」に設定され、そのホワイトリストには「Access-Control-Request-Headers、Access-Control-Request-Method、Origin」が含まれます。 キャッシュレスブラウザーのリロード後に機能するという事実は、すべてがS3 / CloudFront側にあることを示しているようです。しかし、なぜ最初のページビューでコンテンツが配信されないのでしょうか？ macOS上のGoogle Chromeで作業しています。Firefoxは毎回ファイルを取得しても問題ありません。Operaはファイルを取得しません。Safariは、数回更新すると画像を取得します。 …

30 amazon-s3  amazon-cloudfront  google-chrome  cors  jquery 

Amazon AWSに移行しました。現在、うまく機能しているEC2インスタンスがあります。Nginxをフロントで、Apacheをバックエンドで実行しています。それもうまくいっています。すべてのサイトが適切に起動され、EC2から提供されるファイルのCache-Controlヘッダーが含まれます。 問題は、CloudFront CDNを介してアクセスされるAmazon S3に配置したすべての静的ファイルにあります。ファイルには問題なくアクセスできます（CORSには問題ありません）が、どうやら CloudFrontはCache-Controlヘッダーを持つファイルを提供しないようです。ブラウザのキャッシングを活用したい。 静的ファイルはS3 + CloudFrontによって直接処理されるため、EC2インスタンスはここでは役割を果たしません。リクエストはEC2のWebサーバーに送信されません。 私は完全に失われました。 質問：1）この場合、Cache-Controlを設定するにはどうすればよいですか？2）Cache-Controlを設定することはできますか？S3またはCloudFrontからですか？ 注：個々のオブジェクトにS3でヘッダーを設定できるGoogleのいくつかのページにアクセスしました。私の場合はいくつかのオブジェクトについて話しているので、それは特別にそれを行うための生産的な方法ではありません。 ありがとう！

27 amazon-web-services  cache  amazon-s3  cdn  amazon-cloudfront 

Amazon S3でホストされているウェブサイトがあります。これは、WordPressでホストされている古いWebサイトの新しいバージョンです。 Website Redirect Location古い場所を処理し、それらを新しいWebサイトページにリダイレクトするために、メタデータでいくつかのファイルを設定しました。 たとえばhttp://www.mysite.com/solution、リダイレクトしたいことがあったhttp://mysite.s3-website-us-east-1.amazonaws.com/product.htmlのでsolution、正しいメタデータを使用して、バケット内に名前の空のファイルを作成しました。 Website Redirect Location= /product.html S3リダイレクトメタデータは301 Moved Permanently、SEOに最適なものと同等です。これは、S3ドメインからURLに直接アクセスする場合に最適です。 また、Webサイトバケットに基づいてCloudFrontディストリビューションをセットアップしました。そして、ディストリビューションを介してアクセスしようとすると、リダイレクトが機能しません。つまり： http://xxxx123.cloudfront.net/solution リダイレクトせず、代わりに空のファイルをダウンロードします。 私の質問は、CloudFrontディストリビューションを通じてリダイレクトを維持する方法ですか？または、SEOを悪化させることなくリダイレ​​クトを処理する方法についてのアイデアはありますか？ ありがとう

18 amazon-s3  amazon-cloudfront 

CloudFrontでブルー/グリーン展開を行う方法を探しています。 あるCloudFrontディストリビューションから別のCloudFrontディストリビューションに移行するための優れたソリューションを持っている人はいますか？ 私のCloudFrontディストリビューションは、静的コンテンツ（javascriptなど）の1つのS3 オリジンと、AWS ELBを指すカスタムオリジンで構成されています。 CloudFrontに変更はありません 通常の状況では、CloudFrontディストリビューションに一切変更を加えません。S3の静的コンテンツファイルの名前を変更してS3オリジンの静的コンテンツをバージョン管理し、Elastic Load Balancer（ELB）の下でEC2インスタンスにローリング展開を行います。ただし、CloudFrontディストリビューション自体をテストして変更する必要がある場合や、新しい環境で新しいELBを指す必要があるほど大幅に変更する必要がある場合があります。 2つのCloudFrontディストリビューション 私が試みた最初のオプションは、2つの個別のCloudFront Web Distributionsを使用することでした。1つは現在の環境（A）に、もう1つは新しい環境（B）に使用します。Route53 加重ルーティングポリシーを使用して、www.domain.com Route53レコードに2つのレコードを追加しました。1つは重みが1のCloudFrontディストリビューションAを指し、もう1つは重みが0のCloudFrontディストリビューションBを指します。ディストリビューションAからディストリビューションBに移動するときに重みを変更する計画です。ただし、www.domain.com 代替ドメイン名（CNAME）を登録できるCloudFrontディストリビューションは一度に1つのみです。そうしないと、次のエラーが発生します。 com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a) 1つのCloudFrontディストリビューション 2番目のオプションは、1つのCloudFrontウェブディストリビューションを維持することです。AとBの両方の環境を指すS3およびカスタムオリジンがあり、ある環境から別の環境に移動する場合は、CloudFront キャッシュ動作を他のオリジンを指すように更新します。これらの更新には15〜60分かかり、更新の進行状況が見えないため、これは非常に面倒です。変更の性質によっては、キャッシュされたコンテンツを提供しないようにCloudFront無効化を追跡する必要がある場合があります新しいコンテンツとともに古い環境から。 助言ありがとう！

16 deployment  amazon-cloudfront 

AWS Cloudfrontを使用してFirefoxに静的アセットを提供する際に問題が発生しています。 Chromeは完璧に動作しますが、FirefoxはCORSエラーを返しています。 curlを実行すると、次の結果が得られます。 HTTP/1.1 200 OK Content-Type: application/x-font-opentype Content-Length: 39420 Connection: keep-alive Date: Mon, 11 Aug 2014 21:53:50 GMT Cache-Control: public, max-age=31557600 Expires: Sun, 09 Aug 2015 01:28:02 GMT Last-Modified: Fri, 08 Aug 2014 19:28:05 GMT ETag: "9df744bdf9372cf4cff87bb3e2d68fc8" Accept-Ranges: bytes Server: AmazonS3 Age: 2743 X-Cache: Hit from cloudfront Via: …

15 amazon-web-services  amazon-s3  firefox  amazon-cloudfront  cors 

CNAMEワイルドカードサポートがあるため、Amazon CloudFrontを介して動的なウェブサイトをホストできます。ただし、私のサイトの一部のページはHTTPSを使用しています。Amazonには、SSL証明書をCloudFrontディストリビューションに関連付ける方法に関するドキュメントがいくつかありますが、価格は月額600ドルであることが示されています。 私の質問は... HTTPリクエストがCloudFrontから提供されるようにCloudFrontを構成することは可能ですが、HTTPSリクエストはCloudFrontによって無視され、オリジンに直接渡されます（私の場合、追加費用なしでSSLを復号化できるElastic Load Balancer） ？

15 ssl  https  amazon-elb  amazon-cloudfront 

AWS Route53エイリアス値 AWS Route53に登録されたドメインを検討してください。このドメインへのHTTPリクエストは、AWS CloudFront CDNディストリビューションから提供される必要があります。これを実現するために、エイリアスAレコードが定義されます。 dig 結果 ただし、dig結果には実際のIPアドレスが表示されます。実際、これらのIPアドレスは一定ではなく、時間とともに変化します。 # dig @1.1.1.1 serverlessdaystlv.io ... ;; ANSWER SECTION: serverlessdaystlv.io. 60 IN A 13.32.67.21 serverlessdaystlv.io. 60 IN A 13.32.67.27 serverlessdaystlv.io. 60 IN A 13.32.67.97 serverlessdaystlv.io. 60 IN A 13.32.67.122 serverlessdaystlv.io. 60 IN A 13.32.67.141 serverlessdaystlv.io. 60 IN A 13.32.67.159 serverlessdaystlv.io. 60 IN …

13 domain-name-system  amazon-web-services  amazon-route53  alias  amazon-cloudfront 

バックグラウンド S3で静的サイトをホストしており、CloudFrontが上部にあります。私が抱えている問題は、HTMLファイルにあります。 CloudFrontのFAQによると： Amazon CloudFrontはこれらのキャッシュ制御ヘッダーを使用して、そのファイルの更新バージョンのオリジンをチェックする必要がある頻度を決定します これまでにやったこと これを念頭に置いて、S3バケットにHTMLファイルを設定して、次のヘッダーを追加しました。 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Expires: Fri, 01 Jan 1990 00:00:00 GMT myへの最初の呼び出しでsamplefile.htm、次の応答ヘッダーが表示されます（Content-Typeポイントを維持するために、明らかなヘッダー（例：）を除外しました： Cache-Control:no-cache, no-store, max-age=0, must-revalidate Date:Sat, 10 Dec 2011 14:16:51 GMT ETag:"a5890ace30a3e84d9118196c161aeec2" Expires:Fri, 01 Jan 1990 00:00:00 GMT Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT Server:AmazonS3 X-Cache:Miss from cloudfront ご覧のとおり、Cache-Controlヘッダーがそこにあります。問題は、このファイルを更新して更新すると、キャッシュされたコンテンツ（最新のファイルではなく）を取得し、CloudFrontがキャッシュされたバージョンを提供していることが、応答ヘッダーを見ることでわかります。 X-Cache:Hit from …

13 amazon-web-services  amazon-s3  amazon-cloudfront 

S3オリジンからAmazon CloudFrontディストリビューションにHSTSヘッダーを設定することは可能ですか？

11 ssl  amazon-cloudfront  hsts 

比較的簡単なことをしようとしています。いくつかのドメインとサブドメインをセットアップして、サイトのコアドメインにリダイレクトしたいのですが、リダイレクトをCloudfrontに配置したいと思います。ルートパスのリダイレクト以外はすべて機能します。これにより、S3バケットを部分的に説明するXMLファイルが取得されます。 バックグラウンド S3 S3では、次のような全リダイレクトバケットを設定できます。 これをテストすると、Webエンドポイント（brass9-com.s3-website-us-west-1.amazonaws.com）は、本来あるべきことを実行します-brass9.comにリダイレクトします。良い。 クラウドフロント CloudfrontではS3バケットを指すことができますが、そうするように提案されている方法は間違っています。bras9-com.s3.amazonaws.comのように、バケットをその名前で指すのではなく、上記のWebエンドポイントを使用する必要があります。それ以外は、すべてをデフォルトのままにして、良好なリダイレクト動作を得ることができます。したがって、www.brass9.com / portfolioのようなパスは、適切な場所に正しくリダイレ​​クトされます。また良い。 問題-ルートドメインのリダイレクト その後、機能しないのは、単純なwww.brass9.comからリダイレクトすることです。リダイレクトを取得する代わりに、次の奇妙な結果を取得します。 <?xml version="1.0" encoding="UTF-8"?> <ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>brass9-com</Name><Prefix></Prefix> <Marker></Marker><MaxKeys>1000</MaxKeys><IsTruncated>false</IsTruncated> </ListBucketResult> OK... 。したがって、これは完全に予期されることではありません。デフォルトルートオブジェクトがないためです。しかし、この動作を防ぐために、どのデフォルトルートオブジェクトを指定できるでしょうか。指し示す必要があるS3リダイレクトオブジェクトがある場合、その名前は何ですか？または、他に適切な構成がありますか、これは、Amazonが修正する必要があるCloudfrontとS3の相互作用のバグにすぎませんか？ 機能しない既知のソリューション：デフォルトのルートオブジェクト index.htmlのデフォルトルートオブジェクトを指定することは可能ですが、それは何の助けにもなりません-問題を変更するだけです。代わりに、CloudfrontのURLは、404であるメインサイトの/index.htmlにリダイレクトします（index.htmlファイルは使用せず、サーバー側のフレームワーク駆動型サイトです）。index.htmlをサーバーに配置することもできますが、そもそもCloudfrontを使用することによるわずかな速度の向上に勝るものはありません。 同様の質問 1つの質問が似たような質問をしますが、なんらかの理由で、XML応答ではなく、何らかの理由で空白の0バイトの応答が返されます。その問題や解決策に関する質問は含まれていません。 関連記事 ある記事では、ベアドメインとwwwドメインの両方でサイト全体を提供することを提案しています。これは、ユーザーのブックマーク、検索ランキングなどに影響します。これを行うべきではありません。 リダイレクト方式ではなく、S3とCloudfrontで静的Webサイトをホストすることについて議論しているものもあり、関係はありません。 それで、これを適切に行うにはどうすればよいですか？ Cloudfront構成のスクリーンショット-デフォルトルートオブジェクトがなく、S3の起点を指しています。InProgressを無視-テストのためにデフォルトルートオブジェクトのオンとオフを切り替えました。 そしてそのディストリビューションのOrigin設定：

10 redirect  amazon-s3  amazon-cloudfront 

私は自分のウェブサイトの静的アセットをS3に配置し、それらを配布するようにCloudFrontを設定しています。これらは基本的に、ユーザーが既存のパスへの私のサイトでのGETリクエストに必要なコンテンツ、つまりエラーのキャッチオールを保持します。 処理する必要があるPOSTリクエストもいくつかあります。フォームの送信、メールの送信、通知、データベースとのやり取り。 CloudFrontがGETリクエストを処理し、API Gatewayが本文またはPOSTリクエストを含むリクエストを処理するように、同じドメインのCloudFrontとLambda（またはAPI Gateway）を並べてセットアップするにはどうすればよいですか。または、どうにかして個別のURLで実行できますか？

9 amazon-web-services  amazon-cloudfront  amazon-api-gateway 

私はCDNを初めて使用し、CloudFrontを試しています。すべてを設定しましたが、すべて正常に動作しているようです。ページに静的イメージを作成し、CloudFrontディストリビューションを介してそれにアクセスできます。カスタムオリジンを使用しています（つまり、s3バケットではありません）。 とはいえ、パフォーマンスの観点からはもっと悪いのではないかと心配しています。CDNの有無にかかわらず、同じ20枚程度の画像をロードするテストページがあります。Firebugのネットパネルを見ると、このページを初めてロードしたときに、オリジンサーバーから直接ロードされた画像の方がはるかに速く表示されます。次のページの読み込みで、CDNの利点が明らかになります。3〜5回の更新後、CDNはオリジンサーバーよりも優れています。 それで、私たちのサイトで常にヒットしている人気のあるページで、これはメリットになることがわかります。私はシアトル（Amazonのすぐ近く）にいて、サーバーはCAにあるので、メリットが期待できます。 重要なのは、ページを数分間離れてからリロードすると、問題が元の状態に戻り、CloudFrontがオリジンサーバーよりも悪いことです。これは予想されますか？物事はCDNの「キャッシュ」からすぐに消えてしまいますか？ セットアップで何かがパフォーマンスを低下させている可能性はありますか？それとも、CDNは平均して数秒ごとに現在アクセスされているコンテンツに対してのみ正味のプラスになるという現実ですか？ （私はSOのターンアラウンドタイムに永遠に甘やかされてきたので、AWSフォーラムからクロスポストされました） 更新： CloudFrontのパフォーマンスについて質問がある場合に検討する価値のある、以下の2つの良い答えがあります。最近、私の特定の問題について1つの説明が記載されていないことがわかりました。見落としとして、TTLを5分のままにしていた。私もカスタムオリジンを使用しているため、それを実際のAmazon CloudFrontドメインに解決するために、権威ネームサーバーへの追加の往復があります。TTL設定が12時間に戻ったので、長い負荷が発生することはほとんどありません。

9 cdn  amazon-cloudfront 

私はec2インスタンスにApache設定があります： RewriteEngine On ProxyPreserveHost On ProxyRequests On ProxyPass /blog http://212.128.122.142/blog これは、DNSレコードをELBにポイントするまで機能しますが、CDNをポイントするようにDNSを変更した場合は機能しません。502を取得するか、ループをリダイレクトします。 また、私は502の悪いゲートウェイを見たので書き換えルールを試しmyendpoint.elb.amazonaws.com/blogました.CDNはApacheによってアクセスしようとし 、それがApacheによって処理されないため、apacheがserverAliasとしてorginエンドポイントを受け入れ、condを書き換えてURLを元のホスト名に書き戻すように変更しましたproxypreserveを使用してIPに渡します。 RewriteCond %{HTTP_HOST} !^(www\.)?mydomain\.com RewriteCond %{HTTP_HOST} ^myendpoint.elb.amazonaws.com$ RewriteRule ^/blog http://mydomain/blog[R,L] （同じドメインでホストされている別のサーバーから/ blogにアクセスする必要があります。前述のように、ELBがDNSレコードを指すがCDNで停止するまですべて動作しますか？） 私が達成しようとしていること：別のサーバーでホスト/ブログをホストし、これはすべてELBの上部にあるクラウドフロントで動作します

-1 proxy  amazon-cloudfront