AWS 公式ドキュメントが 2023年8月時点で公開している「Best Practices for WordPress on AWS」にある設定例「CloudFront distribution creation」の内容が古かったので、自分なりに改良してみました。 主な改良点は レガシーキャッシュルールではなく、新しいのキャッシュポリシーを使う wp-json ディレクトリの通信を対応する Facebook や広告タグのクエリをオリジンサーバーに飛ばなくする です。 STEP.1 キャッシュポリシーを作成 絶対に CloudFront にキャッシュさせるように最小TTLを60に設定しています。アクセス頻度が少ないサイトであれば、最小TTLを増やすなどしてください。ただ、ページの更新の時間もかかるのでバランスを考えましょう。 名前: 0-default (適当に変えてください) 説明: 任意
CloudFrontのキャッシュクリア（invalidation）を自動化してみた – 仕組みやCLIコマンドを解説 | thilog
こんにちは。てぃろです。 CloudFrontのキャッシュ（chache）をうまく使えてますか？ CloudFrontではWebアプリ配信のレスポンスをよくするためにキャッシュを使えます。しかし、アプリを新たにデプロイする時にはキャッシュをクリア（削除）しないと、古いアプリのまま使われてしまう恐れがあります。 そこで、アプリをデプロイするたびにCloudFrontのキャッシュを自動的にクリアできるようにしたいと思います。 CloudFrontのキャッシュ詳しい仕様は公式ドキュメントをご覧ください。 今回も自作のアプリフレームワークを題材に解説していきます。以下がフレームワークの概要説明の資料です。 CloudFrontのキャッシュクリアの操作をマネジメントコンソールで確認するまず、CloudFrontのキャッシュクリアの操作がどのようなものか見ていきます。 突然ですが、公式ドキュメントやマ
[アップデート] Amazon CloudFront がオリジン Cache-Control ヘッダーの stale-while-revalidate と stale-if-error をサポートしました | DevelopersIO
[アップデート] Amazon CloudFront がオリジン Cache-Control ヘッダーの stale-while-revalidate と stale-if-error をサポートしました いわさです。 CloudFront ではオリジンの Cache-Control で個々のオブジェクトに対するキャッシュの挙動を制御することが可能です。 本日のアップデートでstale-while-revalidateとstale-if-errorを CloudFront でも利用出来るようになりました。 それぞれの仕様は以下で確認出来ます。 stale-while-revalidateディレクティブは、キャッシュの有効期間が切れた後も一定期間は古いキャッシュを利用することが出来ます。 その間にバックグラウンドで非同期でオリジンレスポンスを取得してキャッシュを最新化することが出来る仕組みで
![[アップデート] Amazon CloudFront がオリジン Cache-Control ヘッダーの stale-while-revalidate と stale-if-error をサポートしました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/17d6fdb640a27970efada177996eba4546025db8/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Famazon-cloudfront.png)
[初心者向け]Webサービスを利用する際のDNSからTCPコネクションについて再入門 | DevelopersIO
もう少しSOAレコードについて触れます。 形式として、下記のようになっており、 [認証局ドメイン] [ゾーン管理者のドメイン] [ゾーンのシリアル番号] [更新時間] [再試行時間] [期限が切れる時間] [負の結果をキャッシュする TTL] ゾーンの管理を行うDNSサーバのFQDN（ホスト名まで含むドメイン名）や、管理者に連絡が取れるメールアドレス、ゾーン情報の新旧を判別するためのシリアルナンバー（改訂する度に増加する）が順に記載されています。 続く3つの情報は、セカンダリネームサーバがプライマリのネームサーバから入手したゾーン情報を、どう扱うかを指定するものです。各データはそれぞれ秒数で指定されています。 digコマンドで弊社クラスメソッドのSOAレコードを確認してみましょう。ANSWER SECTIONに上記形式で内容が記載されています。 # SOAレコード $ dig soa cl
![[初心者向け]Webサービスを利用する際のDNSからTCPコネクションについて再入門 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f1fde3cff7767965729d2d96d3e31da5b8a643d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_developers.io_1200x630.jpeg)
Amazon CloudFrontのデフォルト上限値が更に更に大幅アップしました！(2020初夏) | DevelopersIO
はじめに 清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、その開発者ドキュメントを確認していたところ、デフォルトのクォータ(上限値)が引き上げられたことが確認できたのでまとめてみます。引き上げられたデフォルトのクォータは「データ転送レート」がこれまでの40Gbpsから150Gbpsに、「1秒あたりのリクエスト数」が100,000から250,000となっています！ Quotas - Amazon CloudFront クォータ - Amazon CloudFront なお2020/05/30 03:00(JST)現在、日本語版ドキュメントは未反映のようです。英語版ドキュメントを参照ください。 またGitHubでドキュメントソースの差分を確認すると、2020/05/20に更新されていた内容のようです。 Update t
しばたです。 AWS環境を構築・運用する際は各リソースの識別子となるAmazon Resource Names(ARN)をよく見ることになると思います。 ある日ふとタイトル通りの疑問が湧いたので調べてみることにしました。 Amazon S3のARNにある ::: ってなんだろう？ AWSの識別子であるARNの形式については以下のドキュメントに記載されています。 Amazon リソースネーム (ARN) ドキュメントの内容を一部引用するとARNは一般的に以下の:区切りの形式を採ります。 arn:partition:service:region:account-id:resource-id arn:partition:service:region:account-id:resource-type/resource-id arn:partition:service:region:account-
こんにちは、CTOの森です。 本記事はiimonアドベントカレンダー16日目の記事となります。 普段機械学習を使うことは無いのですが、勉強も兼ねてCloudFrontのログを機械学習させてみたらどうなるのか試してみました。 検証した環境 ログデータの形式 使用したログデータのフィールド 分析までの手順 正しくデータを読み込む 学習できる形式に変換 method result_type path_num path_0 ~ path_4 query_num query_len sc-status time-to-first-byte 学習 元のデータと結合 CSVファイルに出力 コード全体 分析結果 (比較的)うまくいった結果 うまくいかなかった結果 参照したサイト まとめ 最後に 今回ログデータをIsolation Forestという手法を用いて分析してみました。Isolation Fore
New – HTTP/3 Support for Amazon CloudFront | Amazon Web Services
AWS News Blog New – HTTP/3 Support for Amazon CloudFront Amazon CloudFront is a content delivery network (CDN) service, a network of interconnected servers that is geographically closer to the users and reaches their computers much faster. Amazon CloudFront reduces latency by delivering data through 410+ globally dispersed Points of Presence (PoPs) with automated network mapping and intelligent ro
Route 53 + CloudFront + S3でZoneApexへのHTTP/HTTPSリクエストをリダイレクトする | DevelopersIO
こんにちは、佐伯です。 静的サイトを既存のApache or NginxからCloudFront + S3に移行を行う場合、既存サイトがZoneApex(例:example.com)へのリクエストをwww.example.comにリダイレクトしており、引継ぎたいケースがあります。 HTTPのみであれば以下エントリのようにS3の静的ウェブサイトホスティングのリダイレクトルールを使用することで、リダイレクトすることができます。 Route 53でZone ApexドメインをS3を使ってリダイレクトする 今回はHTTPSもサポートした構成となります。 やってみた 構成図 リダイレクト用のCloudFrontとS3バケットを作成して、静的サイトのFQDNへリダイレクトします。なお、今回の手順ではリダイレクト先は既に存在している前提となっており、リダイレクト先のリソース作成手順などは省いています。
Amazon CloudFront now supports HTTP version 3 (HTTP/3) requests over QUIC for end user connections. HTTP/3 uses QUIC, a user datagram protocol (UDP) based, stream-multiplexed, secure transport protocol that combines and improves upon the capabilities of existing transmission control protocol (TCP), TLS, and HTTP/2. HTTP/3 offers several benefits over previous HTTP versions, including faster respo
「ハイトラフィック運用 〜スループットの向上を目指して〜」という話をしました #devio2020 | DevelopersIO
こんにちは(U・ω・U) AWS事業部の深澤です。 さて弊社では昨日よりDevelopersIO2020 〜connect〜というイベントが開かれています。 セッションもりもりだよ！ あつまれー！https://t.co/viwYQqiKG7#devio2020_connect — 深澤俊 (@shun_quartet) June 3, 2020 その中で僕は「ハイトラフィック運用 〜スループットの向上を目指して〜」という話でセッションさせていただいたので本ブログではその発表した内容を資料と共にご紹介します！ 動画 資料 セッション内容 今回扱うこと、扱わないこと 今回は観点をメインに紹介します。 それぞれのエンジン等による細かい違いやチューニング方法には触れません。 例：MySQLとPostgras等 メトリクスはCloudWatchのものをご紹介します。 今回はあくまで概要と基本です。
CloudFront の継続的デプロイメントを使用して CDN の変更を安全に検証する | Amazon Web Services
Amazon Web Services ブログ CloudFront の継続的デプロイメントを使用して CDN の変更を安全に検証する 本稿は Joe Viggiano, Carl Johnson, Vishal Anand によるブログ Use CloudFront continuous deployment to safely validate CDN changes を翻訳したものです。翻訳はソリューションアーキテクト 森が担当しました。 Amazon CloudFront などのコンテンツ配信ネットワーク（CDN）は、多くの場合、ユーザーやデバイスがウェブサイトやアプリケーションに接続するためのフロントドアとなります。CDN の設定を変更すると、問題の原因を限定的にしか把握できないまま、完全な停止に至る可能性があります。CDN の設定変更のテストを提供するための既存のソリューション
AWS WAF（Web Application Firewall）は、Amazon Web Services（AWS）が提供するウェブアプリケーションファイアウォールサービスです。このサービスは、ウェブアプリケーションを悪意のあるトラフィックや攻撃から保護するためのものです。 AWS WAFとは？ AWS WAFは、ウェブアプリケーションやAPIに対する一般的なウェブ攻撃を検出し、ブロックするためのサービスです。これにより、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃を防ぐことができます。 AWS WAFのメリット カスタマイズ可能: AWS WAFは、特定のトラフィックパターンや攻撃を検出・ブロックするためのカスタムルールを設定することができます。 リアルタイムのモニタリング: AWS WAFは、リアルタイムでのトラフィックの監視とログの取得が可能です。 スケ
Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転
EC2のみでWebサーバーをたて本番稼働している環境について、AWS WAFを導入したい旨のご相談をいただくことがあります。AWS WAFを導入する前に知っておきたいこと、確認していただきたいことをご紹介します。 WAFで悪意のないユーザーの通信を遮断してしまうリスクを認識しておく AWS WAFに限らず、WAFは悪意のないユーザーの通信を遮断してしまう恐れがあります。導入しただけで完了するサービスではありません。WAFのログを確認し、誤検知しているルールはカウントに変更するといった運用が必要です。運用の支援が必要な場合、WafCharm（ワフチャーム）を検討します。WafCharmはCSC社が提供するAWS WAFのルール作成や運用を支援するサービスです。詳しくはブログをご覧ください。 WAFでは防げない攻撃もある IPA テクニカルウォッチ「DOM Based XSS」に関するレポート
○○ ができない！ IAM ポリシーを確かめよう。実例から学ぶ原因と解決策 〜オペ部だより〜 | DevelopersIO
こんにちは、札幌在住 AWS 事業本部 オペレーション部（通称オペ部）の池田です。オペ部ではクラスメソッドメンバーズにご加入いただいているお客様が直面されたお困りごとや疑問など、様々なお問い合わせに対して各種ドキュメントや技術検証結果のご案内をしたり、場合によっては AWS と連携してお客様が直面している問題解決の支援を行なっています。 本記事では、タイトルにある通り実際にいただいた「○○ ができない」といったお問い合わせの中から IAM ポリシーに原因があったいくつかの事例とその解決策をご紹介したいと思います（今回も全ての事例と原因を網羅できているわけではありませんが、調査方法の参考にしていただけると嬉しいです）。 RDS インスタンスが作成できない 事象 AdministratorAccess、PowerUserAccess 以外の IAM ユーザーで RDS インスタンスを新規作成し
大阪オフィスのちゃだいんです。 当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の17日目のエントリです。 このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。17日目のテーマは『AWS WAF』です。 目次 そもそもWAFとは WAFとは なぜ WAFを使うのか AWSで対策できる攻撃の種類 WA
Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins
Starting today, customers can protect their AWS Lambda URL origins by using CloudFront Origin Access Control (OAC) to only allow access from designated CloudFront distributions. Lambda function URLs allow customers to implement single-function services like form validators, mobile payment processing, machine learning inference, and more. Many customers front their Lambda function URLs with CloudFr
証明書発行までの認証プロセス概要図 EVは細かい審査があるので、安心感がありますね。一方、ドメイン認証は実在確認していないので、運用者が実在するか確認していないですね。（認証局によってはドメイン認証でも実在確認しているところもあると思います。） SSLサーバ証明書のオプション 上記の種類の他にオプションがあります。 ワイルドカード 同一のドメイン配下の複数の異なるサブドメインに利用できるSSL証明書。 コモンネームに「＊.example.com」を指定することで「www.example.com」や「api.example.com」、「admin.example.com」といったサブドメインが異なるサイトを1枚の証明書でカバーすることができる証明書です。 「＊.example.com」で発行されている場合、「example.com」と「＊.example.com」がSubject Alter
「X-Forwarded-For」ヘッダをサポートしたAWS WAFで CloudFront経由の過剰リクエストをELBで止めてみた | DevelopersIO
AWSチームのすずきです。 2020年7月、AWS WAF が X-Forwarded-For ヘッダーをサポートするアップデートがありました。 X-Forwarded-For (XFF) ヘッダーのサポートが AWS WAF で利用可能に 今回 X-Foward-Forに示されたリクエスト元のIPを判定対象とした レートベースのWAFルールを作成、 CloudFront 経由で到達した過剰なリクエストを、ELB用の AWS WAF でブロックできる事を確認する機会がありましたので、紹介させていただきます。 構成図 AWS WAF設定 ELB/CloudFront用 「Regional resources」を指定して、ELB用のACLを作成します。 Resource type: Regional resources Region : 東京リージョン ルール設定 ルールビルダーを利用しました
Amazon CloudFrontにオリジンへのリクエストを軽減するキャッシュレイヤー(Origin Shield)が追加されました | DevelopersIO
AWSのCDNサービスAmazon CloudFrontに新しいキャッシュレイヤーOrigin Shieldが追加されました。 これまでのキャッシュは 200を超える Points of presence (POP/エッジロケーション) 10を超えるリージョナルエッジキャッシュ の2レイヤーでした。 今回追加された Origin Shield はリージョナルエッジキャッシュよりもさらにオリジンよりのキャッシュレイヤーです。 このキャッシュレイヤーを利用すると オリジンへのリクエスト オリジンからのアウトバウンドトラフィック(data transfer out/DTO) を Origin Shield に集約する事ができます。 Origin Shield のユースケース グローバル展開しているサービスを考えます。 以前は全世界のリージョナルエッジキャッシュが個別にオリジンと通信していました。
CloudFrontでモバイルデバイスのOS判別ができるCloudFront-Is-Android-Viewer/CloudFront-Is-IOS-Viewerヘッダを確認してみた | DevelopersIO
CloudFrontでモバイルデバイスのOS判別ができるCloudFront-Is-Android-Viewer/CloudFront-Is-IOS-Viewerヘッダを確認してみた CloudFrontがオリジンへのリクエストの際に付与するヘッダで、ユーザが使用しているデバイスがモバイルであるかの判定のほか、モバイルデイバスのOS（Android/iOS）についても判定が可能です。実際に動作を確認してみました。 はじめに 清水です。AWSのCDNサービスであるAmazon CloudFrontでは以前からユーザがコンテンツ表示に使用しているデバイスを判定するCloudFront-Is-Mobile-Viewerヘッダなどが利用可能でした。この機能自体は2014年6月のアップデートで追加されたものです。 [新機能] Amazon CloudFrontでモバイル端末を判定できるようになりまし
CloudFront KeyValueStoreがリリース。CloudFront Functionsからキーバリューストアを利用可能に！ | DevelopersIO
CloudFront KeyValueStoreがリリース。CloudFront Functionsからキーバリューストアを利用可能に！ AWS向けのCDNサービスCloudFrontがCDNエッジ向けのグローバルかつ低遅延なキーバリューストアAmazon CloudFront KeyValueStoreをリリースしました。 CloudFront向けエッジ･コンピューティングサービスのCloudFront Functions(CF2)から利用出来ます。 CF2はLambda@Edge(L@E)に比べて速くて安いといったメリットもありましたが、CloudFront Functions関数内に閉じた簡易的な文字列操作しか出来ませんでした。 そのため、豊富なライブラリのインストール、さらには、インターネットアクセス(DB接続)も可能なL@Eに比べて、処理内容が限定的でした。 今回のアップデートに
Amazon CloudFront adds support for client IP address and connection port header
Amazon CloudFront now provides a CloudFront-Viewer-Address header that includes IP address and connection port information for requesting clients. The connection port field indicates the TCP source port used by the requesting client. Previously, IP address and client connection port information were available only in CloudFront access logs, making it harder to resolve issues or perform real-time d
CDN とセキュリティエクスペリエンスを統合した CloudFront セキュリティダッシュボードのご紹介 | Amazon Web Services
Amazon Web Services ブログ CDN とセキュリティエクスペリエンスを統合した CloudFront セキュリティダッシュボードのご紹介 セキュリティの脅威がより高度化し、その脅威が広がりやすくなるにつれ、お客様はより Amazon CloudFront と AWS WAF を使用して、Web アプリケーションと API のパフォーマンス、回復性、セキュリティを向上させています。 CloudFront はコンテンツ配信ネットワーク (CDN) で、CloudFront の数百のエッジロケーションのうち、ユーザーに最も近い場所からデータを配信することで、世界中のユーザーの待ち時間を短縮します。 AWS WAF は Web アプリケーションファイアウォールで、一般的なエクスプロイトや望ましくないボットの通信トラフィックから Web アプリケーションを保護するために、悪意のある
AWS CloudFront Pricing and Cost Optimization Guide | CloudForecast
CloudFront is AWS own CDN (Content Delivery Network). CDNs are primarily used for caching, and many customers also use AWS CloudFront CDN as a security layer, or use it to handle network spikes. With AWS CloudFront CDN, when a user requests a webpage or an image, the request is routed to one of Amazon’s 225+ edge server locations. If the edge server already has the resource cached, it’s served to
概要 はじめに 本日は、AWS CloudFront + WordPress 構成を構築する上でハマった落とし穴をいくつかご紹介します。CloudFront + WordPress 構成を採用される方は、参考にして下さい。 システム構成 Amazon Lightsailに、WordPress環境を起動しています。WordPressのバージョンは、5.6です。WordPressのフロントにCloudFrontを設置し、CloudFrontでSSLの終端を行っています。 なお、今回ご紹介する落とし穴は、通常のWordPress環境およびWordPress Multisite環境の両方で発生することを確認しております。 siteurl がオリジン側のURLを向いてしまう 説明 Amazon LightsailにWordPressのインスタンスを起動し、CloudFront のオリジンに設定してデ
CloudFront の Cache Policy と Origin Request Policy を理解する - Qiita
はじめに CloudFront の Management Console で Behavior を設定していると、こんな見慣れない機能が表示されるようになっていた。 これは何ぞや、と思って調べてみたら 2020/07 のアップデート内容のようだ。 Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 かなり新しい機能で、まだ資料が少なかったので自分の理解のために従来と比較して何がうれしいのかをまとめてみた。 TL; DR この機能の実装前はオリジンへのForwardとキャッシュキーの項目が自動的に一致していた Policyの実装によって、キャッシュキーとオリジンへの項目転送を分離してより柔軟で直感的なキャッシュルールを定義できるようになった 1度書いた設定を複数の Behavior で再利用できるようになった 1. CDN / CloudFront の仕
CDNキャッシュ向けレスポンスヘッダーCache-Control:s-maxage を触ってみた | DevelopersIO
HTTPレスポンスヘッダー「Cache-Control:s-maxage」ディレクティブを使うと、CDNのキャッシュ時間をオリジンでコントロールできます。 CDNやプロキシといった共有キャッシュ向けにキャッシュの保持期間を制御する Cache-Control: s-maxage=seconds というレスポンスヘッダーが存在します。 ブラウザとCDNでキャッシュの保持期間を分けたい時や、マルチCDNの構成においてオリジン側でCDNのキャッシュの保持期間を一元管理したい時などに重宝します。 本記事では、この共有キャッシュ向けレスポンスヘッダーについて、かんたんに紹介します。 ブラウザ向けの max-ageと共有キャッシュ向けの s-max-age s-maxage によく似たディレクティブに max-age があります。どちらも Cache-Control と一緒に用いますが、用途は少し異な
こんにちは、坂巻です。 今回はCloudFrontを利用し、以下2つの構成で特定のパスへのアクセスをリダイレクトしてみたいと思います。 CloudFront + Custom Origin(ALB) CloudFront + S3 Origin（ウェブサイトホスティング） CloudFront + Custom Origin(ALB) 構成 https://region.nochan.tk/nekoへのリクエストは、CloudFrontを経由させALBの機能でhttps://dev.classmethod.jpにリダイレクトさせます。（httpの場合はhttpsにリダイレクト） 同様にhttps://region.nochan.tk/inuへのリクエストはhttps://twitter.com/classmethodにリダイレクトさせます。 それでは、リソース毎の設定をみていきたいと思いま
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました | DevelopersIO
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました キャッシュ設定をポリシー化することでBehaviorごとの設定が非常に楽になりました！また、キャッシュキーとオリジンリクエストの設定が分離されたことで、キャッシュ効率に影響を与えることなくオリジンに追加情報を渡せるようになりました。 4 連休ということもありアップデート記事が遅くなってしまいました。 先日のアップデートで、Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました。 Amazon CloudFront announces Cache Key and Origin Request Policies 何がうれしいのか キャッシュおよびオリジンリクエスト設定の外だし これまで Behavior の設定ごと
こんにちは、大前です。 CloudFront + S3 で HLS コンテンツを配信する構成で、署名付き Cookie を使用する機会がありましたので備忘録としてブログを書いていきます。 前提 署名付き Cookie とは 署名付き Cookie とは、CloudFront でプライベートなコンテンツ配信を実現する機能の１つです。 署名付き Cookie の使用 この機能を使用すると、特定の Cookie がセットされている場合に限り、CloudFront からコンテンツを取得する事が出来る様になります。 ※CloudFront 側で署名付き Cookie を利用したリクエスト以外を拒否する設定にする必要があります 特定のユーザにのみコンテンツを配信したい時などに、認証の仕組みと組み合わせる事でプライベートなコンテンツ配信が可能となります。 なぜ HLS に署名付き Cookie を使うの
Use CloudFront continuous deployment to safely validate CDN changes | Amazon Web Services
Networking & Content Delivery Use CloudFront continuous deployment to safely validate CDN changes Content delivery networks (CDN) like Amazon CloudFront are often the front door for users and devices to connect to websites or applications. A change to your CDN configuration could result in a complete outage with limited visibility into the cause of the issue. Today’s existing industry solutions fo
CloudFrontではデフォルトでOriginヘッダ自体の転送をしている話〜Video.jsで発生するCORSエラーのトラブルを例にして | DevelopersIO
CloudFrontではデフォルトでOriginヘッダ自体の転送をしている話〜Video.jsで発生するCORSエラーのトラブルを例にして Amazon CloudFrontではデフォルト状態でもオリジンサーバにOriginヘッダ自体は転送しています。Video.jsで発生するCORSエラーを例に、この点を把握していないと遭遇しうるトラブルについてまとめてみます。 はじめに 清水です。JavaScript製の動画プレイヤーであるVideo.jsなどCORS設定が必要な環境下でCloudFrontを使用する場合、オリジン側でCORS設定をしていても、CloudFront側でOriginヘッダのオリジンへの転送設定を忘れてしまうと思わぬトラブルにつながる場合があります。具体的に私が経験したのは、ライブ動画配信をVideo.js(videojs-http-streaming)で行った場合、テスト
Lambda@Edge ファンの皆さん！ついにこの日が来ましたよ！ 本日のアップデートで Lambda@Edge で Python3.7 がサポートされるようになりました！ Lambda@Edge Adds Support for Python 3.7 何が嬉しいのか 従来、Lambda@Edge でサポートされる言語は Node.js のみでした。私のように 「Node.js 書けないですが、Python ならちょっと書けます」 という方には待望のアップデートです！ サンプルコード Lambda@Edge の公式ガイドのサンプルコードにも既に Python が追加されていますね。（日本語ページはまだアップデートされてません） やってみる サンプルコードを拝借して Python3.7 の Lambda 関数を作成します。（Lambda@Edge 関数は バージニアリージョンで作成する必要が
Amazon CloudFront オリジンアクセスコントロール（OAC）のご紹介 | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront オリジンアクセスコントロール（OAC）のご紹介 本記事は、「Amazon CloudFront introduces Origin Access Control (OAC)」と題された記事の翻訳となります。 Amazon CloudFront は、アプリケーション、ウェブサイト、動画、API を世界中の視聴者にミリ秒で安全に配信するグローバルなコンテンツ配信ネットワークです。CloudFront を利用することで、お客様はユースケースに合わせて様々なタイプのオリジンサービスにアクセスすることができます。お客様が採用されているパフォーマンスの高いアーキテクチャの1つは、Amazon S3 をオリジンとして Web サイトや動画などのコンテンツをホストし、CloudFront を使用して視聴者に配信するものです
前回調査：2022年10月 調査方法 Webクローラー（スパイダー）によるWebサイト調査 集計日 2023年4月7日 対象 Cloudflare、Akamai、Cloudfront、CDNetworks、Incapsula、Limelight、Edgecast，国内CDN事業者（Accelia、IDCF、IIJ、J-Stream） CDN判定方法 cnameベース Akamai, Fastly, Edgecast, Limelight, Accelia, IIJ, IDCF, J-Stream レスポンスヘッダ(サーバ名)ベース Cloudflare, Cloudfront, Incapsula シェア集計の単位 ドメイン(例, example.jp) 補足：FQDNでの集計では、CDNを使用しているblogサイトの影響が出る。つまり、いくつかのブログサイトは、user1.blog.ex
【AWS】S3+CloudFront+Route53+ACMでSSL化(https)した静的Webサイトを公開する
概要 本記事では、S3+CloudFront+Route53を利用して、静的サイトを公開する実装手順を紹介します。ACMを使ってSSL証明書を発行し、httpsで公開します。 LP（ランディングページ）、ポートフォリオサイト、シンプルなサイトなどをインターネット上に公開する際に役立ちます。 構成図 本記事のゴール 今回のゴールは、以下のhtml,ccs,画像だけのシンプルな静的Webサイトを、独自ドメインを使用してインターネット上に公開することです。 事前準備 AWSのアカウント 公開するファイル（html,css,imageなど） 実装手順 S3で静的Webサイトホスティングをする CloudFront経由でS3のファイルにアクセスする CloudFrontのOAIを使用して、S3への直接アクセスを制限する 独自ドメインを取得し、Route53へ設定する(freenomで無料ドメインを取
Amazon CloudFront announces support for HTTP status and response generation using CloudFront Functions
Starting today, you can use CloudFront Functions to further customize responses to viewers, including changing the HTTP status code and replacing the HTTP body of the response. CloudFront Functions is a serverless edge computing feature on CloudFront built for lightweight HTTP transformations that runs in the 450+ CloudFront edge locations globally. Previously, CloudFront Functions allowed transfo
CloudFrontのCNAMEをディストリビューション間でダウンタイム無しにアトミックに移行できるようになりました | DevelopersIO
Amazon CloudFrontはディストリビューション間のCNAMEの重複が許可されていません。 そのため、この CNAMEAlreadyExists 回避のために、 AWSサポートに対応を依頼 ワイルドカード形式のCNAMEを経由して付け替え といった対応が行われてきました。 CloudFrontのCNAMEAlreadyExistsエラーを回避しつつCNAMEを付け替える | DevelopersIO CloudFront エラー「CNAMEAlreadyExists」の解決 今回のアップデートにより、条件付きではありますが、ダウンタイム無しにディストリビューション間でアトミックにCNAMEを付け替えられるようになりました。 New APIs and functionality for managing Amazon CloudFront CNAMEs | Networking &
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WordPress に最適な CloudFront キャッシュ設定 (2023年度版) - Qiita
Amazon S3のARNにある ::: ってなんだろう？と気になったはなし | DevelopersIO
CloudFrontのログを使って機械学習で異常検知を試してみた - iimon TECH BLOG
Amazon CloudFront now supports HTTP/3 powered by QUIC
AWS WAF ベーシックな設定について - Qiita
AWS WAFを導入する時に確認しておきたいこと | DevelopersIO
AWS再入門ブログリレー AWS WAF編 | DevelopersIO
【初心者向け】SSLサーバ証明書の選び方 | DevelopersIO
CloudFront + WordPress 構成の必須設定 | Oji-Cloud
CloudFrontで特定のパスへのアクセスをリダイレクトさせる | DevelopersIO
署名付き Cookie を使用して HLS コンテンツを取得してみた | DevelopersIO
[アップデート]Lambda@EdgeでPythonがサポートされました！！ | DevelopersIO
日本のCDNシェアについて調査結果＠2023年4月 | J-Stream CDN情報サイト