CloudFront Functions を使用して Amazon S3 の Amazon CloudFront オリジンでデフォルトディレクトリインデックスを実装 | Amazon Web Services
Amazon Web Services ブログ CloudFront Functions を使用して Amazon S3 の Amazon CloudFront オリジンでデフォルトディレクトリインデックスを実装 Amazon CloudFront Functions により、以前は AWS Lambda@Edge でしかできなかったことを、より高性能な方法で行うことができるようになりました。たとえば、Amazon CloudFront のオリジンアクセスアイデンティティ (OAI) を使用してオリジンを保護する場合に必要不可欠である URI パスを操作できます。 2017年に私が書いた投稿 (Implementing Default Directory Indexes in Amazon S3-backed Amazon CloudFront Origins Using Lambda@E
SPA+CloudFrontマルチオリジン構成で「/」以外へのアクセスをルーティングする - Qiita
やりたいこと AWS CloudFront ではリクエストパスのパターンに応じて、１つのドメインから複数のオリジンにアクセスを振り分けることができます。 以下のように、S3 でフロントエンドの SPA を配信し、バックエンドを API Gateway で提供するようなマルチオリジン構成を考えます。 SPA を CloudFront + S3 で配信する時の問題点 SPA を CloudFront + S3 で配信する時に問題になるのが、ルートパス ("/") 以外の URL に直接アクセスしたときに 403 エラーが発生するという現象です。 例えば https://example.com/page1 という URL にアクセスしたとき、実際に S3 上に /page1 というオブジェクトが存在しないため、403 エラーが発生します。 よくある解消法（カスタムエラーレスポンス） よく紹介され
CloudFront エッジキャッシュにオブジェクトを保持する時間の指定（有効期限切れ） - Amazon CloudFront
CloudFront が別のリクエストをオリジンに転送するまでにファイルを CloudFront キャッシュに保持する期間を制御できます。この期間を短くすると、動的なコンテンツを供給できます。この期間を長くすると、ユーザー側のパフォーマンスは向上します。ファイルがエッジキャッシュから直接返される可能性が高くなるためです。期間を長くすると、オリジンの負荷も軽減されます。 一般的に CloudFront は、指定したキャッシュ保持期間が経過するまで、つまりファイルの有効期限が切れるまでエッジロケーションからファイルを提供します。ファイルの有効期限が切れると、エッジロケーションがファイルのリクエストを次に受け取ったときに、CloudFront は、リクエストをオリジンに転送し、キャッシュにファイルの最新バージョンが含まれていることを確認します。オリジンからのレスポンスは、ファイルが変更されたかど
CloudFront + S3 でのディレクトリアクセス - Qiita
前置き S3にアップロードしたコンテンツをウェブ公開するときに、CloudFrontを噛ませるのはよくある構成です。S3をStatic Website Hostingで直接公開する場合とくらべて、 CDNの機能が使える WAFが使える（CloudFrontにWAFをアタッチした場合） 独自ドメインのhttps構成が使える（CloudFrontにssl証明書を付与） アクセスはCloudFront経由に集約されるため、CloudFrontのアクセスログでアクセス状況を分析できる といったメリットがあります。しかし、Static Website Hosting で使える index document が使えなくなるという問題が。 S3のindex documentとは たとえば http://hoge.jp/fuga/ というふうにディレクトリに対するリクエストがきたときにどのファイルをレスポ
CloudFrontのオリジンサーバによる機能の違い | DevelopersIO
こんにちは。望月です。 今日はCloudFrontのOriginについてのあまり知られていない(?)差について書いてみます。 CloudFrontの復習 CloudFrontはAWSが提供するCDN(Contents Delivery Network)サービスです。全世界に散らばったエッジサーバと呼ばれるキャッシュサーバがコンテンツ提供元サーバ(オリジンサーバ)の持つコンテンツをキャッシュすることで、オリジンサーバの負荷を軽減しつつ高速なレスポンスを返すことを目的としています。 CloudFrontを経由して配信したいFQDN単位で、CloudFrontのDistributionと呼ばれるものを作成し、それに対してコンテンツの取得元であるオリジンサーバを一つ指定します。CloudFrontの特徴として、オリジンサーバとしてS3バケットを指定できることが挙げられます。以降、S3をオリジンサー
Amazon CloudFrontでAPI Gatewayの痒いところに手を届ける | DevelopersIO
2016/02/05 9:30 ユースケース2 API Gatewayの対応するTLSのバージョンを修正しました。@Keisuke69さんご指摘ありがとうございます！ ども、大瀧です。 Amazon API Gateway、皆さん使ってますか？Lambdaのフロントエンドとして、既存APIのRESTful化&統合として様々なケースで利用できると思います。今回は、そんなAPI GatewayをCloudFrontと組み合わる目的とその注意点をご紹介します。 概要 ご存じの方もいると思いますが、そもそもAPI Gatewayは内部でCloudFrontの仕組みを利用しており、スケーラビリティやアベイラビリティの面でCloudFrontの特徴を享受しています。しかしながら、CloudFrontのフル機能をAPI Gatewayで利用できるわけではないため、場合によっては以下の図のようにAPI G
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【AWS】CloudFront + S3 + Route53 + NuxtJS で公開する手順 | 🧑🏼💻技術ブログ