良くあるこのパターンですが、自分なりに辿り着いたプラクティスを紹介しておきます。 先に結論 SPA: Cloudfront Functionsを使って拡張子付きのパスを/index.htmlに変更する API: Behaviorで/apiをAPI Gatewayに向ける 背景 今まで、Cloudfront + S3 でVueやAngular等のSPAアプリケーションを公開する場合、 存在しないパスにリクエストすることで、S3が403もしくは404を返す。 そのため、Cloudfront側でカスタムエラーページを作成し、/index.htmlにリダイレクトするような設定をしていた。 よくある悩み１（SPAのパス問題） 本来キャッチすべき404があった場合でも気にせずリダイレクトされてしまう。 例えばCSSやJSのアップロードミスがあった場合は気づきにくい。 よくある悩み２（Cloudfron

概要 API Gatewayの前にCloudFront Distribution を使用することで、APIGatewayのパフォーマンスを向上させることができます。API Gatewayのエッジ最適化 API エンドポイントを使用すると、最寄りのCloudFront Point of PresenceでAPI呼び出しを終了できます。 API Gatewayの前でCloudFront Distributionを使用する理由 : レイテンシーを削減 セキュリティを強化する キャッシング動作を制御する APIのTLS設定を制御する。 この記事では、Rest APIの前でCloudFront Distributionを作成してみました。 やってみた REST APIの作成 API GatewayコンソールのREST APIペインで、Buildを選択しておきます。 New API を選択して、API

AWS WAF は CloudFront と統合されているので、AWS WAF を単体で使うことはできません。よくある EC2 + ELB といった構成で AWS WAF を導入するには、ELB の前段にキャッシュしない CloudFront を挟むことで実現できます（そのうち ELB にも AWS WAF が導入できるようになると思いますが）。 このキャッシュしない（させない） CloudFront を検証する機会があったので、その手順とメリット・デメリットについて考えてみました。 キャッシュしない CloudFront の設定 Cache Behavior を次のように設定すれば、CloudFront にまったくキャッシュされず、すべてのリクエストがオリジンサーバに届きます。 Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PA

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

概要 API Gatewayを使うとき手が届かないむずかゆいところがたくさんあります（HTTPSのみしか受け付けないとか、前段にWAFおけないとか）。 そのときに使われるのがCloudFrontになりますが（もちろん、API Gateway内部にCloudFrontが暗黙的に使われており、多段CloudFrontになるため遅延が大きいというのは承知）、API　Gatewayの前段用にCloudFront使うのもなんなのでS3オリジンの配信もやっちゃいたい、という内容です。 CloudFront + API Gateway + S3 S3はOAI(Object Access Identity)でアクセス制限 API Gatewayはカスタムオリジンヘッダによるアクセス制限はしない めんどいので API Gatewayはキャッシュしない Route53で取得したドメインを利用 ACMで取得した

はじめに API Gateway に対して、直接アクセスした場合と CloudFront 経由アクセスした場合に、レスポンス時間がどの様に変化するかを調査した記事です。 API Gateway を CloudFront 経由でアクセスするパターン 私の場合は、静的リソースの配信 (S3) と、動的リソースの配信 (API Gateway) を同一ドメインで配信できるようにしたい、というのが目的です。 Same-origin policy に起因する課題をそもそも起こさせないにはこの構成を試したい、という感じです。 CORSなどの色々設定しているのですが、そもそも同一ドメインでやれるほうが楽なので。 調査しようと思ったきっかけ いくつかの記事を見かけたのですが、早くなる、遅くなるの両方の記事を見かけたので、自分で実際に環境を作って調べよう！と思ったのがきっかけです。 例えば、以下のような記事

WebSocket API Gateway の前段にCloudFrontディストリビューションを置く構成を作成する機会がありましたのでレポートします。 この構成のメリット WebSocketと他のリソースを同じFQDNから配信できる CloudFrontディストリビューションは、Behaviors(Cache Behaviors)という機能を活用することで複数のオリジンを同一FQDNから配信することができます。 例えば以下のようなことができます。 /websocket パス以下をWebSocket API Gatewayオリジンにする 他のパスは他のオリジンを使う(S3、ALBなど) ※とはいえ、FQDN分けてしまえるならその方がシンプルな構成になり良いかと思います。 ネットワークの最適化 2020/08/14現在、CloudFrontの接続ポイントは42か国84都市にある216箇所が提供

最近ブログ名のラズパイがあまり出てきていません。どうものなめです。 タイトルにある「キャッシュなしのCloudFront」ってどういうことか分かりますか？ キャッシュサーバーのサービスなのにキャッシュを一切持たせないとはこれいかに・・・って思いませんか？知っている人からしたら当たり前なのでしょうが、私はこの構成を知ったときは、「え？なんで？？？」って思いました。しかし以外にも調べてみるとキャッシュを一切持たせないCloudFrontを使ってる情報が出てくるんですよね・・・。 ということで、今回はキャッシュを保持しないCloudFrontの利点について調べてみました！ ※追記も目を通していただけると！ 構成について 文字だけじゃイメージし難いと思ったのでさっくりシンプルアイコンでシステム図を描きました。図にいくつか余計なものが描いてあるので、勘のいい人は既に利点に気が付いたのではないでしょう

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで CloudFront の IP アドレスが Managed Prefix List でサポートされました。これにより CloudFront を経由しない不正なアクセスを簡単に弾くことが可能になります。CMS など CloudFront を使う機会が多いサービスではぜひご利用ください。また CloudFront で AWS WAF を使ってセキュリティを向上している場合の迂回路を塞ぐことができます。 Amazon CloudFront now supports a managed prefix list CloudFront を経由しないアクセス 今まで AWS で CloudFront を経由したアクセスだけ強制させる場合は、CloudFront ではカスタムヘッダを付与して、その値を ALB や Web サーバで

CloudFront を利用する際に オリジンの Webサーバ に 「CloudFront を経由しないアクセスを許可したくない」という状況があるかと思います 「CloudFront を経由しないアクセスを許可したくない」を達成する方法として以下の２つを紹介します ① カスタムヘッダの追加による制御 ② Origin Access Identityによる制御 留意事項 2022/2/8 にアップデートがありました CloudFront のオリジンが EC2 や ALB のときはセキュリティグループのルールに 「Cloud Front のAWSマネージドプレフィクスリスト」のみを許可するルールを書くことができます これにより CloudFront を経由した接続のみ許可可能になりました こちらもご参照ください blog.serverworks.co.jp 2022年8月に、OAI に代わる

どうもこんにちは 技術課の山本です 休日は山に登っています 山中湖パノラマ台付近 そして新内眞衣さん卒業おめでとうございます(これを言いたくてブログを書きました) さて本題です CloudFront が AWS-managed prefix list に対応しました aws.amazon.com prefix list (プレフィクスリスト)ってなに？ docs.aws.amazon.com Cidr ブロックをリストにして束ねたものです セキュリティグループやルートテーブルの設定・管理を楽にしてくれます 例として 2つの Cidr ブロックを 1つのプレフィクスリストに束ねて pl-my.network と名前を付けます ※カスタマー管理プレフィクスリスト プレフィクスリストの名前 エントリするCidr ブロック pl-my.network 172.32.1.1/32 172.32.2.

はじめに AWSチームのすずきです。 ALBの高度なリクエストルーティング を利用して、CloudFront、CDNを経由しない、ELBへの直リクエストを禁止したALBを設定する機会がありましたので、紹介させていただきます。 https://dev.classmethod.jp/cloud/aws/advanced-request-routing-for-alb/ ELB設定 デフォルトルールの編集 設定対象のALBを選択、「リスナー」のタブより「ルールの表示/編集」より設定を行います。 「デフォルトアクション」 のルールを変更します。 デフォルトアクションとして以下を設定しました 固定レスポンスを返す レスポンスコード: 403 Content-Type: text/plain; レスポンス本文: Not authorized CloudFront access. カスタムルールの追加

はじめに どうも、BASECAMP ESSENTIALS 参加者の崎山です！ 今回苦戦したCloudFrontとALB間のHTTPS接続について書きたいと思います。 意外と初心者の方は引っかかる箇所だと思いますので、この記事が参考になればうれしいです。 ちなみに接続時のエラーは、HTTP 502 ステータス コード (Bad Gateway) が出力されました。 【引用：HTTP 502 status code (Bad Gateway)】 HTTP 502 ステータス コード (Bad Gateway) は、CloudFront がオリジン サーバーに接続できなかったため、要求されたオブジェクトを提供できなかったことを示します。 構成図 前提 クライアント(ブラウザ)からALBにHTTPS接続して、EC2(Webサーバー)にアクセスできる 参考：【初心者向け】AWSのサービスを使ってWe