タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
【アップデート】Amazon CloudFront を経由しないアクセスのブロックが簡単になりました | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程のアップデートで 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 サーバで
Amazon S3 + Amazon CloudFrontでWebサイトを構築する際にS3静的Webサイトホスティングを採用する理由 | DevelopersIO
はじめに 静的Webサイトを構築する際にAmazon S3とAmazon CloudFrontを利用するアーキテクチャは定番ですが、これらを利用したアーキテクチャには2つの手法があります。 オリジンアクセスアイデンティティを使って、S3バケットへのアクセスをCloudFrontディストリビューションからのみに制限する方法 S3の静的ウェブサイトホスティングを有効化し、CloudFrontにカスタムドメインとして設定する方法 前者がベターに思えるかもしれませんが、後者の方が良い場合もあります。それは ランディングページなどのシンプルなHTMLベースで構築するWebサイトの場合 です。 本記事では、どういった理由でS3のウェブサイトホスティングを採用するか解説します。 リダイレクト設定がかんたん 静的Webサイトホスティングにはリダイレクトを自由にカスタマイズできるRedirection Ru
AWS テクニカルトレーナーと学ぶ Amazon CloudFront ~ エッジロケーションを使った通信の仕組み - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「Artiste (アルティスト)」です。 AWS を学習していて「Amazon CloudFront はコンテンツ配信の最適化や高速化をするサービスである」ということは知っているけれど、「どのような通信経路になるのか」や「なぜ近くのエッジロケーションへアクセスできるのか」は理解できていないなと感じる方はいませんか ? というのも、トレーニングを受講していただいた方から「Amazon CloudFront の概要だけは知っていたけど、具体的な動作まで理解できた !」と言っていただくことがあります。そこで他にも多くの方に Amazon CloudFront の学習や利用に役立てていただけるよう、「仕組み」に焦点を当てた解説記事を書いてみました。それでは私が自作した図を交えながら順を追って説明していきます ! ま
[アップデート] root ユーザー作業が不要に！Amazon CloudFront で署名付き URL/Cookie 向け公開鍵を IAM ユーザー権限で管理できるようになりました。 | DevelopersIO
本日のアップデートで Amazon CloudFront の署名付き URL および署名付き Cookie に対する公開鍵の管理を、IAM ユーザー権限で行えるようになりました！ Amazon CloudFront announces support for public key management through IAM user permissions for signed URLs and signed cookies IAM ユーザー権限による公開鍵管理が可能に 従来、CloudFront で署名付き URL および 署名付き Cookie を利用する場合、「CloudFront のキーペア」を作成する必要がありました。このキーペアの作成は AWS アカウントの root ユーザーしか行うことが出来ません。そのため必要になった際にアカウント管理者に連絡しキーペアを作成してもらう、
[NEW] Amazon CloudFrontでStaging Distributionを使ったContinuous Deployment（継続的デプロイ）がサポートされました！ | DevelopersIO
[NEW] Amazon CloudFrontでStaging Distributionを使ったContinuous Deployment（継続的デプロイ）がサポートされました！ 柔軟なDistributionの設定変更が難しかったCloudFrontで継続的デプロイがサポートされました。ステージング用Distributionを作成し一定量のリクエストを割り振って動作確認をしたあと、本番環境に昇格させるデプロイが行えます！ はじめに 清水です。AWSのCDNサービスであるAmazon CloudFrontにContinuous Deployment（継続的デプロイ）機能がやってきました！本日（日本時間2022/11/19、現地時間2022/11/18）AWS Blogsにポストされたアップデートについてお届けします！！ Use CloudFront continuous deploymen
![[NEW] Amazon CloudFrontでStaging Distributionを使ったContinuous Deployment（継続的デプロイ）がサポートされました！ | 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)
Amazon CloudFrontはボディを含むGETリクエストに403(Forbidden)を返します | DevelopersIO
『Real World HTTP 第2版』で知ったのですが、GETリクエストにはメッセージボディを含めることができます。 より具体的には、HTTP/1.1の一世代前の仕様RFC2616 *1では、「サーバーはメッセージボディを読み込める必要はあるが、リクエストされたメソッドがボディのセマンティクスを定めていない場合は、リクエストの処理時にメッセージボディは無視されるべき」と書かれており、最新のRFC7231 *2では、「ペイロードのボディを持つことはできるが、実装によってはサーバーがこれを受け取らずに拒否することがありえる」と書かれています。(カッコ内は同書から引用) ALB は 何もせず、CloudFront は403を返す 意図せずリクエストが拒否されると困ります。 普段触れる機会の多い AWS のマネージドサービスがどのように振る舞うのか確認したところ、Application Loa
AWS Free Tier Data Transfer Expansion – 100 GB From Regions and 1 TB From Amazon CloudFront Per Month | Amazon Web Services
AWS News Blog AWS Free Tier Data Transfer Expansion – 100 GB From Regions and 1 TB From Amazon CloudFront Per Month The AWS Free Tier has been around since 2010 and allows you to use generous amounts of over 100 different AWS services. Some services offer free trials, others are free for the first 12 months after you sign up, and still others are always free, up to a per-service maximum. Our inten
Introducing Amazon CloudFront KeyValueStore: A low-latency datastore for CloudFront Functions | Amazon Web Services
AWS News Blog Introducing Amazon CloudFront KeyValueStore: A low-latency datastore for CloudFront Functions Amazon CloudFront allows you to securely deliver static and dynamic content with low latency and high transfer speeds. With CloudFront Functions, you can perform latency-sensitive customizations for millions of requests per second. For example, you can use CloudFront Functions to modify head
TCP BBR 輻輳制御による Amazon CloudFront のパフォーマンス向上 | Amazon Web Services
Amazon Web Services ブログ TCP BBR 輻輳制御による Amazon CloudFront のパフォーマンス向上 コンテンツデリバリネットワーク (CDN) が提供すべき重要な要素の１つとしてパフォーマンスがあります。パフォーマンスの良さを示す２つの観点としてレイテンシーとスループットがあり、これらが優れていると大量の情報を高速にかつ安定して送ることができます。これらの観点はビデオストリームや API コール等のあらゆるコンテンツ配信で重要となります。私たちは、最も幅広いワークロードとコンテンツに対して最高品質の体験を提供することと、パフォーマンスを最大化することのために、Amazon CloudFront の技術とインフラストラクチャを継続的に改良しています。 2019年3月から4月にかけて、CloudFront はレイテンシーとスループットを改良する新しいTCP
[アップデート] 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のデフォルト上限値が更に更に大幅アップしました！(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
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
当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2019』の9日目のエントリです。 このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2019年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。 では、さっそくいってみましょう。9日目のテーマは『Amazon CloudFront』です。 目次 Amazon CloudFront とは CDN（Content Delivery Network） とは
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
AWSホワイトペーパー「Amazon CloudFront for Media」を斜め読みしてみた | DevelopersIO
2020年11月にAWSにより発行されたAmazon CloudFrontを使ってストリーミング配信を行う際のベストプラクティス集なホワイトペーパーについて、ざっとですが読んでみました。概要をまとめてみます。 はじめに 清水です。先日ふとしたことからAWSのホワイトペーパーに「Amazon CloudFront for Media ~ Best Practices for Streaming Media Delivery」という、Amazon CloudFrontを使ってストリーミング配信を行う際のベストプラクティス集なものが追加されていることを知りました。ホワイトペーパー自体のドキュメント履歴から、2020年11月に発行されていたようです。 Amazon CloudFront for Media ~ Best Practices for Streaming Media Delivery
Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 Amazon CloudFront の新しいキャッシュポリシーとオリジンリクエストポリシーにより、CloudFront がリクエストデータを使用して、キャッシュキーとキャッシュミス時にオリジンに転送されるリクエストの両方に影響を与える方法をより詳細に制御できます。これにより CloudFront が実行するキャッシュの制御と効率を向上させながら、さらに柔軟性が高まります。これらの設定はすでに部分的には存在していましたが、キャッシュキーの設定はオリジン転送の設定から独立することになります。以前は転送されたデータのほとんどはキャッシュキーを自動的に変更していました。このポリシーにより、ほとんどのリクエスト要素をキャッシュキーに影響を与えることなくオリジンに転
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
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 のユースケース グローバル展開しているサービスを考えます。 以前は全世界のリージョナルエッジキャッシュが個別にオリジンと通信していました。
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
Amazon VPC now supports an AWS-managed prefix list for Amazon CloudFront
Starting today, you can use the AWS managed prefix list for Amazon CloudFront to limit the inbound HTTP/HTTPS traffic to your origins from only the IP addresses that belong to CloudFront’s origin-facing servers. CloudFront keeps the managed prefix list up-to-date with the IP addresses of CloudFront’s origin-facing servers, so you no longer have to maintain a prefix list yourself. You can reference
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました | DevelopersIO
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました キャッシュ設定をポリシー化することでBehaviorごとの設定が非常に楽になりました！また、キャッシュキーとオリジンリクエストの設定が分離されたことで、キャッシュ効率に影響を与えることなくオリジンに追加情報を渡せるようになりました。 4 連休ということもありアップデート記事が遅くなってしまいました。 先日のアップデートで、Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました。 Amazon CloudFront announces Cache Key and Origin Request Policies 何がうれしいのか キャッシュおよびオリジンリクエスト設定の外だし これまで Behavior の設定ごと
AWS 無料利用枠のデータ転送量の拡大 — リージョンから 100 GB、Amazon CloudFront から 1 TB / 月 | Amazon Web Services
Amazon Web Services ブログ AWS 無料利用枠のデータ転送量の拡大 — リージョンから 100 GB、Amazon CloudFront から 1 TB / 月 AWS 無料利用枠は、2010 年から提供されており、100 種類以上の豊富な AWS のサービスをご利用いただけます。無料の試用版を提供しているサービスもあれば、サインアップ後最初の 12 か月間無料で使用いただけるサービスもあります。また、サービスごとの上限を超えて常に無料のサービスもあります。私たちの目的は、利用料金を支払うことなく、さまざまな強力なサービスを簡単かつ費用対効果の高い方法で体験していただけるようにすることです。 無料利用枠のデータ転送拡張 2021 年 11 月 24 日、AWS の料金引き下げに関する長い伝統の一環として、以下のようにデータ転送量を増加し無料利用枠を拡張できることを嬉しく
[アップデート]Amazon CloudFront のコンソール上からワンクリックで、AWS WAFを作成し適用できるようになりました。 | DevelopersIO
[アップデート]Amazon CloudFront のコンソール上からワンクリックで、AWS WAFを作成し適用できるようになりました。 はじめ 題名通り、CloudFront のコンソール上でワンクリックで、AWS WAFを作成し適用できるようになりました。 今までは、WAFを自身で作成後、CloudFront のコンソール上で適用していましたが、今回のアップデートで、CloudFrontのコンソール上でWAFを作成できるようになったため、より手間が減りますね。 CloudFrontのコンソール上でどのような設定でWAFが作成できるのか確認しました。 CloudFrontを作成する CloudFrontのディストリビューションを作成します。 WAFの有効/無効が選択できるようになっていますね。 日本語に変換してみます。 WAFの有効/無効を選択できることと、モニターモード（=カウントモー
2020-04-03 Amazon CloudFront は AWS が提供している CDN サービスで、 AWS 環境で Web アプリケーションを運用する際に利用することが多いと思います。このブログの運用にも使用しているのですが、ふと CloudFront のキャッシュ仕様について気になったので、あらためて調べてみました。 気になったきっかけは先日書いたブログ記事です。 目次 前提 触れること 各項目の概要 各項目の詳細 Cached HTTP Methods Cache Based on Selected Request Headers Object Caching Forward Cookies Query String Forwarding and Caching まとめ 前提 CloudFront の Web Distribution において、 オリジンに S3 を指定してい
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 を使用して視聴者に配信するものです
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
Amazon CloudFront now offers Origin Access Control, a new feature that enables CloudFront customers to easily secure their S3 origins by permitting only designated CloudFront distributions to access their S3 buckets. Customers can now enable AWS Signature Version 4 (SigV4) on CloudFront requests to S3 buckets with the ability to set when and if CloudFront should sign requests. Additionally, custom
Amazon CloudFront が、stale-while-revalidate および stale-if-error キャッシュ制御ディレクティブをサポート
Amazon CloudFront は、stale-while-revalidate および stale-if-error のキャッシュ制御ディレクティブのサポートを発表しました。これらはパフォーマンスと可用性を向上させます。stale-while-revalidate ディレクティブは、バックグラウンドでキャッシュを再検証している間に、ユーザーに古いレスポンスをただちに配信するよう CloudFront に指示します。stale-if-error ディレクティブは、エラーが発生した場合に CloudFront が古いレスポンスを再利用する時間を定義します。これにより、ユーザーエクスペリエンスが向上します。 stale-while-revalidate を使用すると、CloudFront は 480 以上のエッジロケーションから、より高速なレスポンスを配信できます。また、キャッシュヒット率
Amazon Web Services ブログ Amazon CloudFront を活用したウェブサイトの可用性向上 Amazon CloudFront は、キャッシュ機能によるオリジンサーバー（CloudFront がコンテンツを取得する元のウェブサーバー）の負荷軽減とコンテンツ配信のパフォーマンス向上を実現できますが、可用性の向上もCloudFrontを活用することで得られる大きなメリットの1つです。CloudFront を利用する対象のウェブサイトのオリジンサーバーがAWS 上に存在する場合、オリジンサーバー側でもELB の活用や複数のアベイラビリティーゾーンの活用など可用性向上の為の様々なアプローチがありますが、CloudFront を利用することで更に高い可用性をウェブサイトにもたらすことが出来ます。 ウェブサイトの可用性を向上することは、ウェブサイトの応答速度の向上と同様にウ
Amazon CloudFrontがCDN-オリジン間のパフォーマンスを計測するServer Timingに対応しました | DevelopersIO
Webサーバーのパフォーマンスを計測する Server Timing という規格が W3Cによって策定されており、サーバーが決められたフォーマットでメトリクスをレスポンスに含めると、Server Timing に対応したブラウザからメトリクスを簡単に確認できます。 W3C : Server Timing この仕様のエディターは、Akamai と Google のエンジニアであり、Akamai の CDN では何年も前から Server Timing を有効にでき、Chrome ブラウザからメトリクスを確認できました。 Using CDN Server Timing to Monitor CDN and Origin Performance | Akamai Developer 今回のアップデートにより、Amazon CloudFront もCDN-オリジン間の通信に対してこの Server
Amazon CloudFrontのRTMPディストリビューション機能が2020年12月31日に廃止されます | DevelopersIO
はじめに 清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、そのDiscussion FormusにRTMPディストリビューション機能の廃止がアナウンスされていました。少し前ですが、2019年12月17日にポストされた内容となります。 AWS Developer Forums: RTMP Support Discontinuing on December 31, 2020 本エントリではこのRTMPディストリビューション機能の廃止の背景などを確認してみたいと思います。なお本日2020年3月30日現在、CloudFrontのマネジメントコンソール画面、ディストリビューションを作成する際の配信方式選択画面では以下のように廃止が強調表示されています。（私はこの警告文で廃止を知りました。） 2021/01/16 追記 202
20190730 AWS Black Belt Online Seminar Amazon CloudFrontの概要
AWS公式オンラインセミナー: https://amzn.to/JPWebinar 過去資料: https://amzn.to/JPArchive Read less
ども、ゲストブロガーの大瀧です。 先ほど、AWSのCDN(Content Delivery Network)サービスであるCloudFrontがHTTP/3に対応しました。本ブログでは設定してみた様子をご紹介します。 設定方法 設定自体は非常に簡単です。CloudFrontの構成単位であるディストリビューションの新規作成画面もしくは編集画面にある「サポートされているHTTPバージョン」のチェックボックスのうち「HTTP/3」のチェックボックスを有効にします。 新規作成するディストリビューションではチェックボックスが既定でオフですので、オンで明示し有効化する設定です。 オンにし、ためしにHTTP/3をサポートするWebブラウザであるChromeからアクセス、Developer Toolの[Network]タブで[Protocol]列を表示させてみると... いくつかのリソースのProtoco
[新機能] Amazon CloudFrontでより詳細なジオロケーションヘッダが利用できるようになりました | DevelopersIO
はじめに 清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、これまでもカスタムヘッダによりアクセス元の国コードを取得することが可能でしたが、（[新機能] Amazon CloudFrontがジオターゲティングに対応しました | Developers.IO）今回さらに、都市名や郵便番号、タイムゾーンといったより詳細なロケーションに関する情報がカスタムヘッダにより取得できるようになりました。（2020/07/24にポストされたアップデート内容になります。） Amazon CloudFront adds additional geolocation headers for more granular geotargeting 新たに取得できるようになったジオロケーションヘッダについてはドキュメントの以下ページに詳細がまとめ
Amazon CloudFront ログを使用したリアルタイムダッシュボードの作成 | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront ログを使用したリアルタイムダッシュボードの作成 Amazon CloudFront は AWS グローバルネットワークを使用して、静的および動的なウェブコンテンツを低レイテンシかつ高速で安全に配信するコンテンツ配信ネットワーク (CDN) です。 この度 CloudFront でリアルタイムに利用可能な、デリバリーログを配信する機能が発表されました。このリアルタイムログには、CloudFront が受け取った全てのリクエストに関する詳細情報が含まれます。詳細な情報をリアルタイムで確認することで、運用イベントに迅速に対応できるようになります。 リアルタイムログでは、収集する情報とその配信先をカスタマイズできます。リアルタイムログは Amazon Kinesis Data Streams と統合されており、Am
Amazon CloudFront の CNAME を管理するための新しい API と機能について | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront の CNAME を管理するための新しい API と機能について Amazon CloudFront は、ListConflictingAliases と AssociateAlias という 2 つの新しい API のリリースを発表しました。これらの API は、 CNAMEAlreadyExists エラーコードが発生した際に、代替ドメイン名（CNAME）を探したり、移動させたりする必要がある場合に便利です。さらに、アカウント間でワイルドカードの CNAME を使用する際に、より多くのユースケースで利用することが可能になりました。API について詳細を紹介する前に、このブログではまず CNAMEAlreadyExists エラーコードの背景を少し説明し、CloudFront ディストリビューションで CN
[AWS Black Belt Online Seminar] Amazon CloudFront deep dive 資料及び QA 公開 | Amazon Web Services
Amazon Web Services ブログ [AWS Black Belt Online Seminar] Amazon CloudFront deep dive 資料及び QA 公開 先日 (2020/10/28) 開催しました AWS Black Belt Online Seminar「Amazon CloudFront deep dive」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20201028 AWS Black Belt Online Seminar Amazon CloudFront deep dive AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. AWS WAFやShieldがリリースされる以前はCloudFront単体でDDoS Protectionされていたと記憶していますが、それは今
![[AWS Black Belt Online Seminar] Amazon CloudFront deep dive 資料及び QA 公開 | Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/a52566866b4d16b5f2004a89a51f4833eb9896b5/height=288;version=1;width=512/https%3A%2F%2Fd2908q01vomqb2.cloudfront.net%2Fb3f0c7f6bb763af1be91d9e74eabfeb199dc1f1f%2F2020%2F11%2F26%2Fthumbnail-1120x630.png)
Amazon CloudFront で TLS 1.2 と TLS 1.3 の速度の違いを簡易的に測定してみたら、ちょっとだけ速かった | DevelopersIO
Amazon CloudFront で TLS 1.2 と TLS 1.3 の速度の違いを簡易的に測定してみたら、ちょっとだけ速かった いわさです。 TLS1.2 と TLS 1.3 の違いやメリットについて語られる時、よく「より高速で安全だ」と説明されていることが多いです。 「なるほど、高速なのか。であれば TLS 1.3 のほうがいいのか」なんて思うわけですが、ちょっとだけ速いのか、とんでもなく速いのか実は私はよくわかっていません。 そこで本日は、非常に簡易的な方法で TLS 1.2 と TLS 1.3 でのパフォーマンスを測定をしてみましたので行ったことや結果などを紹介したいと思います。 Amazon CloudFront に Apache Bench で大量リクエストを送信することにした E2E の速度を比較したいなと思いつつ、評価のたびにオリジンの処理速度が影響するのも違うよなぁ
Amazon CloudFront で同一オブジェクト同時リクエスト時の Request Collapsing について確認してみました | DevelopersIO
Amazon CloudFront で同一オブジェクト同時リクエスト時の Request Collapsing について確認してみました いわさです。 高速な Web サイトを構築する際にやはり CloudFront は欠かせないですよね。 エッジにキャッシュが存在している際に、キャッシュヒットする条件であればエッジがそのままレスポンスしてくれるので、オリジンの負荷を大幅に下げることが出来ます。 ところで、キャッシュが期限切れでエッジに存在してない状態で瞬間的に大量のリクエスト (100 とか 1000 とか) が送信されたとき、どうなるかご存知でしょうか。 全てのリクエストがキャッシュなしと判断されオリジンに送信されるのでしょうか。 答えは「キャッシュがない状態で短期間にリクエストが集中しても、オリジンへのリクエストは 1 回」です。 これは、CloudFront の機能の reques
[UPDATE] Amazon CloudFrontでResponse headers policiesがサポートされました！ | DevelopersIO
[UPDATE] Amazon CloudFrontでResponse headers policiesがサポートされました！ Amazon CloudFrontでポリシーによるレスポンスヘッダの追加が可能になりました。Lambda@EdgeやCloudFront Functionsを使うよりもよりもシンプルにレスポンスヘッダの挿入が可能かと思います。 はじめに 清水です。本日お伝えするアップデート情報はこちら、AWSのCDNサービスであるAmazon CloudFrontでResponse headers policiesがサポートされ、オリジンの変更やコードの記述なしでレスポンスにヘッダを追加することが可能になりました。日本時間本日（2021/11/03）早朝にポストされたアップデートになります。（現地時間では2021/11/02。） Amazon CloudFront now sup
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS再入門ブログリレー Amazon CloudFront 編 | DevelopersIO
Amazon CloudFront now supports HTTP/3 powered by QUIC
Amazon CloudFront のキャッシュ仕様についてあらためて調べてみた - michimani.net
Amazon CloudFront launches Origin Access Control (OAC)
Amazon CloudFront を活用したウェブサイトの可用性向上 | Amazon Web Services
Amazon CloudFrontがHTTP/3に対応しました | DevelopersIO
www.wp-benricho.com
approach.yahoo.co.jp
koubodatabase.com
www.fujimi-ya.com
currys.hatenablog.com
www.chadeau.com