最新情報

Amazon CloudFront で 3072 ビット RSA 証明書のサポートを発表

日付: 2023 年 7 月 14 日

Amazon CloudFront で 3072 ビット RSA 証明書のサポートが発表されました。お客様は、3072 ビット RSA 証明書を CloudFront ディストリビューションに関連付けることで、クライアントと CloudFront エッジロケーション間の通信セキュリティを強化できるようになりました。

RSA はデジタル証明書で広く使用されている暗号化アルゴリズムで、デジタル署名とデータ暗号化によってインターネット通信を保護します。今回の更新以前は、CloudFront のお客様が使用できるのは 1024 ビットまたは 2048 ビットの強度の RSA 証明書、または ECDSA P256 証明書に限られていました。ECDSA P256 証明書は、1024 ビットまたは 2048 ビットの RSA 証明書よりも優れたセキュリティを提供しますが、従来のクライアントやデバイスではサポートされない可能性があります。3072 ビット RSA 証明書の導入により、以前は ECDSA P256 証明書に限定されていたのと同じセキュリティレベルを CloudFront でも実現できるようになりました。

Amazon CloudFront の 3072 ビット RSA 証明書のサポートを、すぐに利用できるようになりました。最初に、コンソールまたは API を使用して 3072 ビット RSA 証明書を CloudFront ディストリビューションに関連付けます。この機能に関連する追加料金は発生しません。詳細については、CloudFront デベロッパーガイドを参照してください。CloudFront の詳細については、CloudFront 利用開始ページをご覧ください。

AWS がナイジェリアの新しいエッジロケーションを発表

日付: 2023 年 6 月 15 日

詳細:アマゾン ウェブ サービス (AWS) は、ラゴスに新しいエッジロケーションを立ち上げ、ナイジェリアでの事業拡大を発表しました。ナイジェリアのお客様は、新しいエッジロケーションを通じて配信されるデータについて、平均で最大 20% の遅延改善を期待できます。新しい AWS エッジロケーションは、高度に分散されたスケーラブルなコンテンツ配信ネットワーク (CDN) である Amazon CloudFront によりさまざまなメリットを提供します。これにより、静的および動的なコンテンツ、API、ライブおよびオンデマンドビデオの低レイテンシーかつ高性能な配信が利用可能になります。

Amazon CloudFront のすべてのエッジロケーションは、AWS Shield Standard によってインフラストラクチャレベルの DDoS 脅威から保護されています。AWS Shield Standard では、常時オンのネットワークフローモニタリングとインライン緩和機能を使用して、アプリケーションのレイテンシーとダウンタイムを最小限に抑えます。また、AWS WAF を有効にすることで、アプリケーションにセキュリティの追加レイヤーを加え、一般的なウェブエクスプロイトやボット攻撃からアプリケーションを保護することもできます。

このエッジロケーションから配信されるトラフィックは、アフリカのリージョンの料金が適用されます。AWS エッジロケーションの詳細については、CloudFront のエッジロケーションを参照してください。

Amazon CloudFront が、stale-while-revalidate および stale-if-error キャッシュ制御ディレクティブをサポート

日付: 2023 年 5 月 17 日

詳細: Amazon CloudFront は、パフォーマンスと可用性を向上させる、stale-while-revalidate および stale-if-error キャッシュ制御ディレクティブのサポートを発表しました。stale-while revalidate ディレクティブは、バックグラウンドでキャッシュを再検証している間に、ユーザーに古いレスポンスをただちに配信するよう CloudFront に指示します。stale-if-error ディレクティブは、エラーが発生した場合に CloudFront が古いレスポンスを再利用する時間を定義します。これにより、ユーザーエクスペリエンスが向上します。

stale-while-revalidate ディレクティブを使用すると、CloudFront は 480 以上のエッジロケーションからより高速な応答が可能となり、キャッシュヒット率を最大化してキャッシュ期限切れ後のパフォーマンスを向上させることができます。stale-whele-revalidate ディレクティブを使用すると、古いコンテンツはキャッシュから迅速に提供されるため、ユーザーはオリジンからの応答を待つ必要がなくなります。stale-while-revalidate は、頻繁に、または予期せず更新されるコンテンツや、再生にかなりの時間を要すコンテンツ、最新バージョンが必要ないコンテンツに適しています。stale-if-error ディレクティブは、オリジンがエラーを返したときに古いコンテンツを提供することで、ユーザーエクスペリエンスを向上させ、可用性を向上させます。 

これらのディレクティブのサポートは、追加費用なしですべての CloudFront エッジロケーションで利用できるようになりました。オリジンサーバーからディレクティブを定義すると、CloudFront はディレクティブに基づいて動作を処理します。詳細については、Amazon CloudFront デベロッパーガイドを参照してください。

Amazon CloudFront が S3 Object Lambda アクセスポイントオリジンをサポート

日付: 2023 年 4 月 5 日

詳細: 本日より、Amazon CloudFront で S3 Object Lambda アクセスポイントをオリジンとして使用できるようになりました。つまり、S3 Object Lambda アクセスポイントのエイリアスを使用して S3 バケットスタイルの CloudFront オリジンを設定できるようになり、CloudFront の 480 を超えるグローバルエッジロケーションを利用して、S3 Object Lambda 関数によって変換されたデータの配信を高速化できるようになりました。

S3 Object Lambda を使用すると、S3 GET、HEAD および LIST リクエストに独自のコードを追加して、データがアプリケーションに返されるときにデータを変更および処理することができます。今回のリリース以前は、オリジンでの認証には AWS Signature Version 4 (SigV4) の署名プリンシパルとして Lambda@Edge を使用する必要がありました。このたび、S3 Object Lambda アクセスポイントオリジンでの SigV4 認証の署名プリンシパルとして CloudFront を使用できるようになりました。これにより、CloudFront をより簡単に使用して、フィルターされた行、動的にサイズ変更された画像、機密情報が編集されたデータなど、S3 Object Lambda 関数によって変換されたデータの配信を高速化できます。

Amazon CloudFront の S3 Object Lambda アクセスポイントオリジンのサポートが世界中で利用可能になりました。利用を開始するには、S3 コンソールまたは API を使用して S3 Object Lambda アクセスポイントのエイリアスを取得し、CloudFront オリジンとして S3 バケットスタイルのドメインを作成します。この機能に関連する追加料金は発生しません。詳細については、CloudFront デベロッパーガイドを参照してください。CloudFront の詳細については、CloudFront 利用開始ページをご覧ください。

Amazon CloudFront は、CloudFront Functions を使用した HTTP ステータスとレスポンス生成のサポートを発表しました

日付: 2023 年 3 月 29 日

詳細: 本日より、CloudFront Functions を使用して、HTTP ステータスコードの変更やレスポンスの HTTP 本文の置き換えなど、視聴者へのレスポンスをさらにカスタマイズできるようになりました。CloudFront Functions は、軽量な HTTP 変換のために構築された CloudFront のサーバーレスエッジコンピューティング機能で、世界中の 450 以上の CloudFront エッジロケーションで実行されます。

以前、CloudFront Functions では、ヘッダーや Cookie などの HTTP リクエストとレスポンス属性を変換できました。今回のリリースで、CloudFront がオリジンサーバーまたはキャッシュから HTTP レスポンスを受け取ったときに、HTTP ステータスコードと HTTP 本文を上書きするように HTTP レスポンスを変更できます。たとえば、オリジンから返されたヘッダーを評価してリクエストをブロックするかどうかを判断する場合は、HTTP ステータスコードを 403 に変更し、レスポンスの HTTP 本文を削除できます。この機能を使用して、リクエストごとに HTTP 本文を生成することもできます。たとえば、リクエストを評価して、カスタマイズした Web ページで視聴者に応答できます。

詳細は、CloudFront デベロッパーガイドをご覧ください。この機能は追加料金なしで使用できます。CloudFront の使用を開始するには、CloudFront の開始方法をご覧ください。

Amazon CloudFront は、CloudFront Functions によるテストイベントの保存をサポートしています

日付: 2023 年 3 月 23 日

詳細: Amazon CloudFront では、CloudFront Functions のテストイベントを CloudFront コンソールに保存できるようになりました。この機能により、複数のテストイベントを作成して保存できるため、CloudFront Functions を構築する際のテストカバレッジが広がります。テストイベントを保存すると、開発時間を短縮でき、また CloudFront Functions をテストする際のオーバーヘッドも削減できます。

以前は、CloudFront Functions コンソールでは、関数を検証するためのテストイベントを 1 つしか設定できませんでした。これでは余分な手間がかかり、テストイベントを変更しているときに特定のテストケースをうっかり見逃してしまう可能性があります。また、テストイベントは CloudFront コンソールセッション中にのみ保存され、その後は新しいセッション用にテストイベントを再作成する必要があります。テストイベントを保存することで、関数ごとに複数のテストケースを作成し、後で使用できるように保存できるようになりました。既存の関数を変更して、テストイベントを手動で再作成しなくても、以前に保存したすべてのテストイベントに対してすばやくテストできるようになりました。

テストイベントを保存すると、CloudFront Functions コンソールで追加料金なしですぐに使用できます。詳細は、CloudFront Functions デベロッパーガイドをご覧ください。

AWS、ペルーに新しい Amazon CloudFront エッジロケーションを発表

日付: 2023 年 3 月 22 日

詳細: Amazon Web Services (AWS) は、リマに新しいエッジロケーションを立ち上げ、ペルーでの Amazon CloudFront の拡張を発表しました。ペルーのお客様は、新しいエッジロケーションを通じて配信されるデータのレイテンシーが平均で最大 50% 改善され、エンドユーザーが高速で応答性の高いアプリケーションを手にすることを期待できます。新しい AWS エッジロケーションは、
静的および動的コンテンツ、API、ライブおよびオンデマンドビデオを配信する高度に分散されたスケーラブルなコンテンツ配信ネットワーク (CDN) である Amazon CloudFront が提供するすべてのメリットをもたらします。Amazon CloudFront は、450 以上の Point of Presence (POPs) のグローバルネットワークと 49 か国の 90 以上の都市にある 13 のリージョンレベルのエッジキャッシュを使用して、エンドユーザーにコンテンツを配信しています。

Amazon CloudFront のすべてのエッジロケーションは、、インフラストラクチャレベルの DDoS 脅威に対して、
AWS Shield Standard は、常時ネットワークフロー監視とインラインミティゲーションにより、アプリケーションのレイテンシーとダウンタイムを最小化することで、DDoS の脅威を回避します。 また、AWS WAF を有効にすることで、アプリケーションにセキュリティの追加レイヤーを加え、一般的なウェブエクスプロイトやボット攻撃からアプリケーションを保護することもできます。

このエッジロケーションから配信されるトラフィックは、南米の
リージョン料金が含まれます。AWS エッジロケーションの詳細については、CloudFront のエッジロケーションを
参照してください。

Amazon CloudFront、オリジンリクエストポリシーにおけるブロックリストのサポートを発表

日付: 2023 年 2 月 22 日

詳細: Amazon CloudFront は、オリジンリクエストポリシーでブロックリストをサポートするようになりました。この機能により、ブロックリストを使用して特定の値を除外しながら、すべてのビューアーヘッダー、クッキー、クエリ文字列をオリジンに転送することができます。ブロックリストは、ビューアーリクエストデータをオリジンに転送する方法について、より柔軟性を提供します。

これまで、オリジンリクエストポリシーを使用して、オリジンに転送するビューアーヘッダー、クエリ文字列、およびクッキーを決定することができました。新しいブロックリスト機能を使用すると、ブロックリストで定義された値以外のすべてのビューアーの値を転送できるようになります。これにより、API Gateway など、ビューアーの Host ヘッダーの転送をサポートしないオリジンへのリクエストデータの転送が容易になります。さらに、ビューアーリクエストからすべての値 (ヘッダー、クッキー、クエリ文字列) を転送しますが、ビューアーリクエストから Host ヘッダーを含まない AllViewerExceptHostHeader 管理ポリシーをリリースしています。

オリジンリクエストポリシーにおけるブロックリストのサポートは、追加料金なしですぐに使用可能です。 この機能は、CloudFront コンソール、SDK、CLI で設定することができます。詳細は、CloudFront デベロッパーガイドをご覧ください。

AWS Lambda@Edge で Node 18.x のサポートを開始

日付: 2023 年 1 月 13 日

詳細: 本日より、Node.js 18.x ランタイムを使用して AWS Lambda@Edge で関数を開発できるようになりました。このランタイムは、現在サポートされている Node.js16x および Node.js14.x ランタイムに追加されます。

現在の LTS (長期サポート) 版 Node.js 18.x では、NODE_PATH を用いた ES モジュールの解決に対応し、ES モジュールの読み込みが容易になりました。さらに、Node.js 18.x では、クラスフィールドやプライベートクラスのメソッドのパフォーマンスを向上させる新しい言語機能、JSON インポートアサーション、Fetch API、Test Runner モジュール、Web Streams API などの実験的な機能が追加されています。 Node.js 18.x のメリットと新機能の詳細については、AWS 今ぴゅーティングブログの Node.js 18.x に関する発表の投稿をお読みください。

Node.js 18.x の使用を開始するには、AWS CLI または Lambda コンソールを介してコードを AWS Lambda にアップロードし、ランタイムとして Node.js 18.x を選択します。既存の Node.js 関数を Lambda にお持ちの場合は、新しいランタイムとの互換性を確保するために必要なコード変更を行った後、関数設定を編集してランタイムを Node.js 18.x に設定することで、新しいランタイムに切り替えることができます。

Lambda@Edge の詳細については、製品ページをご参照ください。AWS Lambda の Node.js プログラミングモデルの詳細については、AWS Lambda Node.js のドキュメントをお読みください。

Amazon CloudFront がレスポンスヘッダーの削除をサポート

日付: 2023 年 1 月 3 日

詳細: Amazon CloudFront では、レスポンスヘッダーポリシーを使用したレスポンスヘッダーの削除がサポートされるようになりました。これにより、お客様は CloudFront から提供された特定のヘッダーをネイティブに削除できるようになります。ヘッダーの追加とオーバーライドを行う既存機能に加えてこの新機能を使用することで、レスポンスヘッダーを柔軟にカスタマイズできます。

これまでは、レスポンスヘッダーポリシーを使用して、Amazon CloudFront がビューアーに送信するレスポンスに含める HTTP ヘッダー (CORS ヘッダー、セキュリティヘッダー、カスタムヘッダーなど) を指定できました。今回の対応により、レスポンスヘッダーポリシーを使用して、ビューアーに送信されるヘッダーを選択的に削除できるようになります。これにより、アプリケーションロジックや CDN 固有のキャッシュポリシーに必要であっても共有の必要はないヘッダーを非表示にできます。例えば、お客様のブログアプリケーションで「x-powered-by」ヘッダーを送信している場合、このヘッダーが表示されると、そのテクノロジーに関する特定の既知の脆弱性について攻撃者の標的になる可能性があります。これを防ぐために、レスポンスヘッダーポリシーを使用してレスポンスがビューアーに送信されないようにできます。さらに、オリジンが「Vary」ヘッダーを生成して、オリジンのレスポンスに影響を与えたヘッダーを示すこともありますが、この情報はビューアーには必要ない可能性があり、レスポンスヘッダーポリシーを使用して削除できます。

レスポンスヘッダーポリシーを使用したヘッダーの削除は、CloudFront コンソール、AWS SDK、AWS CLI から利用できます。この機能に関連する追加料金は発生しません。一部の HTTP ヘッダーは読み取り専用であるかアクセスができません。その場合は削除できない点に注意してください。削除できないヘッダーの詳細については、「エッジ関数に対する制限」をご覧ください。CloudFront の使用を開始するには、「CloudFront の製品ページ」をご覧ください。

Amazon CloudFront が継続的なデプロイのサポートを開始

日付: 2022 年 11 月 21 日

詳細: Amazon CloudFront は、継続的なデプロイをサポートするようになりました。これは、すべてのビューワーに変更をデプロイする前に、ライブトラフィックの一部を使用して設定の変更をテストおよび検証する新機能です。

CloudFront を使用した継続的デプロイにより、デプロイの安全性を高いレベルで実現します。ブルー、グリーンという 2 つの独立した同一環境をデプロイできるようになりました。また、ドメインネームシステム (DNS) を変更せずにリリースを段階的に展開する機能を使用して、継続的インテグレーションおよびデリバリー (CI/CD) パイプラインに簡単に統合できます。ビューワーセッションを同じ環境にバインドすることで、セッション維持機能によりビューワーが一貫した体験を得られるようにします。さらに、標準ログとリアルタイムログをモニタリングすることで、変更のパフォーマンスを比較できます。その変更がサービスに悪影響を与える場合は、以前の設定にすばやく戻すことが可能です。この機能の一般的な使用例としては、下位互換性のチェック、デプロイ後の検証、より小さなビューワーグループでの新機能の検証などがあります。

継続的デプロイのサポートは、CloudFront のすべてのエッジロケーションで追加料金なしで利用できます。この機能には CloudFront コンソール、SDK、コマンドラインインターフェイス、CloudFormation テンプレートからアクセスできます。この新機能の詳細については、開始についてのブログ、またはドキュメントをご覧ください。

Amazon CloudFront が JA3 フィンガープリントヘッダーのサポートを開始

日付: 2022 年 11 月 17 日

詳細: Amazon CloudFront が Cloudfront-viewer-ja3-fingerprint ヘッダーのサポートを開始しました。これにより、受信したビューワーリクエストの JA3 フィンガープリントへアクセスできるようになりました。JA3 フィンガープリントを利用してカスタムロジックを実装し、悪意のあるクライアントをブロックしたり、想定されるクライアントからの要求のみを許可したりすることができます。

Cloudfront-viewer-ja3-fingerprint (JA3 フィンガープリント) ヘッダーには、受信したビューワーリクエストの TLS Client Hello パケットの 32 文字から成るハッシュ値のフィンガープリントが含まれます。フィンガープリントでは、クライアントの通信方法および同じパターンを持つクライアントのプロファイリングに使用できる方法についての情報を要約します。Cloudfront-viewer-ja3-fingerprint ヘッダーをオリジンリクエストポリシーに追加したり、そのポリシーを CloudFront ディストリビューションにアタッチしたりすることができます。そしてオリジンアプリケーション、または Lambda@Edge や CloudFront Functions でヘッダーの値を調査したり、ヘッダーの値を既知のマルウェアに関するフィンガープリントのリストと比較して悪意のあるクライアントをブロックしたりすることができます。また、想定されるフィンガープリントのリストとヘッダーの値を比較して、想定されるフィンガープリントを持つリクエストのみを許可することもできます。

Cloudfront-viewer-ja3-fingerprint ヘッダーは、すべての CloudFront エッジロケーションですぐにご利用いただけます。CloudFront コンソールで、または AWS SDK を利用して JA3 フィンガープリントヘッダーを有効にできます。JA3 フィンガープリントヘッダーの使用に追加料金はかかりません。詳細については、CloudFront デベロッパーガイドを参照してください。

Amazon CloudFront、リアルタイムログにオリジンレイテンシーと ASN のフィールドを追加し、よりきめ細かいインサイトを実現

日付: 2022 年 10 月 20 日

詳細: Amazon CloudFront は、CloudFront のリアルタイムログに 3 つのデータフィールドを追加しました。Origin first-byte latency、Origin last-byte latency、AS 番号 (ASN) です。CloudFront のリアルタイムログには、応答の HTTP ステータスコードやキャッシュの有無など、CloudFront が配信したリクエストに関する詳細な情報が含まれています。3 つの新しいデータフィールドにより、お客様はリアルタイムログを分析したり、ログを使用して作成したダッシュボードで、CloudFront のパフォーマンスに関するより詳細なインサイトを得ることができます。Origin first-byte latency は、オリジンサーバーが最初のバイトを返すまでの応答時間を秒単位で示したものです。Origin last-byte latency は、オリジンサーバーが最後のバイトを返すまでの応答時間を秒単位で示したものです。ASN は、視聴者 IP アドレスを提供するインターネットサービスプロバイダー (ISP) ネットワークなどのネットワークを識別するための固有の番号です。これらの新しいフィールドは、CloudFront コンソール、SDK、および CLI を介して有効にできます。リアルタイムのログに加えて、CloudFront のオリジンリクエストポリシーを設定して、CloudFront-Viewer-ASN ヘッダーをオリジンサーバーに転送することも可能です。詳細については、CloudFront デベロッパーガイドと API ドキュメントを参照してください。 

ベトナムで Amazon CloudFront の提供を開始

日付: 2022 年 8 月 29 日

詳細: Amazon CloudFront は、ベトナムのハノイとホーチミン市に初のエッジロケーションを発表しました。これらの新しいエッジロケーションを利用するビューワーは、最初のレイテンシーで、最大 30% の改善を期待できます。この 2 つの場所の追加により、CloudFront のグローバルネットワークは、48 か国の 90 以上の都市、410 以上のポイントにまで広がりました。

レイテンシーを削減するだけでなく、これらのエッジロケーションは Lambda@Edge、Field Level Encryption、Amazon S3 Transfer Acceleration などの Amazon CloudFront が提供する一連の利点および AWS Certificate Manager (ACM)、AWS Shield、AWS WAF、AWS Simple Storage Service (S3)、Amazon Elastic Compute Cloud (EC2) などのその他 AWS 製品とのシームレスな統合も提供します。これらハノイとホーチミン市の新しいエッジロケーションは、最高機密データのセキュアな配信を確保するために PCI、DSS、HIPAA、ISO のすべてに準拠したインフラストラクチャとプロセスを含む世界中にある他の CloudFront エッジロケーションと同じ高い基準に従って構築されています。

これらのエッジロケーションで提供されるトラフィックには、アジアパシフィックリージョンの料金が適用されます。 AWS エッジロケーションの詳細については、CloudFront のエッジロケーションについての説明を参照してください。

Amazon CloudFront でオリジンアクセスコントロール (OAC) をリリース

日付: 2022 年 8 月 25 日

詳細: Amazon CloudFront では、オリジンアクセスコントロールの提供を開始します。これは、指定の CloudFront ディストリビューションにのみ S3 バケットへのアクセスを許可することによって、CloudFront のお客様が S3 オリジンを簡単に保護できるようにする新機能です。S3 バケットへの CloudFront のリクエストで AWS Signature Version 4 (SigV4) を有効にして、CloudFront がリクエストに署名するタイミング/条件を設定できるようになりました。また、CloudFront を介してアップロードとダウンロードを実行する際、SSE-KMS を使用できるようになりました。

これまでは、Origin Access Identity を使用して、S3 オリジンへのアクセスを CloudFront に制限することに限定されていました。オリジンアクセスコントロールはセキュリティを強化し、機能の統合を深めることで、オリジンアクセスアイデンティティを改善します。Origin Access Identity と比較して、オリジンアクセスコントロールは短時間のみ有効な認証情報およびより頻度の高い認証のローテーションによって、セキュリティ体制をより強化します。オリジンアクセスコントロールで、リソースベースのポリシーによってきめ細かなポリシーを設定でき、混乱する代理攻撃に対するより強い保護が提供されます。オリジンアクセスコントロールを使用してデータを取得し、SigV4 を必要とするリージョンの S3 オリジンに格納できます。また、オリジンアクセスコントロールによって S3 オリジンの SSE-KMS を使用できます。Origin Access Identity では、これはできませんでした。

CloudFront は新しいオリジンアクセスコントロールとこれまでのオリジンアクセスアイデンティティの両方をサポートします。オリジンアクセスアイデンティティを使用するよう設定されている配信がある場合、ほんの数クリックで簡単にオリジンアクセスコントロールに配信を移行できます。Origin Access Identity を使用する配信は引き続き機能し、新しい配信に Origin Access Identity を従来どおり使用できます。近日発表されるリージョンの制限については、CloudFront オリジンアクセス移行のドキュメントをご覧ください。 

現在、CloudFront オリジンアクセスコントロールは AWS 中国リージョンを除く世界中で利用可能です。オリジンアクセスコントロールは CloudFront コンソール、API、SDK、CLI から使用を開始できます。オリジンアクセスコントロールの使用にあたり追加料金はかかりません。オリジンアクセスコントロールの設定方法については、CloudFront オリジンアクセスコントロールのドキュメントをご覧ください。CloudFront の使用を開始するには、CloudFront の製品ページにアクセスしてください。

Amazon CloudFront が QUIC を利用した HTTP/3 のサポートを開始

日付: 2022 年 8 月 15 日

詳細: Amazon CloudFront は、エンドユーザー接続のために QUIC を介した HTTP バージョン 3 (HTTP/3) リクエストをサポートするようになりました。HTTP/3 は、ユーザーデータグラムプロトコル (UDP) ベースのストリーム多重化された安全なトランスポートプロトコルである QUIC を使用します。これは、既存の伝送制御プロトコル (TCP)、TLS、および HTTP/2 の機能を組み合わせ、改善するものです。HTTP/3 には、応答時間の短縮、セキュリティの向上など、以前の HTTP バージョンを上回るいくつかの利点があります。

顧客が常に求めているのは、より高速で安全なアプリケーションをユーザーに提供することです。インターネットの普及率が世界的に高まり、モバイルやリモートネットワークからオンラインにアクセスするユーザーが増えるのに伴って、パフォーマンスと信頼性の向上に対するニーズがこれまで以上に高まっています。HTTP/3 は、以前の HTTP バージョンよりも改善されており、接続時間を短縮し、ヘッドオブラインブロッキングを排除することで、パフォーマンスとエンドビューワーのエクスペリエンスを向上させるのに役立ちます。CloudFront の HTTP/3 サポートは、Rust での新しいオープンソース QUIC プロトコル実装である s2n-quic の上に構築されており、効率とパフォーマンスに重点が置かれています。CloudFront の HTTP/3 実装はクライアント側の接続の移行をサポートしており、クライアントアプリケーションでは、Wifi からセルラーへの移行や永続的なパケット損失などの問題のあるイベントが発生している接続を、最小限の中断または中断なしの状態で回復させることができます。さらに、HTTP/3 では TLS ハンドシェイクパケットを暗号化する QUIC がデフォルトで使用されるため、高度なセキュリティが得られます。CloudFront の利用者が配信で HTTP/3 を有効にした場合、最初の 1 バイトを受信するまでの時間が最大 10% 改善され、ページのロード時間が最大 15% 改善されました。また、配信で HTTP/3 を有効にした場合、ハンドシェイクの失敗が減少するため、信頼性も向上することが確認されています。

配信で HTTP/3 を有効にするには、CloudFront コンソール、UpdateDistribution API アクション、または CloudFormation テンプレートを使用して配信設定を編集します。HTTP/3 をサポートしていないクライアントでも、以前の HTTP バージョンを使用して、HTTP/3 対応の Amazon CloudFront 配信と通信できます。

HTTP/3 は、世界中の 410 以上の CloudFront エッジロケーションすべてで利用できるようになりました。この機能を使用するための追加料金はありません。Amazon CloudFront HTTP/3 の詳細については、CloudFront デベロッパーガイドを参照してください。Amazon CloudFront の詳細については、Amazon CloudFront 製品ページを参照してください。

Amazon CloudFront が CloudFront ポリシーで最大 1024 文字までのヘッダー名をサポート

日付: 2022 年 7 月 11 日

詳細: Amazon CloudFront では、キャッシュポリシー、オリジンリクエストポリシー、オリジンレスポンスポリシーにおけるすべてのヘッダー名について、最大 1024 文字がサポートされるようになりました。512 文字が追加され、最大 1024 文字まで使用できるようになったことで、ヘッダーメタデータをポリシーに追加できるようになりました。

CloudFront ポリシーを使用することで、多くの配信動作に対して特定の同じ設定の組み合わせを適用できます。これまでは、CloudFront またはポリシー内のカスタムヘッダー名として、最大 512 文字まで追加することができました。文字数の上限が引き上げられたことにより、キャッシュポリシーにヘッダーを追加することで、よりきめ細やかなキャッシュキーを設定したり、ユーザー認証を実装するための入力として追加のヘッダーを活用したりすることができるようになりました。ヘッダーはすべて、Lambda@Edge、CloudFront Functions、または Origin のアプリケーションロジックで利用可能です。

すべてのヘッダー名における文字数の増加は、世界中ですぐに利用可能です。この機能の使用に追加料金は発生しません。お客様は、これまでと同様に、CloudFront コンソール、API、SDK、CLI を使用してポリシー内でヘッダーを設定できます。詳細については、CloudFront デベロッパーガイドと API ドキュメントを参照してください。

Amazon CloudFront がビューワー接続のために TLS 1.3 セッション再開のサポートを開始

日付: 2022 年 6 月 7 日

詳細: Amazon CloudFront は、ビューワー接続のパフォーマンスをさらに改善するため、Transport Layer Security (TLS) 1.3 セッション再開をサポートするようになりました。これまで、Amazon CloudFront は、ビューワーと CloudFront 間の HTTPS 通信を暗号化するために、2020 年から TLS プロトコルのバージョン 1.3 をサポートしてきました。このプロトコルを採用したお客様は、以前の TLS バージョンと比較して、接続パフォーマンスが最大 30% 改善されました。本日より、TLS 1.3 を使用するお客様は、TLS 1.3 セッション再開のおかげで、パフォーマンスを最大 50% 改善できます。セッション再開では、以前に TLS 接続を行っていたサーバーにクライアントが再接続すると、サーバーはクライアントによって送信された事前共有キーを使用してセッションチケットを復号し、セッションを再開します。TLS 1.3 セッション再開は、サーバーとクライアントの両方の計算オーバーヘッドを削減するため、セッションの確立を高速化します。また、完全な TLS ハンドシェイクと比較して、転送する必要のあるパケットが少なくなります。

TLS セッション再開は、TLS 1.3 を使用しているお客様のために自動的に有効になります。お客様は、TLS 1.3 セッション再開のパフォーマンスの改善のメリットを享受するために、CloudFront デプロイに追加の変更を加える必要はありません。アプリケーションが古いバージョンの OpenJDK を使用している場合は、最新の安定した OpenJDK バージョンを使用するように更新することをお勧めします。古い OpenJDK は、クライアントがセッション再開の実行を試みる際に接続の問題を引き起こす可能性があるためです。JDK パッチの詳細については、OpenJDK のバグページとバグの軽減に関するブログをご覧ください。

ビューワーと CloudFront 間でサポートしているプロトコルと暗号の詳細については、CloudFront デベロッパーガイドを参照してください。Amazon CloudFront の詳細については、Amazon CloudFront 製品ページを参照してください。

Amazon CloudFront が、CloudFront-Viewer-TLS-header で TLS バージョンと暗号スイートの提供を開始

日付: 2022 年 5 月 23 日

詳細: CloudFront が、オリジンリクエストポリシーで使用するために CloudFront-Viewer-TLS ヘッダーを提供するようになりました。CloudFront-Viewer-TLSは、ビューアのTLS接続のネゴシエーションに使用されるTLSバージョンと暗号スイートを含む HTTP ヘッダーです。従来は、TLS 情報は、以前のリクエストを分析するために CloudFront アクセスログで利用可能でした。これで、各 HTTP リクエストの TLS バージョンと暗号スイートにアクセスして、古い TLS バージョンでリクエストを制限するなどのリアルタイムの決定を行うことができるようになります。CloudFront-Viewer-TLS ヘッダー値は次の構文を使用します。例えば、TLSv1.2:ECDHE-RSA-AES128-SHA256 です。 

CloudFront-Viewer-TLS ヘッダーを設定するには、CloudFront オリジンリクエストポリシーに含めて、オリジンに転送します。設定すると、CloudFront Functions および Lambda@Edge から Cloudfront-Viewer-TLS ヘッダーにアクセスして、エッジでのアクセスの制限などの機能を実行することもできます。 

Cloudfront-Viewer-TLS ヘッダーは、Sinnet 運営の Amazon Web Services 中国 (北京) リージョンと NWCD 運営の Amazon Web Services 中国 (寧夏) リージョンを除く、すべてのリージョンで利用可能となっています。このヘッダーは追加料金なしで使用できます。Cloudfront-Viewer-TLS ヘッダーの使用方法については、CloudFront デベロッパーガイドをご覧ください。オリジンポリシーでサポートされているユースケースの詳細については、このブログにアクセスしてください。Amazon CloudFront の詳細については、CloudFront 製品ページを参照してください。

Amazon CloudFront がサーバータイミングヘッダーをサポートするようになりました。

日付: 2022 年 3 月 31 日

詳細: 本日より、CloudFront ディストリビューションを設定して、CloudFront の動作とパフォーマンスを監視するサーバータイミングヘッダーを含めることができます。サーバータイミングヘッダーは、リクエストの受信時にコンテンツがキャッシュから提供されたかどうか、リクエストが CloudFront エッジロケーションにルーティングされた方法、接続およびレスポンスプロセスの各ステージで経過した時間などの詳細なパフォーマンス情報を提供します。 

サーバータイミングヘッダーは、ビューワーのレスポンスに HTTP ヘッダーの形式で追加のメタデータを提供し、クライアント側のアプリケーションコードで検査または使用することができます。サーバータイミングヘッダーを使用して、CloudFront のパフォーマンスをトラブルシューティングする際のより詳細なインサイトを取得し、CloudFront の動作を検査し、キャッシュミス、最初のバイトのレイテンシー、最後のバイトのレイテンシーなど、ユーザーがリクエストしたトランザクション全体のメトリクスを収集および集約することができます。

サーバータイミングヘッダーは、すべての CloudFront エッジロケーションですぐに使用できます。サーバータイミングヘッダーは、CloudFront コンソールまたは AWS SDK を介して有効化できます。サーバータイミングヘッダーを使用するための追加料金はありません。詳細については、CloudFront デベロッパーガイドを参照してください。 

Amazon CloudFront がマネージドプレフィックスリストのサポートを開始

日付: 2022 年 2 月 7 日

詳細: 本日より、Amazon CloudFront の AWS マネージドプレフィックスリストを使用して、CloudFront のオリジンに面したサーバーに属する IP アドレスのみからのオリジンへのインバウンド HTTP/HTTPS トラフィックを制限できます。CloudFront が、マネージドプレフィックスリストを CloudFront のオリジンに面したサーバーの IP アドレスで最新の状態に保つので、プレフィックスリストを自分で管理する必要がなくなります。

CloudFront のマネージドプレフィックスリストは、Amazon Virtual Private Cloud (VPC) セキュリティグループルール、サブネットルートテーブル、AWS Firewall Manager との共通セキュリティグループルール、およびマネージドプレフィックスリストを使用できるその他の AWS リソースで参照できます。例えば、VPC セキュリティグループのインバウンドルールで CloudFront のマネージドプレフィックスリストを使用して、CloudFront IP アドレスのみが EC2 インスタンスにアクセスできるようにすることができます。AWS Firewall Manager の共通のセキュリティグループルールでマネージドプレフィックスリストを使用する場合、すべての AWS アカウントで複数の Application Load Balancers (ALB) へのアクセスに制限することができます。詳細については、AWS マネージドプレフィックスリストをご覧ください。

マネージドプレフィックスリストは、中国、アジアパシフィック (ジャカルタ)、アジアパシフィック (大阪) を除くすべてのリージョンで、AWS コンソールおよび AWS SDK を介してすぐに使用できます。プレフィックスリストは、利用可能なリージョンの CloudFormation テンプレートで参照できます。CloudFront のマネージドプレフィックスリストを利用するための追加料金はありません。詳細については、CloudFront デベロッパーガイドをご覧ください。

Amazon CloudFront が設定可能な CORS、セキュリティ、およびカスタム HTTP レスポンスヘッダーをサポート

日付: 2021 年 11 月 2 日

詳細: 本日、Amazon CloudFront がレスポンスヘッダーポリシーのサポートを開始します。CloudFront ディストリビューションが返す HTTP レスポンスに、CORS (cross-origin resource sharing)、セキュリティ、およびカスタムヘッダーを追加できるようになりました。これらのヘッダーを挿入するために、オリジンを設定したり、Lambda@Edge や CloudFront のカスタム機能を使用する必要はもうありません。

CloudFront のレスポンスヘッダーのポリシーを利用して、アプリケーションの通信を保護したり、動作をカスタマイズしたりすることができます。CORS ヘッダーでは、ウェブアプリケーションがリソースにアクセスできるオリジンを指定することができます。ウェブアプリケーションとサーバーの間でセキュリティ関連の情報を交換するために、以下のいずれかのセキュリティヘッダーを挿入することができます: HTTP Strict Transport Security (HSTS)、X-XSS-Protection、X-Content-Type-Options、X-Frame-Options、Referrer-Policy、Content-Security-Policy などです。たとえば、HSTS は、平文の HTTP ではなく、暗号化された HTTPS 接続の使用を強制します。また、レスポンスヘッダーポリシーを使用して、カスタマイズ可能なキーバリューペアをレスポンスヘッダーに追加し、ウェブアプリケーションの動作を変更することもできます。挿入したレスポンスヘッダーは、Lambda@Edge 機能や CloudFront の機能からもアクセスできるため、エッジでより高度なカスタムロジックが可能になります。

今回のリリースでは、CloudFront はいくつかの事前設定されたレスポンスヘッダーポリシーも提供しています。これには、デフォルトのセキュリティヘッダーのポリシー、あらゆるオリジンからのリソース共有を許可する CORS ポリシー、すべての HTTP メソッドを許可するプレフライト CORS ポリシー、デフォルトのセキュリティヘッダーと CORS またはプレフライト CORS を組み合わせたポリシーなどがあります。また、さまざまなコンテンツやアプリケーションのプロファイルに対応した独自のカスタムポリシーを作成し、似たような特徴を持つ CloudFront ディストリビューションのキャッシュ動作に適用することもできます。

CloudFront のレスポンスヘッダーポリシーは、CloudFront コンソール、AWS SDK、AWS CLI ですぐに使用することができます。詳細は、CloudFront デベロッパーガイドをご覧ください。CloudFront のレスポンスヘッダーポリシーを利用するための追加料金はありません。

Amazon CloudFront はクライアント IP アドレスと接続ポートヘッダーのサポートを追加

日付: 2021 年 10 月 25 日

詳細: Amazon CloudFront は、リクエストするクライアントの IP アドレスと接続ポート情報を含む CloudFront-Viewer-Address ヘッダーを提供するようになりました。接続ポートフィールドは、リクエスト元のクライアントが使用する TCP ソースポートを示します。これまで、IP アドレスやクライアントの接続ポートの情報は CloudFront のアクセスログでのみ利用可能であったため、これらのデータに基づいて問題を解決したり、リアルタイムに意思決定したりすることは困難でした。CloudFront-Viewer-Address ヘッダーをオリジンサーバーに転送するように、CloudFront のオリジンリクエストポリシーを設定することができるようになりました。また、ヘッダーがオリジンリクエストポリシーに含まれている場合、CloudFront Functions で使用することができます。CloudFront-Viewer-Address ヘッダーは次の構文を使用します。CloudFront-Viewer-Address: 127.0.0.1:4430

CloudFront-Viewer-Address ヘッダーは追加料金なしで提供されます。ヘッダーは、他の CloudFront ヘッダーとともに、分析、監査、ロギングなどの目的で使用することができます。CloudFront-Viewer-Address ヘッダーの使用方法については、CloudFront デベロッパーガイド をご覧ください。キャッシュとオリジンリクエストポリシーの詳細については、ブログをご覧ください。Amazon CloudFront の詳細については、CloudFront 製品ページをご参照ください。

AWS Lambda@Edge で Python 3.9 のサポートを開始

日付: 2021 年 9 月 22 日

詳細: 本日より、Lambda@Edge で Python 3.9 を使用して関数を開発できるようになりました。このランタイムは、現在サポートされている Python 3.8 に加えて提供されます。

Python 3.9 は、Python 言語の最新リリースであり、パフォーマンスの改善や、文字列の接頭辞や接尾辞を削除する新しいメソッド、辞書の新しい演算子などの機能が含まれています。Python 3.9 の利点や新機能の詳細は、AWS Python 3.9 についてのブログ記事にてご確認ください。

これらの新しいランタイムの使用を開始するには、AWS CLI または Lambda コンソールから Python のコードを AWS Lambda 関数としてアップロードし、ランタイムとして Python 3.9 を選択します。既存の Python 関数を Lambda にお持ちの場合は、新しいランタイムとの互換性を確保するために必要なコード変更を行った後、関数設定を編集してランタイムを Python 3.9 に設定することで、新しいランタイムに切り替えることができます。

Lambda@Edge の詳細については、製品ページを参照してください。Lambda の Python プログラミングモデルの詳細については、AWS Python ドキュメントをご覧ください。 

Amazon CloudFront がビューワーに対する HTTPS 接続のための ECDSA 証明書のサポートを開始

日付: 2021 年 7 月 14 日

詳細: 本日より、Elliptic Curve Digital Signature Algorithm (ECDSA) P256 証明書を使って、ビューワーと Amazon CloudFront 間で HTTPS 接続をネゴシエートできるようになりました。NIST に記載のとおり、ECDSA 証明書は、RSA より小さいキーサイズで、同等のセキュリティ強度を提供できます。その結果、ECDSA 証明書を使用して TLS ハンドシェイクを実行する場合、必要になるネットワークリソースとコンピューティングリソースの量が減り、ストレージと処理能力に制限のある IoT デバイスにおいて、より良いオプションとなります。

AWS Certificate Manager (ACM) または AWS Identity and Access Management (IAM) のいずれかに証明書をインポートしたあと、CloudFront ディストリビューションを設定して ECDSA 認定書を使用できます。ビューワーの接続のために CloudFront で ECDSA 証明書を使用するには、曲線が P256 (prime256v1) であることが不可欠です。どの ECDSA 暗号がサポートされているかについては、CloudFront デベロッパーガイドでビューワーと CloudFront との間でサポートされているプロトコルと暗号をご参照ください。CloudFront ディストリビューションで ECDSA P256 証明書を使用する際に、料金の追加はありません。CloudFront の開始方法ページにアクセスして、CloudFront の使用を開始してください。

Amazon CloudFront が代替ドメイン名 (CNAME) を見つけて移動するための新しい API を発表

日付: 2021 年 7 月 8 日

詳細: Amazon CloudFront は、ListConflictingAliases と AssociateAlias という 2 つの新しい API を発表しました。これらは、CNAMEAlreadyExists エラーコードが発生した場合に代替ドメイン名 (CNAME、Alternate Domain Names) を見つけて移動するのに役立ちます。これらの新しい API を使用すると、ソースディストリビューションが同じアカウントにある場合、または別のアカウントのソースディストリビューションが無効になっている場合に限り、どのディストリビューションに CNAME があるかを確認し、CNAME をターゲットディストリビューションに移動できます。ソースディストリビューションがまだ有効になっているアカウント間で CNAME を移動するには、AWS Support に連絡して次の手順を実行する必要があります。

ListConflictingAliases API を使用することで、特定のサブドメインまたはワイルドカードのいずれかで特定の CNAME を識別し、その CNAME に一致または重複する CNAME のリストを受け取ることができます。API は、フォローアップ調査を容易にするために、各 CNAME が配置されているディストリビューション ID とアカウント ID についての対応する (ただし部分的に難読化された) 情報も返します。AssociateAlias API を使用すると、2 つのディストリビューションが同じアカウントにあるか、ソースディストリビューションが無効になっている限り、特定の CNAME をターゲットディストリビューションに移動できます。これらの API のいずれかを使用するには、呼び出しが成功するためにドメイン検証チェックに合格する必要があります。詳細については、CloudFront デベロッパーガイドの代替ドメイン名を別のディストリビューションに移動するを参照してください。

さらに、これらの API のリリースと 2019 年 4 月のドメイン検証の導入により、CloudFront は、クロスアカウントワイルドカード CNAME 関係するシナリオで CNAMEAlreadyExists エラーコードを返さなくなりました。例えば、アカウント A のディストリビューションに *.example.com などのワイルドカード CNAME を設定し、アカウント B のディストリビューションに test.example.com などの特定のサブドメインを設定できるようになりました。

Amazon CloudFront がビューワー接続用の新しい TLSv1.2_2021 セキュリティポリシーを発表

日付: 2021 年 6 月 23 日

詳細: Amazon CloudFront は、以下の CBC ベースの暗号を削除した TLSv1.2_2021 という新しいセキュリティポリシーを提供するようになりました。

• ECDHE-RSA-AES128-SHA256
• ECDHE-RSA-AES256-SHA384

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305
  

インドとアジアパシフィックリージョンでの Amazon CloudFront の値下げを発表

日付: 2021 年 5 月 6 日

詳細: Amazon CloudFront では、インターネットへのリージョン内データ転送アウト料金が、インドで最大 36%、アジアパシフィックリージョン (香港、インドネシア、フィリピン、シンガポール、韓国、台湾、タイ) で最大 26% の値下げになります。2021 年 5 月 1 日より、CloudFront の新価格がこれらのリージョンで適用されます。更新された CloudFront のオンデマンド料金は、CloudFront の料金ページで確認できます。

Amazon CloudFront が軽量エッジコンピューティング機能である CloudFront Functions を発表

日付: 2021 年 5 月 3 日

詳細: Amazon CloudFront は、新しいサーバーレスエッジコンピューティング機能である CloudFront Functions の一般提供を発表しました。この新しい CloudFront 機能を使用して、47 か国 90 都市にある 225 以上の CloudFront エッジロケーションで JavaScript 関数を実行できます。CloudFront Functions は、軽量の HTTP(S) 変換と操作用に構築されており、よりリッチでパーソナライズされたコンテンツを低レイテンシーで顧客に配信できます。

CloudFront Functions は、すべてのリクエストで実行できる軽量の CloudFront CDN カスタマイズに最適で、HTTP ヘッダー操作、URL の書き換え/リダイレクト、キャッシュキーの正規化などの大規模でレイテンシーに敏感な操作を可能にします。例えば、CloudFront Functions を使用して、受信リクエストの Accept-Language ヘッダーに基づいて、サイトの言語固有のバージョンにリクエストを書き換えることができます。CloudFront Functions を使用してカスタムトークンを検証し、受信リクエストを承認することもできます。これらの関数は CloudFront のすべてのエッジロケーションで実行されるため、レイテンシーのオーバーヘッドを最小限に抑えながら、1 秒あたり数百万のリクエストに即座にスケールできます。

CloudFront Functions は CloudFront にネイティブに組み込まれているため、CloudFront 内でビューワーリクエストおよびビューワーレスポンス関数を簡単に構築、テスト、デプロイできます。GitHub リポジトリでは、関数を構築するための開始点として使用できる一連のコードを提供しており、使用の開始を簡単にしています。IDE を使用して CloudFront コンソールで、または CloudFront API/CLI から関数を構築できます。コードを記述したら、CloudFront ディストリビューションに対して関数をテストして、デプロイ後に確実に正しく実行されるようにできます。コンソールのテスト機能は、JSON の編集を必要とせずに、テストイベントをすばやく作成するためのビジュアルエディタを提供します。

CloudFront イベントへの対応としてカスタムコードを実行できる既存の AWS Lambda@Edge 機能に加えて、CloudFront Functions を使用できます。サーバー側のレンダリングや画像の最適化など、計算量の多いオリジンのリクエストとレスポンスオペレーションには、引き続き Lambda@Edge を使用すべきです。

CloudFront Functions の料金は、100 万回の呼び出しあたり 0.1 USD です。料金の詳細については、CloudFront の料金ページにアクセスしてください。CloudFront Functions の詳細については、CloudFront Functions のリリースブログ、CloudFront デベロッパーガイド、または特徴に関するよくある質問をご覧ください。

AWS Lambda@Edge で Node 14.x のサポートを開始

日付: 2021 年 4 月 29 日

詳細: 本日より、Node.js 14.x ランタイムを使用して AWS Lambda@Edge で関数を開発できるようになりました。このランタイムは、現在サポートされている Node.js10.x および Node.js12.x ランタイムに追加されます。

Node.js 14.x は最新の Long Term Support (LTS) バージョンの Node.js で、新しい V8 8.1 エンジンを使用しています。また、以前の LTS バージョンである 12.x と比較してパフォーマンスが向上しています。さらに、Node.js 14.x は、nullish 合体 (?? 演算子)、オプションチェーン (?. 演算子)、診断レポートなどの新機能をサポートしています。Node.js 14.x のメリットと新機能の詳細については、AWS 今ぴゅーティングブログの Node.js 14.x に関する発表の投稿をお読みください。

Node.js 14.x の使用を開始するには、AWS CLI または Lambda コンソールを介してコードを AWS Lambda にアップロードし、ランタイムとして Node.js 14.x を選択します。既存の Node.js 関数を Lambda にお持ちの場合は、新しいランタイムとの互換性を確保するために必要なコード変更を行った後、関数設定を編集してランタイムを Node.js 14.x に設定することで、新しいランタイムに切り替えることができます。

Lambda@Edge の詳細については、製品ページをご参照ください。AWS Lambda の Node.js プログラミングモデルの詳細については、AWS Lambda Node.js のドキュメントをお読みください。

Amazon CloudFront が米国西部 (北カリフォルニア) リージョンの新しい Regional Edge Cache を発表

日付: 2021 年 4 月 8 日

詳細: Amazon CloudFront は、米国西部 (北カリフォルニア) における新しい Regional Edge Cache (REC) を発表します。今回のリリースの一環として、これまではオレゴンの REC を介してオリジンリクエストを送信していたいくつかの CloudFront Edge ロケーションが、北カリフォルニアの REC を介してリクエストを送信するようになります。  これらのエッジロケーションは、北カリフォルニアに近いため、または北カリフォルニアへの直接接続が多いため、オレゴンの REC と比較して、カリフォルニアの REC からコンテンツを取得する際のレイテンシーが 60% も削減されます。

CloudFront は現在、世界中で 13 のリージョン別エッジキャッシュを運用しています。これらは、CloudFront のエッジロケーションとオリジンの間に配置された中間層キャッシュレイヤーとして機能します。これらの中間層キャッシュは、コンテンツをより長期間保持するための増分キャッシュ幅を提供し、オリジンのトラフィックスパイクからの保護を強化します。すべての Regional Edge Cache と同様に、北カリフォルニアのロケーションは無料で提供され、CloudFront ディストリビューション向けにデフォルトで自動的に含まれます。CloudFront の Regional Edge Cache を利用するために設定を変更する必要はありません。

各 Regional Edge Cache のロケーションなど、CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront の主な機能のページにアクセスしてください。

AWS Lambda@Edge が請求時間単位を 50 ミリ秒から 1 ミリ秒に変更

日付: 2021 年 3 月 31 日

詳細: Amazon CloudFront では、Lambda@Edge 関数期間の請求時間単位を 50 ミリ秒から 1 ミリ秒に短縮されました。これにより、ほとんどの Lambda@Edge 関数の料金を抑えることができるようになりました。このことは、短期間の関数の場合により良く当てはまります。計算期間は、これまでのように呼び出しごとに最も近い 50 ミリ秒の単位に切り上げられるのではなく、呼び出しごとに 1 ミリ秒の単位で請求されます。

ヘッダー操作や URL 書き換えなどの軽量関数は、期間が短い傾向があります。この変更により、Lambda@Edge でこれらの関数を実行する方がさらに費用対効果が高くなります。例えば、平均 10 ミリ秒で実行される関数は、50 ミリ秒で請求されていました。今後は、その関数は 10 ミリ秒で請求され、その結果、期間に対する支出が 80% 削減されます。この変更は、4 つの Lambda@Edge イベントトリガー (ビューワーリクエスト、ビューワーレスポンス、オリジンリクエスト、オリジンレスポンス) すべてに適用されます。この変更は、2021 年 4 月 1 日から有効になります。詳細については、CloudFront の料金のページをご覧ください。

インドネシアでの Amazon CloudFront の提供を開始

日付: 2021 年 3 月 23 日

詳細: インドネシアのジャカルタに初となる Amazon CloudFront エッジロケーションが発表されました。この新しいエッジロケーションを利用するビューワーは、最初のレイテンシーで、最大 30% の改善を期待できます。このエッジロケーションで提供されるトラフィックには、CloudFront のアジアパシフィックリージョンの料金が適用されます。CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront インフラストラクチャをご覧ください。

クロアチアで Amazon CloudFront の提供を開始

日付: 2021 年 2 月 9 日

詳細: ザグレブ (クロアチア) で Amazon CloudFront のエッジロケーションの提供が開始されました。このザグレブの新しいエッジロケーションは、CloudFront の欧州リージョンの料金に含まれ、1 バイト目のレイテンシ―を最大 14% 削減します。CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront インフラストラクチャをご覧ください。

Amazon CloudFront Security Savings Bundle のご紹介

日付: 2021 年 2 月 5 日

本日、Amazon CloudFront Security Savings Bundle を発表します。これは、1 年間にわたって月間最低使用量を確約いただくことと引き換えに、CloudFront の請求額を最大 30% 節約できる柔軟なセルフサービスの料金プランです。また、Savings Bundle では、確約いただいた金額の最大 10% について、AWS WAF (Web Application Firewall) を無料でご利用いただけます。CloudFront Security Savings Bundle によってカバーされていない追加の Standard CloudFront または WAF 料金は引き続き適用されます。 

CloudFront Security Savings Bundle を使用すると、ワークロードに最適な月間最低使用量を柔軟に選択して、節約を最大化できます。例えば、月額 70 USD の最低使用量を確約すると、100 USD 相当の CloudFront 使用量がカバーされます (30% 割引)。この使用にかかる特典は、CloudFront によって配信されるデータに限定されず、Lambda@Edge を含むすべての CloudFront 使用タイプに適用されます。さらに、お客様は AWS WAF を利用して、一般的なウェブエクスプロイトからウェブアプリケーションを保護できます。この例では、Savings Bundle は 7 USD 相当の AWS WAF 料金もカバーし、最大 1160 万の WAF リクエストをカバーします。

CloudFront Security Savings Bundle は簡単に有効にできます。CloudFront コンソールから、組み込みの節約見積もりツールと推奨機能を使用して、過去の使用状況または手動入力に基づいて節約を見積もります。複数の Savings Bundle を追加して、将来の使用量の増加に対応することもできます。  

CloudFront Security Savings Bundle の使用を開始するには、CloudFront コンソールにアクセスしてください。CloudFront Security Savings Bundle の詳細については、よくある質問または CloudFront デベロッパーガイドをご覧ください。AWS WAF の詳細については、WAF 製品ページにアクセスしてください。

タイでの Amazon CloudFront の提供を開始

2020 年 11 月 17 日

詳細: Amazon CloudFront は、タイでは最初となる、2 つのエッジロケーションを発表しました。これらのバンコクの新しいエッジロケーションにより、視聴者に対しては、p90 基準で最大 30% 減となる レイテンシーを提供できるようになります。これらの新しいエッジロケーションの料金は、アジアパシフィック地域でのリージョンにおける、CloudFront の料金帯に収まるように設定されています。CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront インフラストラクチャをご覧ください。

Amazon CloudFront が署名付き URL と署名付き Cookie 向けとして IAM ユーザーのアクセス許可を通じたパブリックキー管理のサポートを発表

日付: 2020 年 10 月 22 日

詳細: Amazon CloudFront は、AWS ルートアカウントを必要とせずに、Amazon Identity and Access Management (IAM) ベースのユーザーアクセス許可を通じて署名付き URL と署名付き Cookie に使用するパブリックキーを管理できるようになったことを発表しました。IAM ユーザーアクセス許可ベースのパブリックキー管理により、パブリックキーを管理するための柔軟性と API アクセスが向上します。

インターネットを介してコンテンツを配信する多くのお客様は、特定のユーザー (料金を支払ったユーザーなど) を対象としたドキュメント、ビジネスデータ、メディアストリーム、またはコンテンツへのアクセスを制限したいと考えています。お客様は、CloudFront の署名付き URL と署名付き Cookie を使用して、コンテンツへのアクセスを制限しています。これまで、CloudFront は、信頼できる署名者がパブリックキーを管理するためにルートアカウントアクセスを必要としていました。今回の拡張機能により、CloudFront でキーグループを作成および管理できます。キーグループは、付与されたアクセス許可に基づいて IAM ユーザーが作成できる複数のパブリックキーのセットです。 

キーグループは、同じ組織内の他のユーザーと共有できます。今回のリリースでは、CloudFront の API を介してパブリックキーをローテーションして、メンテナンスを容易にすることもできます。必要に応じて、信頼できる署名者のルートアカウントアクセスを引き続き使用してパブリックキーを管理できます。

Amazon CloudFront でプライベートコンテンツを提供する方法の詳細については、CloudFront のドキュメントをご覧ください。Amazon CloudFront の使用を開始するには、ウェブページにアクセスしてください。

Amazon CloudFront Origin Shield の発表

日付: 2020 年 10 月 20 日

詳細: Amazon CloudFront は、Origin Shield を発表しました。これは一元化されたキャッシングレイヤーで、キャッシュヒット率を高めてオリジンの負荷を軽減するのに役立ちます。Origin Shield は、リージョン間でリクエストを折りたたんで、オブジェクトごとに 1 つのリクエストがオリジンに送信されるようにすることで、オリジンの運用コストも削減します。Lambda@Edge を Origin Shield とともに使用して、動的なオリジンロードバランシングなどの高度なサーバーレスロジックを有効にすることもできます。ライブストリーミング、画像処理、またはマルチ CDN ワークロードに Origin Shield を使用しているお客様は、オリジンの負荷が最大 57% 削減されたと報告しています。

ジャストインタイムパッケージングなど、リクエストごとにより多くの計算を必要とするプロセスを持つお客様のオリジンは、オリジンフェッチの数に敏感になる可能性があります。CloudFront は、オリジンの運用上の負担を軽減するために、追加コストなしでリージョン別エッジキャッシュを既に提供しています。CloudFront Origin 設定でたった 2 回クリックして Origin Shield を有効にすることで、オリジンの負荷をさらに最小限に抑えることができます。Origin Shield を設定するには、オリジンに最も近いリージョン別エッジキャッシュを選択して、Origin Shield リージョンにします。すべての Origin Shield リージョンは、複数のアベイラビリティーゾーンにまたがる高可用性アーキテクチャを使用して構築されており、セカンダリオリジンシールドリージョンへの自動フェイルオーバーが含まれています。Origin Shield を有効にすると、CloudFront はすべてのオリジンフェッチを Origin Shield を介してルーティングし、コンテンツが Origin Shield のキャッシュにまだ保存されていない場合にのみオリジンにリクエストを送信します。

Origin Shield は、増分レイヤーとして Origin Shield に送信される各リクエストのリクエスト料金として請求されます。 Origin Shield の料金の詳細については、CloudFront の料金を参照してください。Origin Shield の詳細については、Amazon CloudFront デベロッパーガイドを参照してください。Amazon CloudFront の使用を開始するには、ウェブページにアクセスしてください。 

Amazon CloudFront がメキシコとニュージーランドの 2 つの新しい国で利用可能に

日付: 2020 年 9 月 29 日

詳細: Amazon CloudFront がメキシコとニュージーランドの 2 つの新しい国での最初のエッジロケーションの開始を発表しました。メキシコでは、ケレタロの 2 つの新しいエッジロケーションにより、最大 30% 減の p90 レイテンシーを視聴者に提供できるようになります。これらの新しいエッジロケーションの料金は、CloudFront の北米の地理的リージョンの価格帯に収まるように設定されています。ニュージーランドでは、オークランドの 2 つの新しいエッジロケーションにより、最大 50% 減の p90レイテンシーを視聴者に提供できるようになります。これらの新しいエッジロケーションの料金は、CloudFront のオーストラリアの地理的リージョンの価格帯に収まるように設定されています。CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront インフラストラクチャをご覧ください。

Amazon CloudFront で、Brotli 圧縮がご利用可能に

日付: 2020 年 9 月 15 日

詳細: Amazon CloudFront を使用して、Brotli 圧縮コンテンツをエンドユーザーに提供できるようになりました。Brotli は広くサポートされているロスレス圧縮アルゴリズムで、多くの場合において、Gzip よりも優れた圧縮率を提供します。ファイルサイズが小さいほど、コンテンツをより速く視聴者に配信できるため、アプリケーションのパフォーマンスが向上します。CloudFront の Brotli エッジ圧縮は、Gzip と比較して最大 24% 小さいファイルサイズを提供します。

これまでは、「Accept-Encoding」ヘッダーをホワイトリストに登録することで、オリジンで Brotli 圧縮を有効にすることができました。本日以降、CloudFront は、オリジンに転送する前に、正規化された「Accept-Encoding」ヘッダーに「br」を含めます。Brotli オリジン圧縮を有効にするために「Accept-Encoding」ヘッダーをホワイトリストに登録する必要がなくなり、全体的なキャッシュヒット率が向上します。さらに、オリジンが非圧縮コンテンツを CloudFront に送信する場合、CloudFront は Brotli を使用してエッジでキャッシュ可能な応答を自動的に圧縮できるようになりました。

Brotli は追加費用なしですぐにご利用いただけます。この機能は、CloudFront コンソール、SDK、および CLI を介して有効にできます。詳細は、CloudFront デベロッパーガイドをご覧ください。CloudFront の使用を開始するには、CloudFront の製品ページにアクセスしてください。

Amazon CloudFront で TLSv1.3 によるビューワー接続のサポートを開始

日付: 2020 年 9 月 3 日

詳細: Amazon CloudFront で TLSv1.3 がサポートされ、パフォーマンスとセキュリティが改善されました。Amazon CloudFront は、コンテンツを低レイテンシーかつ高可用性で安全に視聴者に配信できる、グローバルコンテンツ配信ネットワーク (CDN) サービスです。Amazon CloudFront では、ビューワークライアントとの間の通信を暗号化し安全を確保するために、Transport Layer Security (TLS) を使用する HTTPS をサポートしています。TLSv1.3 は、この TLS の最新のバージョンです。

改善したパフォーマンス

TLSv1.3 は、往復の通信回数を削減できるシンプルなハンドシェークプロセスを使用することで、パフォーマンスを向上させます。安全な接続を行うためのネゴシエーションのために、TLSv1.2 では 2 回の往復通信（2-RTT）が必要であったのに対し、TLSv1.3 が必要とするのは 1 回（1-RTT）のみです。これは、第 1 バイトでのレイテンシーを低減するので、現実的なパフォーマンスの改善をもたらします。US リージョンで当社が実施した社内テストを実例にあげると、TLSv1.3 でネゴシエーションした新しい接続における第 1 バイトでのレイテンシーは、従来の TLS と比較して最大で 33% まで削減しました。

セキュリティの強化

TLSv1.3 では、これまでの TLS バージョンが使用していた、レガシー機能や古い暗号スイートを削除しています。TLSv1.3 は、その時点のネットワークセッションのみで使用されるワンタイムキーを生成する、PFS（パーフェクトフォワードシークレシー）暗号スイートのみをサポートします。

TLSv1.3 は今すぐにご利用いただけます。すべての Amazon CloudFront におけるセキュリティポリシーオプションで、デフォルトで有効化されています。CloudFront の構成についての一切の変更は必要なく、TLSv1.3 のビューワー接続により改善された、セキュリティとパフォーマンスからのメリットを得ることができます。現時点で、ほとんどのウェブブラウザが既にサポートしている TLSv1.3 クライアントでは、サポートする TLS の最高バージョン（TLS 1.2、1.1、または 1）を自動的にネゴシエーションしません。カスタムの SSL 認証を使用しているお客様の場合は、サポートされる最低限のセキュリティポリシーを選択してください。

ビューワーと CloudFront 間でサポートしているプロトコルと暗号の詳細については、CloudFront デベロッパーガイドをご参照ください。Amazon CloudFront の詳細については、製品ページをご参照ください。

Amazon CloudFront がリアルタイムログを発表

日付: 2020 年 8 月 31 日

詳細: Amazon CloudFront は、CloudFront アクセスログのリアルタイムのログ配信のサポートを開始しました。Amazon CloudFront は、コンテンツを低レイテンシーかつ高い可用性で視聴者に配信できるグローバルコンテンツ配信ネットワーク (CDN) です。リアルタイムログには、CloudFront が受信する視聴者リクエストに関する詳細情報が含まれています。これらのログは、リアルタイムで Kinesis Data Streams に配信されるため、コンテンツ配信のパフォーマンスを簡単に監視し、運用イベントにすばやく対応できます。

CloudFront は、お客様の Amazon S3 バケットへのアクセスログの配信をサポートしており、ログは通常数分で配信されます。ただし、一部のお客様のユースケースでは時間が重要な要素となっており、アクセスログデータを迅速に取得する必要があります。新しいリアルタイムログを使用すると、数秒でデータを利用できるようになり、コンフィギュアビリティが向上します。たとえば、ログで必要なフィールドを選択し、特定のパスパターン (キャッシュ動作) のログを有効にし、サンプリングレート (ログに含まれるリクエストの割合) を選択できます。CloudFront リアルタイムログは Kinesis Data Streams と統合されているため、ログデータを即座に収集、処理、および配信できます。Amazon Kinesis Data Firehose を使用して、これらのログを一般的な HTTP エンドポイントに簡単に配信することもできます。Amazon Kinesis Data Firehose は、Amazon S3、Amazon Redshift、Amazon Elasticsearch Service、および Datadog、New Relic、Splunk などのサービスプロバイダーにログを配信できます。これらのログを使用して、リアルタイムのダッシュボードを作成し、アラートを設定し、異常を調査したり、運用イベントに迅速に対応したりできます。本日のリリースでは、CloudFront は、一元化されたページからログ設定を管理するための個別の [Logs (ログ)] ページを設けることで、アクセスログのコンソールエクスペリエンスを最適化しました。[Log (ログ)] ページから、リアルタイムのログ設定を作成して、CloudFront ディストリビューション内のキャッシュ動作に適用できます。

この機能はすぐに使用でき、CloudFront コンソール、SDK、および CLI を介して有効にすることができます。CloudFormation のサポートは、このリリースの直後に利用可能になります。詳細については、CloudFront デベロッパーガイドと API ドキュメントを参照してください。リアルタイムログは、CloudFront がログの宛先に発行するログ行の数に基づいて課金されます。リアルタイムログの料金に関する情報は、CloudFront の料金ページにあります。 Kinesis Data Stream のコストは使用状況によって異なり、料金は料金ページで確認できます。

Amazon CloudFront が AWS の欧州 (アイルランド) リージョンで新しいリージョン別エッジキャッシュを開始

日付: 2020 年 8 月 10 日

詳細: Amazon CloudFront は、AWS の欧州 (アイルランド) リージョンに所在する新しいリージョン別エッジキャッシュを開始したことを発表しました。このリリースの一環として、ロンドンリージョンのリージョン別エッジキャッシュを介してオリジンリクエストを送信した少数の CloudFront エッジロケーションが、アイルランドリージョンを通過するようになりました。これらのエッジロケーションは、アイルランドに近いため、またはアイルランドへの直接接続が多いため、ロンドンのリージョン別エッジキャッシュと比べて、アイルランドのリージョン別エッジキャッシュからコンテンツをフェッチする場合、レイテンシーが 62% 削減されます。

CloudFront は現在、世界中で 12 のリージョン別エッジキャッシュを運用しています。これらは、CloudFront のエッジロケーションとオリジンの間に配置された中間層キャッシュレイヤーとして機能します。これらの中間層キャッシュは、コンテンツをより長期間保持するための増分キャッシュ幅を提供し、オリジンのトラフィックスパイクからの保護を強化します。すべてのリージョン別エッジキャッシュと同様に、アイルランドのロケーションは無料で提供され、CloudFront ディストリビューションにデフォルトで自動的に含まれます。CloudFront の中間層ロケーションを利用するのに設定は必要ありません。

各リージョン別エッジキャッシュの場所を含む CloudFront のグローバルネットワークのリストを確認するには、Amazon CloudFront の機能ページをご覧ください。 

Amazon CloudFront に、より詳細なジオターゲティングを行える位置情報ヘッダーが追加

日付: 2020 年 7 月 24 日

詳細: Amazon CloudFront で追加の位置情報ヘッダーがご利用いただけるようになりました。新しいキャッシュおよびオリジンリクエストポリシーで使用できます。

CloudFront を設定して、キャッシングとオリジンリクエストポリシーをより詳細に設定する追加の位置情報ヘッダーを追加できるようになりました。以前は、CloudFront がオリジンに送信するリクエストヘッダーに閲覧者の国コードを提供するように Amazon CloudFront を設定することができました。新しいヘッダーにより、キャッシュの動作をより細かく制御したり、視聴者の IP アドレスに基づいて、視聴者の国名、リージョン、都市、郵便番号、緯度、経度にアクセスしたりできます。

サンプル値を含む追加の位置情報ヘッダー:

CloudFront-Viewer-Country-Name: United States

CloudFront-Viewer-Country-Region: MI

CloudFront-Viewer-Country-Region-Name: Michigan

CloudFront-Viewer-City: Ann Arbor

CloudFront-Viewer-Postal-Code: 48105

CloudFront-Viewer-Time-Zone: America/Detroit

CloudFront-Viewer-Latitude: 42.30680

CloudFront-Viewer-Longitude: -83.70590

CloudFront-Viewer-Metro-Code: 505

これらの追加の位置情報ヘッダーを、既存のサポートされている CloudFront ヘッダーとともに使用して、視聴者に配信するコンテンツをパーソナライズできます。たとえば、郵便番号ヘッダーをオリジンに渡して、ハイパーローカルコンテンツまたは広告を表示できます。Lambda@Edge オリジンリクエスト関数を使用して、ネットワーク呼び出しを行ってローカル言語ファイルを取得し、国またはリージョンごとに言語固有の HTML ページを作成して返すこともできます。

これらの追加の位置情報ヘッダーは、追加費用なしですべての Amazon CloudFront ディストリビューションでご利用いただけるようになりました。

このような新しいヘッダーを使用するには、CloudFront デベロッパーガイドを参照してください。新しいキャッシュとオリジンリクエストポリシーの詳細については、ブログをご覧ください。CloudFront イベントに対応してコードを実行する方法の詳細については、Lamda@Edge 製品ページにアクセスしてください。Amazon CloudFront の詳細については、製品ページをご参照ください。 

Amazon CloudFront がキャッシュキーとオリジンリクエストポリシーを発表

日付: 2020 年 7 月 22 日

詳細: Amazon CloudFront は、ヘッダー、クエリ文字列、クッキーを構成するための、さらに強化された詳細な制御の提供を開始しました。これらは、キャッシュキーを計算したり、CloudFront ディストリビューションからオリジンを転送したりするときに使用します。さらに、キャッシュキーとオリジンリクエストの設定をアカウントレベルのポリシーとして個別に設定して、複数のディストリビューションに簡単に適用できます。

以前は、ヘッダー、クエリ文字列、Cookie などのリクエストメタデータを転送するように CloudFront 配信動作を設定すると、CloudFront はこれらのメタデータ値のすべての一意の組み合わせに基づいて、これらのオブジェクトの個別のバージョンをキャッシュしていました。この新しい機能を使用すると、、データをオリジンに転送するか、キャッシュ効率を最適化するかを選択する必要がありません。絶対に必要な場合にのみキャッシュキーを変更するだけで済みます。たとえば、常に「Auth」または「User-Agent」ヘッダーをオリジンに転送するように CloudFront を設定できますが、これらの値に基づいてコンテンツを変更することはできません。または、すべてを転送できますが、特定のヘッダーまたはクエリ文字列パラメータを選択して、キャッシュされたコンテンツを変化させるために使用します。たとえば、「Accept-Language」ヘッダーを使用して、サポートされているクライアント言語によってローカライズされたコンテンツバリアントを提供する場合などです。

さらに、これらのオプションは現在、ポリシーを使用して設定されるようになりました。ポリシーにより、同じ特定の設定の組み合わせを多くの異なる配信動作に簡単に適用でき、セットアップ時間と複雑さを低減し、設定全体の一貫性を管理できます。CloudFront は、事前設定されたシステムポリシーもいくつか提供します。これらには、最大のキャッシュと保持のデフォルトポリシー (最大 TTL、圧縮など)、動的トランザクションのプロキシに適したポリシー (キャッシュの無効化)、さらには AWS Elemental Media Package を使用したパーソナライズされたビデオストリーミング、S3 CORS ヘッダーサポート (特定の予期されるヘッダーの転送) など、一般的なユースケースや他の AWS のサービスとの統合のためのポリシーも含まれます。さまざまなコンテンツおよびアプリケーションプロファイルに対して独自のポリシーを作成してから、同様の特性を持つすべてのディストリビューションおよび動作に適用できます。

この機能はすぐに使用でき、CloudFront コンソール、API、SDK、および CLI でサポートされています。詳細については、CloudFront デベロッパーガイドと API ドキュメントを参照してください。この機能は追加料金なしで使用できます。CloudFront の標準料金が適用されます。

Amazon CloudFront がビューワー接続用の新しい TLS1.2 セキュリティポリシーを発表

日付: 2020 年 7 月 17 日

詳細情報: Amazon CloudFront が新しいセキュリティポリシー TLSv1.2_2019 のサポートを開始しました。このサポートには、次の暗号のみが含まれます。

• TLS_AES_128_GCM_SHA256

• TLS_AES_256_GCM_SHA384

• TLS_CHACHA20_POLY1305_SHA256

• ECDHE-RSA-AES128-GCM-SHA256

• ECDHE-RSA-AES128-SHA256

• ECDHE-RSA-AES256-GCM-SHA384

• ECDHE-RSA-CHACHA20-POLY1305

• ECDHE-RSA-AES256-SHA384
  

セキュリティポリシーは、CloudFront がビューワーとの通信に使用する SSL/TLS プロトコルと、CloudFront がビューワーに返すコンテンツを暗号化するのに使用する暗号を決定します。TLSv1.2_2019 ポリシーは、ネゴシエートされた最小の Transport Layer Security (TLS) バージョンを 1.2 に設定し、上記の暗号のみをサポートします。カスタム SSL 証明書を使用して新しいディストリビューションを作成すると、TLSv1.2_2019 がデフォルトのポリシーオプションとして選択されます。AWS マネジメントコンソール、Amazon CloudFront API、または AWS CloudFormation を使って、この新しいセキュリティポリシーを利用するように既存のディストリビューション設定を更新できます。

TLSv1.2_2019 セキュリティポリシーは、本日よりご利用いただけます。この新しいポリシーとサポートされる暗号の詳細については、CloudFront のドキュメントをご参照ください。CloudFront の使用を開始するには、CloudFront の製品ページにアクセスしてください。

Amazon CloudFront で、オリジン接続の試行とタイムアウトが設定可能に

日付: 2020 年 6 月 11 日

詳細: Amazon CloudFront で、CloudFront とオリジン間の接続動作をさらに細かく制御できるようになりました。CloudFront のオリジンへの接続試行回数と、各試行のオリジン接続タイムアウトが設定できるようになりました。加えて、CloudFront オリジン応答タイムアウトの範囲が拡張し、値を 1 秒から 60 秒の間で変更できるようになりました (以前の最短時間は 4 秒でした)。これらの 2 つの新しい設定は、CloudFront ディストリビューション内の任意のタイプのオリジンで個別に設定できます。この設定を CloudFront オリジンフェイルオーバーと組み合わせた場合、マルチオリジンアプリケーションの応答性と可用性をさらに高めることも可能です。

たとえば、CloudFront のオリジンフェイルオーバーを使用して、プライマリオリジンとセカンダリオリジンを備えた高い可用性を持つアプリケーションを作成できます。これらの新しいオリジン接続設定を使用することにより、オリジングループのフェイルオーバー状態をより迅速に切り替え、ビューワーの要求にさらに素早く応答できるようになります。ストリーミング動画コンテンツなどの一部のユースケースでは、プライマリオリジンが応答しない場合、CloudFront で 1 秒のタイムアウトで 1 度だけ接続を試行し、セカンダリオリジンにフェイルオーバーしたいことがあります。オリジン接続動作のしきい値を低くすると、セカンダリオリジンから動画セグメントを素早くフェッチしたり、プレーヤーに独自の再試行ロジックを実行する時間を与えたりして、動画のバッファリングを最小限に抑えることができます。

これらの新らしい機能は、追加料金なしで今すぐご利用いただけます。AWS マネジメントコンソール、Amazon CloudFront API、または AWS CloudFormation を使用して、これらの値を設定できます。これらの新しい設定の詳細については、CloudFront のドキュメントをご参照ください。CloudFront の使用を開始するには、CloudFront の製品ページにアクセスしてください。

Amazon CloudFront がコルカタとハンブルクの最初のエッジロケーションを発表

日付: 2020 年 5 月 13 日

詳細: Amazon CloudFront は、インドのコルカタとドイツのハンブルクの最初のエッジロケーションを発表しました。これらの新しいエッジロケーションによって提供されるビューワーでは、最大 20% のレイテンシーの改善を期待できます。インドにおいては、CloudFront は、ベンガルール、チェンナイ、デリー、ハイデラバード、およびムンバイに複数のエッジロケーションを有しています。同様に、CloudFront は、すでにベルリン、デュッセルドルフ、フランクフルト、およびミュンヘンなどのドイツのいくつかの都市にエッジロケーションを有しています。CloudFront のグローバルインフラストラクチャの詳細については、CloudFront の主な特徴をご覧ください。

中国の Amazon CloudFront が Origin Access Identity に対するサポートを発表

日付: 2020 年 4 月 24 日

詳細: 中国の Amazon CloudFront は、Origin Access Identity (OAI) に対するサポートを発表しました。OAI を使用すると、中国にある Amazon CloudFront の分散型エッジネットワーク経由でコンテンツを取得することを必須とすることにより、ビューワ―が Amazon S3 バケットから直接コンテンツにアクセスすることを制限することができます。中国の Amazon CloudFront の OAI の詳細については、コンテンツへの安全なアクセスとアクセス制限の設定の CloudFront の資料をお読みください。中国で Amazon CloudFront を開始するには、当社のウェブページにアクセスしてください。

AWS Lambda@Edge で Node 12.x と Python 3.8 のサポートを開始

日付: 2020 年 3 月 2 日

詳細: 本日より、Lambda@Edge で Node.js 12.x と Python 3.8 を使用して関数を開発できるようになりました。これらのランタイムに加え、現在サポート中の Node.js 10.x および Python 3.7 も引き続きご利用になれます。

Node.js 12.x は最新の Long Term Support (LTS) バージョンの Node.js で、新しい V8 7.4 エンジンを使用しています。また、以前の LTS バージョンである 10.x と比較してパフォーマンスが向上しています。さらに Node.js 12.x では、プライベートクラスや、強化されたスタックトレーシングといった新機能がサポートされています。Node.js 12.x の利点や新機能の詳細は、AWS の Node.js 12.x についてのブログ記事にてご確認ください。

Python 3.8 は Python 言語の最新のメジャーリリースであり、代入式、位置専用引数、型の改善といった新機能が含まれています。Python 3.8 の利点や新機能の詳細は、AWS の Python 3.8 についてのブログ記事にてご確認ください。

これらの新しいランタイムの使用を開始するには、AWS CLI または Lambda コンソールから Node.js または Python のコードを AWS Lambda 関数としてアップロードし、Node.js 12.x または Python 3.8 のいずれかを選択します。既存の Node.js 関数または Python 関数を Lambda にお持ちの場合は、新しいランタイムとの互換性を確保するために必要なコード変更を行った後、関数設定を編集してランタイムを Node.js 12.x または Python 3.8 に設定することで、新しいランタイムに切り替えることができます。

Lambda@Edge の詳細については、製品ページを参照してください。Lambda の Node.js プログラミングモデルの詳細については、AWS の Node.js ドキュメントを参照してください。Lambda の Python プログラミングモデルの詳細については、AWS の Python ドキュメントをご覧ください。

中国で使用する Amazon CloudFront がコンソールでの使用状況およびアクティビティレポートのサポートを発表

日付: 2020 年 2 月 21 日

詳細: Amazon CloudFront を中国でご利用のお客様向けに、AWS マネジメントコンソールの CloudFront レポートを使用して CloudFront の使用状況とアクティビティに関する詳細情報が取得できるようになりました。中国でご利用のお客様は CloudFront キャッシュ統計レポートを使用することで、合計リクエスト、結果タイプごとのビューワーリクエストの割合、転送されたバイト数、HTTP ステータスコード、ダウンロードが完了しなかった GET リクエストの割合を確認できます。CloudFront 人気オブジェクトレポートには、人気のあるオブジェクト上位 50 個と、それらのオブジェクトに関する統計が表示されます。CloudFront トップリファラーレポートには、上位 25 件のリファラーと、各リファラーからのリクエスト数が表示されます。CloudFront 使用状況レポートには、プロトコルごとや送信先ごとのリクエスト数およびデータ転送数が表示されます。CloudFront ビューワーレポートには、デバイス、ブラウザ、オペレーティングシステム、および場所ごとのビューワーの詳細が表示されます。これらのレポートは CloudFront を利用するすべてのお客様に提供され、追加の費用は発生しません。

中国で CloudFront の利用を開始するには、Amazon CloudFront にアクセスしてください。ドキュメントについては、Amazon CloudFront デベロッパーガイド内のコンソールの CloudFront レポートを参照してください。

Amazon CloudFront のご利用が新しく 5 つの国 (ブルガリア、ギリシャ、ハンガリー、ケニア、ルーマニア) で開始

日付: 2020 年 1 月 10 日

詳細情報: Amazon CloudFront が新たに 5 つの国で、最初のエッジロケーションを発表しました。ナイロビ (ケニヤ)、ソフィア (ブルガリア)、アテネ (ギリシャ)、ブダペスト (ハンガリー)、ブカレスト (ルーマニア) です。これらの国の利用者は、CloudFront を介してコンテンツにアクセスする際、レイテンシーが平均で最大 50% 改善されるようになります。これらの新しい国々に加えて、CloudFront はドイツのデュッセルドルフにも最初のエッジロケーションを設置します。これらの新しいロケーションを加えて、CloudFront の POP (Point Of Presence) は現在合計 216 か所あり、42 か国の 84 都市に広がっています。CloudFront のグローバルインフラストラクチャの詳細については、Amazon CloudFront インフラストラクチャをご覧ください。

Amazon CloudFront が、8 つのリアルタイムメトリクスをAmazon CloudWatch に追加

日付: 2019 年 12 月 19 日

詳細: Amazon CloudFront が、Amazon CloudWatch で使用できるリアルタイムメトリクスをさらに 8 つ提供するようになりました。これらの新しいメトリクスは、CloudFront トラフィックのパフォーマンスの可視性を向上させます。CloudFront のリアルタイムメトリクスを使用して、CloudFront ディストリビューションの運用パフォーマンスに関するモニタリング、アラーム、通知を受信できます。CloudFront は、追加費用なしですべての CloudFront ユーザーに 6 つの運用メトリクスと 4 つの Lambda@Edge 関数メトリクスをすでに提供しています。

8 つのメトリクスには以下が含まれます。

キャッシュヒット率: CloudFront がキャッシュからコンテンツを提供した、すべてのキャッシュ可能なリクエストの割合。HTTP POST および PUT リクエストとエラーは、キャッシュ可能なリクエストとは見なされません。キャッシュヒット率を使用すると、コンテンツのオリジンサーバーに移動する代わりに、CloudFront エッジキャッシュから提供されるビューワーリクエストの割合を決定できます。

オリジンレイテンシー: CloudFront キャッシュではなく、オリジンから提供されるリクエストについて、CloudFront がリクエストを受信してからネットワーク (ビューワー以外) に応答を返すまでの合計時間 (ミリ秒単位) です。オリジンレイテンシーを使用すると、オリジンサーバーのパフォーマンスをモニタリングできます。

ステータスコードごとのエラー率: 応答の HTTP ステータスコードが 4xx または 5xx の範囲の特定のコードである、すべてのビューアリクエストの割合。このメトリクスは、401、403、404、502、503、504 のエラーコードで使用できます。エラー率メトリックを使用すると、4xx または 5xx エラーの背後にある特定のタイプの HTTP ステータスコードを識別できます。

これらの新しいメトリクスは、CloudFront コンソールのモニタリングページで有効にできるようになりました。その際、標準の CloudWatch レートが適用されます。これらのメトリクスを有効にする方法の詳細については、「追加の CloudFront ディストリビューションメトリクスの表示」をご覧ください。

Amazon CloudFront がアクセスログに 7 つの新しいデータフィールドを提供

日付: 2019 年 12 月 12 日

詳細: Amazon CloudFront のアクセスログは、CloudFront が受け取るユーザーリクエストのすべてに関する詳細情報を提供します。本日から、お使いの CloudFront アクセスログに、コンテンツの配信に対する可視性を向上させるための 7 つの追加データフィールドが表示されるようになります。例えば、x-edge-detailed-result-type フィールドでは特定タイプのエラーを識別し、sc-range-start/sc-range-end の各フィールドではリクエストされた範囲の詳細を確認できます。これらの新しいフィールドは、以前のログファイル形式との後方互換性を維持するために、各ログエントリの最後に追加されます。7 つの新しいデータポイントは以下の通りです。

• c-port – ビューワーからのリクエストのポート番号です。
• time-to-first-byte – リクエストを受信してから応答の最初のバイトを書き込むまでの秒数で、サーバーで測定されます。
• x-edge-detailed-result-type – 結果タイプがエラーの場合は、このフィールドに特定タイプのエラーが含まれます。
• sc-content-type – 応答の HTTP Content-Type ヘッダの値です。
• sc-content-len – 応答の HTTP Content-Length ヘッダの値です。
• sc-range-start – 応答に HTTP Content-Range ヘッダが含まれる場合は、このフィールドに範囲開始値が含まれます。
• sc-range-end – 応答に HTTP Content-Range ヘッダが含まれる場合は、このフィールドに範囲終了値が含まれます。

アクセスログの有効化は無料ですが、ログファイルの保存には S3 の標準料金が適用されます。アクセスログとログファイル形式に関する詳細については、CloudFront ドキュメントの「ウェブディストリビューションのログファイル形式」を参照してください。

Amazon CloudFront kündigt 10 neue Edge-Standorte an, darunter den ersten Edge-Standort in Rom, Italien

Datum: 26. Nov. 2019

Details: Amazon CloudFront kündigt seinen ersten Edge-Standort in Rom und zwei weitere Edge-Standorte in Mailand an - mehr als die Verdoppelung der Gesamtkapazität von CloudFront auf der italienischen Halbinsel.Darüber hinaus kündigt CloudFront weitere Edge-Standorte in Kuala Lumpur, Mumbai, Singapur, Sydney, Philadelphia, Newark, Atlanta, Los Angeles und Hillsboro an, um das globale Netzwerk von CloudFront auf 210 Points of Presence in 78 Städten in 37 Ländern zu bringen.CloudFront のグローバルインフラストラクチャの詳細については、CloudFront の主な特徴をご覧ください。

Amazon CloudFront in China gibt Unterstützung für AWS CloudFormation und Echtzeitmetriken in Amazon CloudWatch bekannt

日付: 2019 年 11 月 1 日

詳細: 中国の Amazon CloudFront が AWS CloudFormation テンプレートおよび Amazon CloudWatch でのリアルタイムのメトリクスに対応することを発表しました。このリリースに伴い、中国のユーザーに、Amazon S3 固有またはお客様固有の CloudFront ディストリビューションを作成する際、CloudFormation テンプレートをご利用いただけるようになります。CloudFormation は、AWS でのプロビジョニングと管理を単純化します。お客様はご自身で必要とするサービスまたはアプリケーションのアーキテクチャ用にテンプレートを作成し、それらを信頼できる、繰り返しのプロビジョニングに使用できます。お客様は AWS CloudFormation のテンプレートページでサンプルのテンプレートとテンプレートスニペットを見ることができます。 

さらに、中国のお客様は今後、AWS 中国 (寧夏) リージョンで CloudWatch を使用する CloudFront の運用パフォーマンスについてモニタリングおよびアラームを発することができるほか、運用パフォーマンスの通知を受け取ることもできます。本日リリースされる両方の機能は、AWS のお客様に追加料金なしでご利用いただけます。

中国で CloudFront の利用を開始するには、Amazon CloudFront にアクセスしてください。ドキュメントについては、中国での AWS のサービスガイドで Amazon CloudFront をご覧ください。

AWS for WordPress プラグインが利用可能になり、新しい Amazon CloudFront ワークフローに追加されました

日付: 2019 年 10 月 30 日

詳細: アマゾン ウェブ サービスは AWS for WordPress プラグインの一般利用の開始を発表します。以前、Amazon Polly と Amazon AI プラグインとして知られていた新しい AWS for WordPress プラグインが、WordPress ウェブサイトに対して高度に最適化された Amazon CloudFront のディストリビューションを設定するためのワークフローを提供するようになりました。

AWS のコンテンツ配信ネットワークである Amazon CloudFront は、200 のエッジロケーションのグローバルネットワークを使用して、ビューアに近いコンテンツをキャッシュして、配信します。プラグインの新しい CloudFront ワークフローは複数のキャッシュビヘイビアーをもつ配信を作成し、それぞれのビヘイビアーは最良のビューア―と管理者エクスペリエンスのために対するさまざまなタイプのコンテンツを対象にしてカスタマイズされています。

AWS for WordPress プラグインは、WordPress Plugin ディレクトリから無料でダウンロードできます。AWS のサービスの使用には標準料金が適用されます。新しい CloudFront ワークフローを使用するプラグインの既存のユーザーは、プラグインの IAM ユーザーに対する IAM ポリシーを更新する必要があります。AWSforWordPressPluginPolicy という名前の新しいマネージド IAM ポリシーを使用して、更新された IAM ポリシーを作成することに関する詳細は、CloudFront デベロッパーガイドを参照してください。

AWS で WordPress をセルフホスティングし、プラグイン内で新しい CloudFront ワークフローを使用するための詳細なガイドについては、ブログ投稿を参照してください。また、AWS で非常にスケール自在な WordPress ウェブサイトに関する詳細は、新しく更新されたホワイトペーパー WordPress: AWS でのベストプラクティスもお読みください。

Amazon CloudFront がコロンビア、チリ、アルゼンチンにて新たなエッジロケーションを開設し、200 ロケーションに拡大されました。また、南米での料金が 56% 引き下げられました。

日付: 2019 年 10 月 24 日

詳細: Amazon CloudFront は、コロンビア、チリ、アルゼンチンでの Edge ロケーションの提供開始を発表します。これらの Edge ロケーションにより、対象の国々から CloudFront を通じコンテンツへアクセスされるビューワーの方々は、平均で 60% のレイテンシー改善を体験できます。さらに 2019 年 11 月 1 日以降は、南米地域での CloudFront によるオンデマンドのデータ転送料金が、最大で 56% まで削減されます。南米での料金体系は「Amazon CloudFront の料金」でご確認いただけます。現在までに CloudFront の POP (Point Of Presence) は、 37 か国の 77 都市に広がる合計 200 か所となっています。こちらから、今回の発表に関する Jeff Barr の ブログ がご覧いただけます。

Amazon CloudFront、ベルギーでの最初のエッジロケーションを発表

日付: 2019 年 10 月 21 日

詳細: Amazon CloudFront が、ベルギーのブリュッセルに最初のエッジロケーションを設けることを発表しました。この新しいエッジロケーションにより、ベルギーから CloudFront を通じコンテンツにアクセスされるビューワーの方々は、レイテンシーで最大 28％ の改善を体験できます。 CloudFront は、ベルギー以外にも、日本の東京に 4 つ、ドイツのフランクフルトに 1 つのエッジロケーションを追加しました。CloudFront の POP (Point Of Presence) は現在合計 197 か所あり、34 か国の 74 都市に広がっています。

CloudFront のグローバルインフラストラクチャの詳細については、CloudFront の主な特徴をご覧ください。

Amazon CloudFront、新たに中国深川のエッジロケーションを発表

日付: 2019 年 9 月 19 日

詳細: Amazon CloudFront は、中国の深川に新しい CloudFront エッジ (POP) ロケーションの開設を発表しました。Ningxia Western Cloud Data Co. Ltd. (NWCD) が運営するこの新しい POP により、CloudFront は中国の都市 4 か所に 4 つの POP を所有しています。このリリースにより、深川の視聴者は、CloudFront を介してコンテンツにアクセスする際の平均レイテンシーが 62% 改善された状態でご利用いただけます。

CloudFront の中国配信の料金については、こちらを参照してください。デベロッパーガイドについては、こちらを参照してください。使用を開始するには、AWS マネジメントコンソールにログインし、コンテンツの高速化を開始します。

Amazon CloudFront、ポルトガルに最初のエッジロケーションを発表

日付: 2019 年 9 月 4 日

詳細: ポルトガルで最初の Amazon CloudFront のエッジロケーションをリスボンに開設することが発表されました。この新しいエッジロケーションにより、CloudFront によってポルトガル国内の視聴者へコンテンツを配信する際のレイテンシーが最大 60% 低減されます。CloudFront の POP (Point Of Presence) は現在合計 190 か所あり、33 か国の 72 都市に広がっています。詳細については、お知らせのページを参照してください。

CloudFront のグローバルインフラストラクチャの詳細については、CloudFront の主な特徴をご覧ください。

バーレーンに最初のエッジロケーションを設けることにより Amazon CloudFront の中東での提供範囲を拡大

日付: 2019 年 8 月 27 日

詳細: バーレーンで最初の Amazon CloudFront のエッジロケーションをマナマに開設することが発表されました。この新しいエッジロケーションにより、CloudFront によってバーレーン国内の視聴者へコンテンツを配信する際のレイテンシーが最大 40% 低減されます。CloudFront の接続拠点は現在 189 か所あり、32 か国の 71 都市に広がっています。

CloudFront のグローバルインフラストラクチャの一覧は、CloudFront の主な特徴からご覧いただけます。

Amazon CloudFront、イスラエルに新しいエッジロケーションを発表

日付: 2019 年 8 月 13 日

詳細: イスラエルで最初の Amazon CloudFront のエッジロケーションをテルアビブに開設することが発表されました。この新しいエッジロケーションにより、CloudFront によってイスラエル国内の視聴者へコンテンツを配信する際のレイテンシーが最大 75% 低減されます。CloudFront の POP (Point Of Presence) は現在合計 188 か所あり、31 か国の 70 都市に広がっています。

イスラエルのこの新しいエッジロケーションの料金を含む、CloudFront の料金の詳細については、料金ページを参照してください。

Amazon CloudFront で、リソースレベルおよびタグベースのアクセス許可のサポートを発表

日付: 2019 年 8 月 8 日

詳細: Identity and Access Management (IAM) ポリシーを定義して、CloudFront で詳細なリソースレベルおよびタグベースのユーザー権限を指定できるようになりました。これらの新機能により、CloudFront ディストリビューションへのアクセスを一段と柔軟に管理できるようになります。

これまでは、IAM ポリシーを適用して CloudFront でユーザーアクションを管理できましたが、アカウントの特定のディストリビューションにアクションを制限することはできませんでした。今後は、リソースレベルのアクセス許可により、Amazon リソースネーム (ARN) またはワイルドカードを使用して個々の CloudFront ディストリビューションを参照する IAM ポリシーを設定し、それらのディストリビューションのみにアクセス許可を持つユーザーとアクションを指定できます。同様に、タグベースのアクセス制御を使用すると、関連付けられたタグに基づいて特定の CloudFront ディストリビューションでアクションを許可または拒否する IAM ユーザーポリシーを作成することもできます。

この新しい機能の使用を開始するには、CloudFront デベロッパーガイドを参照してください。Amazon CloudFront の詳細については、製品ページをご参照ください。

Lambda@Edge が Python3.7 のサポートを追加

日付: 2019 年 8 月 1 日

詳細: 本日より、従来サポートされていた Node.js に加え、Python プログラミング言語でも Lambda@Edge の関数を開発できるようになりました。これにより、関数を作成するときに、好みのプログラミング言語を柔軟に選択できるようになります。

開始するには、まず AWS CLI または AWS Lambda コンソールを使用して関数コードをアップロードします。次に Python 3.7 ランタイムを選択し、Amazon CloudFront イベントを関連付けます。CloudFront イベントによってトリガーされる Lambda@Edge 関数では、世界中の AWS ロケーションにカスタムコードを拡張できます。そのため、アプリケーションロジックをエンドユーザーの近くで実行し、応答性を向上させることが可能になります。

Lambda@Edge の詳細については、製品ページを参照してください。Lambda の Python プログラミングモデルの詳細については、ドキュメントをご覧ください。こちらの関数の例を使用して、Python で作成した Lambda@Edge 関数を簡単にデプロイしてテストすることもできます。

Amazon CloudFront コンソールでの Lambda@Edge モニタリング機能の強化を発表

日付: 2019 年 6 月 20 日

詳細: 本日より、Amazon CloudFront ディストリビューションに関連する Lambda 関数を、Amazon CloudFront コンソールから直接モニタリングできるようになります。これにより、モニタリングとデバッグがいっそう容易になります。

これまでは、ディストリビューションと関連関数をモニタリングするには、CloudFront と AWS Lambda コンソールに別々にアクセスする必要がありました。本日発表された CloudFront コンソールの改善点は以下のとおりです。 

• CloudFront ディストリビューションおよび関連する Lambda@Edge 関数のすべてが一覧表示されるようにモニタリングダッシュボードが改良されました。これにより、ディストリビューションメトリクスと関連関数の実行メトリクスの両方を、迅速に選択および表示できるようになります。
• Lambda@Edge 5xx エラーをディストリビューションによって論理的にグループ化して集約表示するようにディストリビューションメトリクスビューが合理化されました。これにより、CloudFront 5xx エラーがお客様のオリジンに由来するものか Lambda@Edge 関数に由来するものかを判別でき、トラブルシューティングがいっそう容易になります。
• Lambda@Edge エラービューでは、新たにディストリビューションごとの詳細表示が可能となりました。関数実行エラー、無効な関数レスポンスエラー、スロットルといった、関数のエラーメトリクスについてリージョン別の内訳が表示されます。1 つまたは複数の AWS リージョンでエラーの急激な増加が見られた場合は、そのリージョンを選択し、AWS CloudWatch に保存されているリージョンのログを確認できます。

本日の発表では、Lambda コンソールの機能に変更はありません。CloudFront コンソールで Lambda 関数のモニタリングおよびデバッグを行うための詳細な手順については、こちらのブログをご覧ください。

使用を開始するには、CloudFront コンソールをご参照ください。Amazon CloudFront の詳細については、製品ページをご参照ください。

Amazon CloudFront が北米、欧州、オーストラリアに 7 か所の新しいエッジロケーションを発表

日付: 2019 年 6 月 18 日

詳細: Amazon CloudFront にて、新たに 7 か所のエッジロケーションが発表されました。新しいエッジロケーションのうち 4 か所は北米にあり、それぞれテキサス州ヒューストン (2)、オレゴン州ヒルズボロ、オンタリオ州トロントです。2 か所のエッジロケーションは欧州のマンチェスター (英国)、チューリッヒ (スイス) に、もうひとつはシドニー (オーストラリア) に追加されました。これらの新しいエッジロケーションが追加されたことで、各都市での容量が 2 倍になり、増え続けるビューワーのリクエストに応えることが可能になります。CloudFront のグローバルロケーションの一覧は、CloudFront の主な機能ウェブページからご覧いただけます。

Amazon CloudFront でインド、日本、米国に 11 か所の新しいエッジロケーションの開始を発表

日付: 2019 年 5 月 7 日

詳細: Amazon CloudFront では、世界で新たに 11 個のエッジロケーションを開設することを発表しました。これには、ユタ州ソルトレイクシティで最初のエッジロケーションも含まれます。新しいエッジロケーションの所在地は以下のとおりです。

米国

• ユタ州ソルトレイクシティ (CloudFront のネットワークに新たに追加された都市)
• マサチューセッツ州ボストン
• ワシントン州シアトル
• アリゾナ州フェニックス

日本

• 東京

インド

• ハイデラバード (2)
• バンガロール (2)
• デリー (2)

インド国内でこれら 6 個の新しいエッジロケーションが開設されたことにより、同リージョン内の CloudFront のキャパシティーが 2 倍に向上します。すべての新しい CloudFront エッジロケーションでは、お客様のウェブアプリケーションとユーザーをサポートするための全体パフォーマンスを引き続き強化していきます。CloudFront のグローバルロケーションの一覧は、CloudFront の主な機能ウェブページからご覧いただけます。

Amazon CloudFront がディストリビューションに代替ドメイン名を追加する際のセキュリティを強化

日付: 2019 年 4 月 8 日

詳細: 本日より、Amazon CloudFront でディストリビューションに代替ドメイン名を追加するプロセスが以前よりもさらに安全になります。これからは www.example.com のような代替ドメイン名をディストリビューションに追加する際、そのディストリビューションに代替ドメイン名をカバーする SSL/TLS 証明書もアタッチする必要があります。本日のリリースにより、ドメインを CloudFront ディストリビューションに追加できるのは、ドメインの証明書へのアクセスを許可されたユーザーだけとなります。

CloudFront に代替ドメイン名を追加すると、CloudFront が割り当てたデフォルトドメイン (d111111abcdef8.cloudfront.net など) の代わりに、www.example.com などの DNS レコードのカスタム CNAME を使用してコンテンツを配信できます。この変更により、AWS マネジメントコンソールまたは CloudFront API を使用して代替ドメイン名を追加する場合、代替ドメイン名を使用する権限があることを確認するために、ディストリビューションに証明書を添付しなくてはいけなくなります。証明書は、SSL/TLS 証明書を無料で提供する AWS Certificate Manager のような公的に信頼できるプライベート認証機関が発行したもの、かつ有効である必要があります。この変更が適用される前に CloudFront ディストリビューションに追加された代替ドメイン名はすべて、以前と同じように機能し続けます。今までのようにトラフィックを管理するのに必要なアクションはありません。

このプロセスについての詳細は、今回の変更について記載されているブログ記事をお読みいただくか、更新された CloudFront デベロッパーガイドを参照してください。CloudFront の使用を開始するには、開始方法のページをご覧ください。

Amazon CloudFront が米国とフランスに 6 つの新しいエッジロケーションを立ち上げることを発表

日付: 2019 年 2 月 6 日

詳細: Amazon CloudFront が 6 つの新しいエッジロケーションを立ち上げることを発表しました。これにより、それぞれの地域のネットワークに容量が追加されます。新しいエッジロケーションのうち 5 つは北米にあり、それぞれアトランタ (2)、シカゴ、ダラス、ヒューストンです。この新しい容量によって、これらの地域では CloudFront のリクエスト処理容量が平均で最大 50% 増量します。6 番目の新しいエッジロケーションはパリ (フランス) です。これまでと同様に、全ての新しい CloudFront エッジロケーションで、お客様の顧客のウェブアプリケーションの配信とパフォーマンスが向上されます。CloudFront のグローバルロケーションに関するすべてのリストは、CloudFront の主な機能の Web ページにあります。

Amazon CloudFront は北米、ヨーロッパ、アジアに 10 個の新しいエッジロケーションを発表

日付: 2018 年 12 月 11 日

詳細: Amazon CloudFront では、新たに 10 個のエッジロケーションを世界の主要都市に展開することを発表しました。新しいエッジロケーションのうち 8 つは北米で、それぞれ、テキサス州ヒューストン (この都市で初のロケーション)、イリノイ州シカゴ、ニュージャージー州ニューアーク、カリフォルニア州ロサンゼルス、バージニア州アッシュバーンです。残りの 2 つはそれぞれ、ベルリン (ドイツ) と東京 (日本) に追加されました。

今回のリリースによって、北米の都市で、CloudFront のリクエスト処理能力が平均して最大 40% 向上します。

これら新しいエッジロケーションの追加により CloudFront はさらにグローバルに展開し、お客様への配信、パフォーマンス、規模が拡張されます。CloudFront のグローバルロケーションに関するすべてのリストは、CloudFront の主な機能の Web ページにあります。

Amazon CloudFront 10 周年にあたり、6 つの新しいエッジロケーションを開設し、世界中で合計 150 の接続ポイントを達成

日付: 2018 年 11 月 20 日

詳細: Amazon CloudFront は 4 つの大陸に 6 つの新しいエッジロケーションを立ち上げることを発表米国では、シカゴ、ニューアーク、アシュバーンに新たに立ち上げられます。米国以外では、ミュンヘン、東京、リオデジャネイロが対象です。東京については、わずか 1 年前に、エッジロケーションが 100 か所を達成したことを発表しました。今回、これらの 6 つのロケーションが新たに追加され、CloudFront の合計ネットワークは世界 65 都市、29 か国に 150 のプレゼンスポイントを展開することになります。

数日前には CloudFront の 10 周年記念を祝ったばかりです。ブログを読む Jeff Bezos と Andy Jassy の内部の課題に対して CloudFront がどのように作成されたかについての話を書いています。当社のビジネスの発展にお力添えをいただき、ありがとうございます。次の 10 年に向けて新たな一歩を踏み出していきます。

Amazon CloudFront がオリジンフェイルオーバーのサポートを発表

日付: 2018 年 11 月 20 日

詳細: 本日より、エンドユーザーに配信されるコンテンツの可用性が向上するように、Amazon CloudFront ディストリビューションのオリジンフェイルオーバーを有効化できるようになりました。

CloudFront のオリジンフェイルオーバー機能を使用することで、プライマリオリジンが使用不可であることが CloudFront によって検出されると、セカンダリオリジンからコンテンツが提供されるように、プライマリとセカンダリの 2 つのオリジンをディストリビューションに設定できます。すでに CloudFront では、カスタムのエラーページを設定したり、オリジンが使用不可の場合には Lambda@Edge でリダイレクトを生成することができます。オリジンフェイルオーバーを使用することで、AWS オリジンまたは非 AWS カスタム HTTP オリジンの組み合わせの間でフェールオーバーロジックを簡単に設定できるようになり、視聴者のエクスペリエンスの中断は最小限に抑えられます。たとえば、2 つの Amazon S3 バケットをオリジンとして、個別にコンテンツをアップロードすることができます。CloudFront がプライマリバケットにリクエストするオブジェクトが存在しない場合、またはプライマリバケットへの接続がタイムアウトした場合、CloudFront はセカンダリバケットにオブジェクトをリクエストします。そのため、HTTP 4xx または 5xx ステータスコードのいずれかに応じてフェイルオーバーを開始するように CloudFront を設定できます。

この機能は追加料金なしで使用できます。CloudFront におけるオリジンフェイルオーバーの動作の詳細については、「デベロッパーガイド」をお読みになるか、当社ウェブページの「開始方法」をご覧ください。

Amazon CloudFront が WebSocket のサポートを発表

日付: 2018 年 11 月 20 日

詳細: 優れたパフォーマンスとセキュリティをエンドユーザーに提供できるように、WebSocket プロトコルを使用するアプリケーションで Amazon CloudFront を使用できるようになりました。

WebSocket は、リアルタイムの通信プロトコルであり、クライアント (ブラウザなど) と、長時間維持される TCP 接続経由のサーバーの間の双方向通信チャンネルを提供します。クライアントとサーバーで永続的なオープン接続を使用することにより、リアルタイムのデータを相互に送信することができます。新しいデータがやり取りされていることを確認するために、クライアントで頻繁に接続を再開する必要はありません。WebSocket 接続は、チャットアプリケーション、コラボレーションプラットフォーム、マルチプレイヤーゲーム、金融取引プラットフォームでよく使用されます。

WebSocket プロトコルは CloudFront をサポートしているため、他の動的コンテンツや静的コンテンツと同じ CloudFront リソースを介して WebSocket トラフィックを統合できるようになりました。CloudFront のグローバルエッジネットワークを使用して、ユーザーに近い WebSocket 接続の SSL/TLS ハンドシェイクを終了し、AWS の最適化ネットワークを活用してアプリケーションの応答性と信頼性を向上させることもできます。また、DDOS から包括的に保護するには、CloudFront と緊密に統合されている AWS Shield と AWS WAF を使用して、ソースに近い攻撃を軽減します。

WebSocket はグローバルに使用することができるため、デフォルトでサポートされている WebSocket プロトコルを CloudFront リソース内で有効にするために追加設定を行う必要はありません。WebSocket プロトコル経由でデータを送信するために追加料金はかかりません。CloudFront の標準料金が適用されます。

CloudFront における WebSocket の使用の詳細については、「デベロッパーガイド」をお読みになるか、当社ウェブページの「開始方法」をご覧ください。

Amazon CloudFront は北米、ヨーロッパ、アジアに 6 つの新しいエッジローケーションを発表

日付: 2018 年 11 月 6 日

詳細について: Amazon CloudFront は、6 つの新しいエッジローケーションを発表し、世界の主要都市にグローバルに展開しています。新しいエッジローケーションはハイデラバード (2) 、ニューデリー、ロンドン (2) 、ヒルズボロにあります。インドのハイデラバードとオレゴン州のヒルズボロは、最新のロケーションです。今回の立ち上げにより、CloudFront はインドとイギリスの平均要求処理能力を最大 55％ 向上させました。
これらのエッジロケーションを追加したことで、顧客の配送、性能、および規模が増大します。CloudFront のグローバルロケーションに関するすべてのリストは、CloudFront の主な機能の Web ページにあります。

Amazon CloudFront がアラブ首長国連邦で 2 つ目となるのロケーションを含む、新しいエッジロケーション 2 か所を発表

日付: 2018 年 10 月 12 日

詳細: Amazon CloudFront が新しいエッジロケーションを 2 か所発表: フジャイラ (アラブ首長国連邦)、パリ (フランス)。フジャイラは先月開始されたアラブ首長国連邦初のロケーションであるドバイに続いて 2 か所目となるエッジロケーションです。アラブ首長国連邦内でコンテンツを提供するお客様は、平均で最高 90% のレイテンシの改善を期待いただけます。パリに新しいエッジローケーションが追加されたことにより、フランスでは地域で 50% の容量増大になります。CloudFront のグローバルなロケーションの完全なリストは CloudFront の詳細ページからご覧いただけます。

Amazon CloudFront はニューデリー (インド) で 2 つ目となるエッジロケーションを開設

日付: 2018 年 9 月 12 日

詳細: Amazon CloudFront は、ニューデリー (インド) で 2 つ目となるエッジロケーションを追加することを発表しました。このロケーションの追加により、該当エリアにおいて、ビューワーリクエストの処理とコンテンツのローカルなキャッシュについて CloudFront のキャパシティーが 2 倍になります。CloudFront のグローバルネットワークの一覧は、CloudFront の詳細ウェブページを参照してください。

Amazon CloudFront がドバイ (アラブ首長国連邦) で 1 つ目となるエッジロケーションをローンチ

日付: 2018 年 9 月 4 日

詳細: Amazon CloudFront は、中東で 1 つ目となるエッジロケーションをドバイ (アラブ首長国連邦) に追加することを発表しました。CloudFront のグローバルネットワークの一覧は、CloudFront の詳細ウェブページを参照してください。

Amazon CloudFront がノルウェーとデンマークに最初のエッジロケーションを置いて北欧に進出

日付: 2018 年 8 月 15 日

詳細: Amazon CloudFront がノルウェーのオスロとデンマークのコペンハーゲンで 2 つの新たなエッジロケーションを発表。これら 2 つのエッジロケーションはそれぞれの国で最初のもので、北欧での CloudFront のキャパシティーを 55% 増加します。CloudFront の北欧での拡張により、このリージョンでのユーザーへのコンテンツデリバリーのアベイラビリティとパフォーマンスがさらに改善されます。新規ロケーション追加前の CloudFront のパフォーマンスに比べ、ノルウェーとデンマークでのコンテンツデリバリーのレイテンシーは 35% 削減されることを期待しています。

CloudFront のグローバルなロケーションの完全なリストは CloudFront の詳細ページからご覧いただけます。

Lambda@Edge で HTTP POST および PUT 処理のリクエストボディへのアクセスを提供開始

日付: 2018 年 8 月 14 日

詳細: Lambda@Edge は、お客様のエンドユーザーへ配信されたコンテンツをカスタマイズするため、URI を含むさまざまな HTTP 属性、ヘッダー、クエリ文字列へのアクセスを可能にします。今日から、Lambda 関数の HTTP リクエストボディにアクセスできるようになりました。これによって、エッジから直接カスタムロジックを実行し、応答を生成することができます。

デベロッパーは一般的に、ウェブ/HTML フォームあるいはウェブビーコン/バグといったメカニズムでエンドユーザーからデータを収集し、オリジンサーバーでそれらのデータを処理します。Lambda 関数からリクエストボディにアクセスをすることによって、こうしたロジックをエッジにオフロードし、エンドユーザー向けにレイテンシーを向上させることができます。例えば、「お問い合わせ」フォームのある静的ウェブサイトでは、Amazon DynamoDB のグローバルテーブルへのネットワークコールを実行し、Lambda 関数からデータを保存することができます。あるいは、ウェブサイトの Web ビーコンを使ってエンドユーザーの動作データを収集している場合、Lambda 関数から Amazon Kinesis Firehose のエンドポイントに直接ログ入力することによって、オリジンのインフラストラクチャを簡略化できます。

この機能は追加料金なしで使用できます。Lambda@Edge の詳細については、製品詳細ページを参照してください。この新しい機能の詳しい使用方法については、以下のリソースを参照してください。

Lambda 関数の例を参照し、リクエストボディについてアクセス方法と変更方法を確認して使用開始する

Amazon CloudFront、Lambda@Edge、Amazon Kinesis Firehose を使ってデータ取り込み用のグローバルパススルーを構築する方法についてブログ記事を参照する

詳細については、こちらからドキュメントを参照してください。

Amazon CloudFront が北アメリカ、ヨーロッパ、アジアの主要都市で新たに 9 つのエッジロケーションをグローバルに展開

日付: 2018 年 7 月 24 日

詳細: Amazon CloudFront が現在の主要都市に新たに 9 つのエッジロケーションをグローバルに展開することを発表しました。5 つの新しいエッジロケーションが北アメリカ (カリフォルニア州ロサンゼルス、カリフォルニア州サンノゼ、ニュージャージー州ニューアーク、テキサス州ダラス/フォートワース、フロリダ州マイアミ) に追加されました。3 つの新しいエッジロケーションがヨーロッパに展開されました。ロンドン (英国) に 2 つ、フランクフルト (ドイツ) に 1 つです。アジアでは 9 番目の都市である東京 (日本) に 1 つの新しいエッジロケーションが追加されました。

今回のリリースによって、北アメリカの 5 つの都市とヨーロッパの 2 つの都市で、CloudFront のリクエスト処理キャパシティーが平均 40% 向上します。

これらの新しいエッジロケーションの追加により CloudFront は更にグローバルに展開し、お客様への配信、パフォーマンス、規模が拡張されます。CloudFront のグローバルなロケーションの完全なリストは CloudFront の詳細ページからご覧いただけます。

Amazon CloudFront が南アフリカのケープタウンを含む新しい 4 か所のエッジロケーションを発表

日付: 2018 年 7 月 12 日

詳細: ケープタウン (南アフリカ)、コロラド州デンバー、フランクフルト (ドイツ)、台北 (台湾) の 4 つの新しいエッジロケーションが Amazon CloudFront に追加されました。ケープタウンは、南アフリカで 2 番目のエッジロケーションです。最初のエッジロケーションは、2018 年 6 月に追加されたヨハネスブルグです。南アフリカでコンテンツを配信するお客様には、既に平均で 75% のレイテンシーの短縮が見られています。コロラド州デンバーで新しいエッジロケーションを追加したことにより、デンバーでのキャパシティーが 2 倍になりました。フランクフルトの新しいエッジロケーションは、この都市で 7 番目のものです。また、台北については、これが 3 番目のエッジロケーションです。これらのロケーションの追加によって CloudFront のグローバルな規模とキャパシティーが拡大されるため、より優れたパフォーマンスとスケールをお客様に提供できます。

CloudFront のグローバルインフラストラクチャの完全なリストは、CloudFront の詳細ウェブページで確認できます。

Amazon CloudFront はアフリカのヨハネスブルグとバンガロールに初の新しいエッジロケーションを展開

日付: 2018 年 6 月 14 日

詳細: 2008 年 11 月に Amazon CloudFront を開始して以来、当社は世界中のインフラストラクチャリージョンを継続的に広げ、コンテンツ配信のパフォーマンスを向上させてきました。本日、南アフリカのヨハネスブルグとインドのバンガロールで新しいエッジロケーションを立ち上げたことをお知らせします。ヨハネスブルグのエッジロケーションは、Amazon CloudFront でアフリカ大陸における初の PoP (接続ポイント) です。この 2 つの場所の追加により、CloudFront のグローバルネットワークは、26 か国の 58 都市、119 ポイントにまで広がりました。

Amazon CloudFront の南アフリカへの展開により、そのリージョンのビューワーへのコンテンツ配信の可用性とパフォーマンスがさらに向上します。Amazon CloudFront を使用して南アフリカのビューワーにコンテンツを配信する顧客は、レイテンシーが最大 75% 削減され、パフォーマンス向上が期待されます。新しいバンガロールの PoP は、インドにおける CloudFront キャパシティーを最大 25% 増加することが期待されます。

レイテンシーを削減するだけでなく、これらのエッジロケーションは Lambda@Edge、Field Level Encryption、Amazon S3 Transfer Acceleration などの Amazon CloudFront が提供する一連の利点および AWS Certificate Manager (ACM)、AWS Shield、AWS WAF、AWS Simple Storage Service (S3)、Amazon Elastic Compute Cloud (EC2) などのその他 AWS 製品とのシームレスな統合も提供します。これらヨハネスブルグとバンガロールの新しいエッジロケーションは、最高機密データのセキュアな配信を確保するために PCI、DSS、HIPAA、ISO のすべてに準拠したインフラストラクチャとプロセスを含む世界中にある他の CloudFront エッジロケーションと同じ高い基準に従って構築されています。

新しい南アフリカのエッジロケーションを含む、CloudFront の価格設定についての情報は、料金表ページをご覧ください。

Amazon CloudFront は東京で 8 つ目となるエッジロケーションを開設

日付: 2018 年 5 月 30 日

詳細: Amazon CloudFront は、東京で 8 つ目となるエッジロケーションを追加することを発表しました。このエッジロケーションの追加により、CloudFront の地域内でのキャパシティーが引き続き拡大し、より多くの量のウェブトラフィックに対応できます。

CloudFront のグローバルネットワークの全リストは、CloudFront の詳細ウェブページをご覧ください。

Node.js v8.10 での Lambda@Edge のサポートを追加

日付: 2018 年 5 月 14 日

詳細: 本日より、従来サポートされていた Node.js v6.10 ランタイムに加え、Node.js v8.10 でも Lambda@Edge の関数を開発できるようになりました。

Node.js v8.10 は最新の Long Term Support (LTS) バージョンの Node で、新しい V8 6.0 エンジンを使用しています。このエンジンは、以前の LTS バージョンである 6.x と比較してパフォーマンスが向上しています。また、Node.js v8.10 では、async/await などの新機能サポートが追加されています。これは Node.js の非同期オペレーションの新しい処理方法です。これにより、非ブロッキング呼び出しをよりシンプル、簡潔、明瞭なコードで記述することができるようになります。Node.js v8.10 で導入された async/await 機能の利点について詳しくは、こちらのブログ投稿をご覧ください。

使用を開始するには、AWS CLI または Lambda コンソールを使用して、Node.js コードを AWS Lambda 関数としてアップロードし、Node.js 8.10 ランタイムを選択します。既存の Node.js 関数をお持ちの場合は、新しいランタイムとの互換性を確保するために必要なコード変更を行った後、関数設定を編集してランタイムを Node.js 8.10 に設定することで、新しいランタイムに切り替えることができます。

Lambda@Edge の詳細については、製品詳細ページを参照してください。Lambda の Node.js プログラミングモデルの詳細については、ドキュメントを参照してください。

Amazon CloudFront より、シンガポールで 3 か所目となるエッジロケーションと、台湾の台北で 2 か所目となるエッジロケーションが発表

日付: 2018 年 4 月 25 日

詳細: Amazon CloudFront より、シンガポールで 3 か所目となるエッジロケーションと、台湾の台北で 2 か所目となるエッジロケーションが発表されました。CloudFront のキャパシティーは、エッジロケーションが AWS インフラストラクチャに追加されるたびに増加します。これによって、世界中でセキュアなコンテンツを提供する際のレイテンシーが低減し、可用性が向上します。

CloudFront のグローバルインフラストラクチャの一覧は、CloudFront の詳細ウェブページで確認できます。

Lambda@Edge、リクエストヘッダーに基づくコンテンツ配信のカスタマイズの S3 オリジンによるサポートを追加

日付: 2018 年 3 月 20 日

詳細: 本日から、Lambda@Edge は、カスタムヘッダーを含み、オリジン向きのイベント内の追加のホワイトリストされたヘッダーへのアクセスができ、Amazon S3 に格納されたコンテンツの配信をさらにカスタマイズできるようになりました。例えば、Amazon CloudFront を設定して国別ヘッダーをお客様の S3 オリジンにキャッシュして転送し、Lambda@Edge を用いてビューワーの場所に応じてお客様のウェブサイトの国別バージョンに動的にリダイレクトできます。CloudFront はまた応答をキャッシュし、お客様のウェブサイトに次回のリクエストでのパフォーマンスを向上します。

今までは、Amazon CloudFront を S3 オリジンで設定して次の 3 つのヘッダーのみでオブジェクトを転送、キャッシュしていました: Access-Control-Request-Headers、Access-Control-Request-Method、Origin。このため、S3 バケットに格納されたコンテンツの配信をカスタマイズしたいときにクッキーとクエリしか使用できなかったため、Lambda@Edge の力を使いこなすことができませんでした。しかし、今回の追加により、CloudFront を S3 オリジンで設定して CloudFront-Viewer-Country や CloudFront-Is-*-Viewer などの他のいくつかのヘッダーもキャッシュ、転送できるようになり、それから Lambda@Edge を用いてこれらのヘッダーに基づいてカスタマイズし、ビューワーに低レイテンシーで配信できるようになりました。サポートされるヘッダーすべてを見るには、ここをクリックしてください。

この新機能は追加料金なしで使用できます。Lambda@Edge の詳細については、製品詳細ページを参照してください。この新しい機能の詳しい使用方法については、以下のリソースを参照してください。

• ビューワーロケーションおよびビューワーデバイスタイプに基づいたコンテンツのパーソナライズを示す例。
• ヘッダーを用いたコンテンツベースの動的オリジン選択を示す例。 

CloudFront がオリジンに対する HTTPS 接続のための ECDSA 証明書をサポートするようになりました

日付: 2018 年 3 月 15 日

詳細: 本日より、Elliptic Curve Digital Signature Algorithm (ECDSA) を使ってオリジンへの HTTPS 接続をネゴシエートするために Amazon CloudFront を使用できるようになりました。ECDSA はより高速でありながら、旧型の RSA アルゴリズムと同様にセキュアな小型のキーを使用します。小型のキーは、オリジンが 1 秒ごとに処理できる TLS ハンドシェイクの数も増加させることから、コンピューティングサイクルを節約し、暗号化コストを削減します。ECDSA は、ECDSA 証明書を使用または優先するようにオリジンサーバーを設定するだけで有効化できます。この機能は追加料金なしで使用できます。

ECDSA が CloudFront でどのように機能するかに関する詳細については、こちらのブログ記事と CloudFront のデベロッパーガイドをご覧ください。

Amazon CloudFront が韓国ソウルに 4 番目のエッジロケーションを設置

日付: 2018 年 2 月 19 日

詳細: Amazon CloudFront は韓国ソウルに新しいエッジロケーションの追加を発表しました。これにより、韓国ではソウルにあるエッジロケーションの数が 4 か所になりました。この新しいエッジロケーションの追加により、CloudFront の地域内でのキャパシティーが引き続き拡大し、より多くの量のウェブトラフィックに対応できます。

CloudFront のグローバルインフラストラクチャの完全なリストは、CloudFront の詳細ウェブページで確認できます。

Amazon CloudFront、東京 (日本) に 2 か所、パース (オーストラリア) 初のロケーションを追加した 6 か所の新エッジロケーションを発表

日付: 2018 年 1 月 5 日

詳細: Amazon CloudFront は、そのグローバルネットワークの一部となる 6 か所の新しいエッジロケーションを発表しました。これら 6 か所の新しいエッジロケーションの所在地は以下のとおりです。

パース (オーストラリア)、チェンナイ (インド)、リオデジャネイロ (ブラジル)、カリフォルニア州ロサンゼルス (米国)、東京 (日本) に追加された 2 か所のエッジロケーション。

CloudFront のグローバルインフラストラクチャの完全なリストは、CloudFront の詳細ウェブページで確認できます。

Lambda@Edge でオリジンからのエラー応答をカスタマイズできるようになりました

日付: 2017 年 12 月 21 日

詳細: 本日から Lambda@Edge で、Amazon CloudFront がオリジンから受け取る HTTP エラーに対してラムダ関数を実行できるようにすることで、オリジンからのエラー応答をカスタマイズできるようになりました。これは、現在サポートされている 2XX (成功) および 3XX (リダイレクション) ステータスコードに加えて、Amazon CloudFront オリジンの応答イベントに関連付けられた Lambda@Edge 関数が、4XX および 5XX エラーステータスコードに対して呼び出されるようになったことを意味します。

詳細については、お知らせのページを参照してください。

Amazon CloudFront でのフィールドレベル暗号化のご紹介

日付: 2017 年 12 月 14 日

詳細: 本日から、新しい Amazon CloudFront 機能であるフィールドレベル暗号化を使用して、クレジットカード番号や社会保障番号のような個人を識別できる情報 (PII) など、機密データのセキュリティをより強化できるようになりました。CloudFront のフィールドレベル暗号化では、フィールド固有の暗号化キー (お客様指定) を使用して、POST リクエストがお客様のオリジンに転送される前に HTTPS 内で機密データをさらに暗号化します。これにより、機密データはお客様のアプリケーションスタックの特定のコンポーネントまたはサービスでのみ、復号化および表示できます。

詳細については、お知らせのページを参照してください。

Amazon CloudFront が 6 つのエッジロケーションを追加し、4 つの新しい都市に拡大

日付: 2017 年 11 月 22 日

詳細: 本日、Amazon CloudFront のグローバルコンテンツ配信ネットワークに 6 つの新しいエッジロケーションの追加が発表されました。新しいエッジロケーションは、ヘルシンキ (フィンランド)、マドリード (スペイン)、マンチェスター (英国)、デンバー (コロラド)、ニューアーク (ニュージャージー)、フェニックス (アリゾナ) に設置されます。

これらのエッジロケーションのうち 4 つ (ヘルシンキ、マンチェスター、デンバー、フェニックス) で、CloudFront のネットワークに新しい都市が追加され、6 つの各エッジロケーションで、追加のキャパシティーがそのリージョン内で提供されます。CloudFront のグローバルインフラストラクチャの完全なリストは、CloudFront の詳細ウェブページで確認できます。

Amazon CloudFront の詳細については、開始方法のウェブページで近日開催のオンラインセミナーと便利なリソースをご覧ください。

Lambda@Edge で、コンテンツベースの動的なオリジン選択、ビューワーイベントからのネットワーク呼び出し、および高度なレスポンス生成をサポート

日付: 2017 年 11 月 21 日

詳細: 本日より、Lambda@Edge で 3 つの新機能を使用できるようになりました。これは、ビューワー向けにパーソナライズされたコンテンツを構築すると同時に、レイテンシー改善とオリジンインフラストラクチャの簡素化を実現するのに役立ちます。まず、コンテンツベースの動的オリジン選択では、ビューワーのロケーション、ビューワーのデバイスタイプ、HTTP ヘッダー、URL パス、クエリ文字列、Cookie といったリクエスト属性に基づいて、リクエストを異なるバックエンドオリジンサーバーにルーティングできます。2 番目に、Amazon CloudFront のビューワー向けイベントからのリモートネットワークコールが可能になりました。3 番目に、Lambda@Edge 関数からバイナリデータを生成できます。これにより、Amazon CloudFront を使用してさらに豊富でカスタマイズされたコンテンツを配信できるようになります。また、Lambda@Edge 関数の上限値も引き上げられました。最大 1536 MB のメモリの選択、最大 50 MB の大型パッケージのデプロイ、最大 30 秒まで延長されたタイムアウト値での Lambda@Edge 関数の実装が可能です。

詳細については、お知らせのページを参照してください。

Amazon CloudFront では、パレルモ (イタリア) に初のエッジロケーションを開設したことにより、接続ポイント数が 101 に達しました。

日付: 2017 年 11 月 6 日

詳細: 弊社では、先週 100 番目の接続ポイントについて発表したばかりですが、本日、Amazon CloudFront のネットワークに新しい都市が加わり、パレルモ (イタリア) で初のエッジロケーションが開始します。ミラノと合わせて、イタリアのエッジロケーション数は 2 つになります。現在 Amazon CloudFront のネットワークには、90 のエッジロケーションと 11 のリージョン別エッジキャッシュによって構成された 101 の接続ポイントがあります。新しい都市パレルモ (イタリア) の追加に続き、今後数か月の間にネットワークの新規拡大が多数発表される予定です。

Amazon CloudFront の詳細と利用開始方法については、弊社ウェブページの近日開催のオンラインセミナーに関する記事をご覧ください。

Amazon CloudFront には現在 100 の接続ポイントがありますが、5 番目のエッジロケーションを日本の東京で開始しました。

日付: 2017 年 10 月 31 日

詳細: 約 9 年前、アマゾン ウェブ サービス (AWS) は自社のグローバルコンテンツ配信ネットワーク (CDN) である Amazon CloudFront の提供開始を発表しました。14 の接続ポイントを持つ新しい高性能エッジネットワークとして始まった Amazon CloudFront は現在、世界中の何百万ものビューワーをサポートするまでに成長しました。本日、Amazon CloudFront の最も成長著しい国の 1 つである日本で、100 番目の接続ポイント (89 のエッジロケーションと 11 のリージョン別エッジキャッシュ) を発表できることを嬉しく思います。この 100 番目の接続ポイント (POP) は、東京で 5 番目の、そして日本で 6 番目のエッジロケーションでもあります。

Amazon CloudFront の 100 か所の接続ポイントは世界中の 23 か国 50 都市に展開されています。過去 1 年に、弊社は 37 のロケーションを追加し、ネットワーク規模を 50% 以上拡張しました。それには新たな 9 都市と 4 か国*が含まれます。ベルリン (ドイツ)、ミネアポリス (米国ミネソタ州)、プラハ (チェコ共和国)*、ボストン (米国マサチューセッツ州)、ミュンヘン (ドイツ)、ウィーン (オーストリア)*、クアラルンプール (マレーシア)*、フィラデルフィア (米国ペンシルベニア州)、チューリッヒ (スイス)* などです。

2016 年の re:Invent カンファレンスでは、弊社のネットワークに 11 の接続ポイントを追加する、リージョン別エッジキャッシュという新しいタイプのキャッシングレイヤーを発表しました。これらのロケーションは、従来のエッジロケーションよりもキャッシュ幅が大きく、エッジロケーションとお客様のオリジンサーバーとの間に位置しています。これにより、ビューワーのより近くでより長くお客様のコンテンツをキャッシュできるため、お客様のオリジンの負荷が軽減され、オリジンフェッチが高速化されます。

世界中のあらゆる規模のお客様と協力できることを光栄に思います。個人のブロガーや小規模企業から世界の大企業に至るまで、1 人 1 人が大切なお客様です。そのような皆さまに弊社のグローバルネットワークの一翼を担っていただけることに感謝申し上げます。

ありがとうございます。

- Amazon CloudFront チーム

Amazon CloudFront の詳細と利用開始方法については、弊社ウェブページの近日開催のオンラインセミナーに関する記事をご覧ください。

Amazon CloudFront で、フロリダ州マイアミの 99 番目の接続ポイントとその 2 つ目のエッジロケーションの追加が発表されました。

日付: 2017 年 10 月 30 日

詳細: Amazon CloudFront チームは、フロリダ州マイアミの 99 番目の接続ポイントとその 2 つ目のエッジロケーションの追加を発表しました。Amazon CloudFront の 99 の接続ポイントには、88 のエッジロケーションと 11 のリージョン別エッジキャッシュがあります。このネットワークにより、世界 23 か国 50 都市を網羅しています。Amazon CloudFront の詳細と利用開始方法については、弊社ウェブページの近日開催のオンラインセミナーに関する記事をご覧ください。

Amazon CloudFront では、引き続き北欧、西欧、米国西部のキャパシティーを強化していきます。新しいロケーションとしてストックホルム、ロンドン、ダラスが追加されました。

日付: 2017 年 10 月 11 日

詳細: Amazon CloudFront チームは、ストックホルム、ロンドン、ダラスの 3 つの接続ポイントの追加を発表できることを嬉しく思います。ストックホルムには現在 3 つの接続ポイントがあります。ロンドンは 5 つ、ダラスは 4 つあります。 これら 3 つのネットワークの追加により、引き続き各リージョンでの Amazon CloudFront のキャパシティーが拡張され、信頼性の高い、安全で迅速なエンドユーザー体験が確保されます。

今回の追加により、Amazon CloudFront の接続ポイントは 23 か国 50 都市に 98 か所 (87 のエッジロケーションと 11 のリージョン別エッジキャッシュ) となりました。CloudFront の拠点の詳細なリストについては、こちらのウェブサイトをご覧ください。今後のオンラインセミナーで CloudFront チームと交流してください。

Lambda@Edge でクエリ文字列パラメータ、国、デバイスタイプヘッダーが利用可能に

日付: 2017 年 10 月 10 日

詳細: Lambda@Edge により、低いレイテンシーでコンテンツをパーソナライズでき、オリジンサーバーを管理する必要はありません。本日より、Lambda@Edge では、リクエストの追加属性が利用できるようになり、コンテンツをより簡単にパーソナライズできます。AWS Lambda 関数のクエリ文字列パラメータ、国、デバイスタイプヘッダーを利用できるようになりました。例えば、この機能により、リクエストが行われたエンドユーザーのロケーションに基づいて、特定の国または言語のバージョンのウェブサイトにエンドユーザーをリダイレクトできます。

この機能に追加費用は発生しません。Lambda@Edge の詳細については、製品詳細ページを参照してください。この新機能の使用方法に関する詳細については、以下のリソースを参照してください。

• エンドユーザーロケーションとエンドユーザーデバイスタイプに基づいたコンテンツのパーソナライズを示す例。
• クエリ文字列パラメータの利用方法の詳細。

Amazon CloudFront で、セキュリティポリシーに TLS v1.1、v1.2 を最低バージョンとして選択したり、ビューワー接続のセキュリティ暗号を選択したりすることが可能になりました。

日付: 2017 年 9 月 27 日

詳細: 本日より、最低プロトコルバージョン (TLS バージョン 1.1 または 1.2) を強化する、事前定義されたセキュリティポリシーを選択することで、Amazon CloudFront で実行されるウェブアプリケーションのセキュリティをさらに向上させることが可能になりました。Amazon CloudFront 側で、選択したセキュリティポリシーに合わせた暗号化方式が自動で選択されるようになります。これは、HTTPS 経由でコンテンツをビューワーに返す前に、コンテンツを暗号化するために使用されます。例えば、この機能により、TLS バージョン 1.1 を強化するセキュリティポリシーを選択し、RC4 や 3DES などの脆弱な暗号を自動的に除外できます。SNI を使用して HTTPS リクエストに応答するために独自 SSL 証明書を使用する場合に、この機能をご利用いただけます。

独自 SSL 証明書を使用し、SNI を使用して HTTPS リクエストに応答するように設定されている既存のすべての CloudFront ディストリビューションでは、デフォルトで TLS バージョン 1.0 が使用され、すべてのサポートされている暗号 (RC4 を除く) が使用されます。CloudFront コンソールや API を使用して、ディストリビューションのセキュリティポリシーを変更することが可能です。この機能は、CloudFront に接続されるビューワーの SSL ハンドシェイクに適用されることにご注意ください。CloudFront とカスタムオリジン間のハンドシェイクに、TLS の最低バージョンを 1.1 または 1.2 に設定することは、これまで既に可能でした。

この機能に追加費用は発生しません。TLS の最低バージョンと関連する暗号化方式を強化するセキュリティポリシーについて詳しくは、CloudFront ドキュメントをご覧ください。

Amazon CloudFront でマサチューセッツ州ボストンに初のエッジロケーション、ワシントン州シアトルに 3 番目のエッジロケーションを追加

日付: 2017 年 9 月 22 日

詳細: Amazon CloudFront チームから、マサチューセッツ州ボストンに初のエッジロケーションが追加されたことが発表されました。 この新たな都市に加えて、ワシントン州シアトルに 3 番目のエッジロケーションが追加されました。これらの新たなエッジロケーションにより、引き続き CloudFront のパフォーマンスを向上させることができ、エンドユーザーにより高速で信頼性の高いサービスを提供できます。

今回の追加により、Amazon CloudFront の接続ポイントは 23 か国 50 都市に 95 か所 (84 のエッジロケーションと 11 のリージョン別エッジキャッシュ) となりました。詳細については、お知らせのページを参照してください。

シカゴとフランクフルトに Amazon CloudFront 用のエッジロケーションを追加

日付: 2017 年 8 月 11 日

詳細: イリノイ州シカゴとフランクフルト (ドイツ) に Amazon CloudFront 用のエッジロケーションが 2 つ追加されました。シカゴには現在 2 つ、フランクフルトには 6 つのエッジロケーションがあります。新しいエッジロケーションの追加により、お客様のアプリケーションのエンドユーザーに対する CloudFront のパフォーマンスと可用性がさらに向上します。

この 2 つのロケーションの追加により、Amazon CloudFront のロケーション数は合計 93 (82 のエッジロケーションと、11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

パリ (フランス) に Amazon CloudFront 用の 3 つ目のエッジロケーションを追加

日付: 2017 年 8 月 4 日

詳細: パリ (フランス) に 3 つ目のエッジロケーションが追加されました。 これで、Amazon CloudFront のエッジロケーションは合計で 91 (80 のエッジロケーションと 11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

ストックホルム (スウェーデン) に Amazon CloudFront 用の 2 つ目のエッジロケーションを追加

日付: 2017 年 7 月 21 日

詳細: ストックホルム (スウェーデン) に Amazon CloudFront 用の新しいエッジロケーションが追加されました。これは、ストックホルム地域で 2 番目のエッジロケーションであり、これで CloudFront のロケーションの数は合計 90 (79 の接続ポイントと、11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

クアラルンプール (マレーシア初) に Amazon CloudFront および Amazon Route 53 用の新しいエッジロケーションを追加

日付: 2017 年 7 月 20 日

詳細: Amazon CloudFront および Amazon Route 53 用の新しいエッジロケーションがクアラルンプールに追加されました。これはマレーシアで初めてエッジロケーションです。マレーシアにこのロケーションを追加したことにより、Amazon CloudFront のロケーション数は合計 89 (78 の接続ポイントと、11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

Lambda@Edge の一般公開を開始

日付: 2017 年 7 月 17 日

Lambda@Edge がすべてのお客様に一般公開されました。新しい AWS Lambda の機能を使用すると、世界中の AWS エッジロケーションで Node.js 関数を実行できます。サーバーのプロビジョニングや管理の必要がなく、各エンドユーザーにパーソナライズされた豊富なコンテンツを、低いレイテンシーで配信できます。

作成したコードを AWS Lambda にアップロードし、Amazon CloudFront の各イベント (ビューワーのリクエスト、ビューワーの応答、オリジンのリクエスト、オリジンの応答) でトリガーされるよう設定するだけで、作業は完了です。CloudFront で受信した関連リクエストは、ビューワーに近く、実行に最適な AWS エッジロケーションにルーティングされます。続いて、Lambda@Edge によりコードが実行され、CloudFront のグローバルネットワーク全体のリクエストのボリュームに応じてスケールされます。Lambda@Edge を使用してコードを実行することにより、個別のリクエストに基づいてウェブページをカスタマイズできます。また、カスタム認証ロジックを作成してグローバルに実行でき、安全なカスタムヘッダーを簡単に配信することができます。さらに、リモートネットワークの呼び出しを実行して、オリジン向けのイベントでインターネットのリソースにアクセスできるようになりました。また、動的なウェブコンテンツを、リクエストに応じてゼロからリアルタイムでインライン生成することもできます。この機能全体を活用することにより、各エンドユーザーにパーソナライズされた豊富なコンテンツを、低いレイテンシーで配信できます。

現在、Lambda@Edge 関数は米国東部 (バージニア北部) で作成できるようになっています。今後、CloudFront のイベントに対する応答の呼び出しのため、グローバルにレプリケートされます。

デベロッパー向けの Lambda@Edge の活用方法の詳細については、ドキュメントを参照してください。

Amazon CloudFront が HIPAA 対応サービスに

日付: 2017 年 6 月 1 日

AWS では HIPAA 準拠プログラムを拡張し、Amazon CloudFront を HIPAA 対応サービスとして追加しました。 AWS と事業提携契約 (BAA) を締結している場合は、Amazon CloudFront を使用して、保護された医療情報 (PHI) の配信を加速することができます。AWS での HIPAA 準拠サービスについては HIPAA コンプライアンスページをご覧ください。

AWS ですでに BAA を行っている場合は、BAA に対応しているアカウントで今すぐ Amazon CloudFront をご利用いただけます。AWS でまだ BAA を行っていない場合または AWS での HIPAA 準拠サービスに関するご質問があれば、こちらにご連絡ください。AWS 日本担当チームが対応いたします。

Amazon CloudFront および AWS でヘルスケアアプリケーションを構築する方法の詳細については、Amazon CloudFront ドキュメントと、AWS クラウドコンピューティングのヘルスケアのページをご覧ください。

ワシントン州シアトルに Amazon CloudFront 用の 2 つ目のエッジロケーションを追加

日付: 2017 年 5 月 23 日

詳細: ワシントン州シアトルに Amazon CloudFront 用の新しいエッジロケーションが追加されました。新しいエッジロケーションが稼働するたびに、お客様のアプリケーションのエンドユーザーに対するパフォーマンスと可用性の向上につながります。これは、シアトル地域で 2 番目のエッジロケーションであり、これで CloudFront のロケーションの数は合計 88 (77 の接続ポイントと、11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

Amazon CloudFront の新しいエッジロケーションに東京とテキサス州ダラス/フォートワースを追加

日付: 2017 年 5 月 9 日

詳細: Amazon CloudFront の新しいエッジロケーションに東京とテキサス州ダラス/フォートワースが追加されました。新しいエッジロケーションが稼働するたびに、お客様のアプリケーションのエンドユーザーに対するパフォーマンスと可用性の向上につながります。詳細については、お知らせのページを参照してください。

ジョージア州アトランタに Amazon CloudFront 用の 3 つ目のエッジロケーションを追加  

日付: 2017 年 4 月 21 日

詳細: ジョージア州アトランタに Amazon CloudFront 用の新しいエッジロケーションが追加されました。新しいエッジロケーションが稼働するたびに、お客様のアプリケーションのエンドユーザーに対するパフォーマンスと可用性の向上につながります。これは、アトランタ地域で 3 番目のエッジロケーションであり、これで CloudFront のロケーションの数は合計 85 (74 の接続ポイントと、11 のリージョン別エッジキャッシュロケーション) となりました。詳細については、お知らせのページを参照してください。

Amazon CloudFront カスタムオリジンのリードタイムアウトとキープアライブタイムアウトの値を設定する

日付: 2017 年 3 月 30 日

詳細: 本日より、Amazon CloudFront でカスタムオリジンとの通信時に使用される、リードタイムタイムアウトとキープアライブタイムアウトの値を設定できるようになりました。アプリケーションのニーズに応じてそれぞれの値を増減できます。詳細については、お知らせのページを参照してください。

スイス初となるチューリッヒの新しいエッジロケーションについてのお知らせ

日付: 2017 年 3 月 15 日

詳細: 新しいエッジロケーションがチューリッヒに追加されたことをお知らせします。これはスイス初のエッジロケーションです。チューリッヒに新しいエッジロケーションを追加したことにより、Amazon CloudFront のエッジロケーションは、全世界で合計 73 か所となりました。詳細については、お知らせのページを参照してください。

チェコ共和国初となるプラハの新しいエッジロケーションについてのお知らせ

日付: 2017 年 3 月 8 日

詳細: 新しいエッジロケーションがプラハに追加されました。これはチェコ共和国初のエッジロケーションです。プラハに新しいエッジロケーションを追加したことにより、Amazon CloudFront のエッジロケーションは、全世界で合計 72 か所となりました。詳細については、お知らせのページを参照してください。

新しい Amazon CloudFront のエッジロケーションがペンシルベニア州フィラデルフィアに

日付: 2017 年 2 月 24 日

詳細: Amazon CloudFront 用の新しいエッジロケーションが、ペンシルベニア州フィラデルフィアに追加されました。フィラデルフィアにエッジロケーションが追加されたことで、エッジロケーションの合計数は、米国で 24、全世界で 71 となりました。詳細については、お知らせのページを参照してください。

Lambda@Edge で Response Generation と Custom Logging のサポートを追加

日付: 2017 年 2 月 8 日

詳細: Lambda@Edge 関数では、Response Generation と Custom Logging の 2 つの新しい機能をサポートするようになりました。Lambda@Edge では、エンドユーザーが AWS エッジロケーションにリクエストを送信した場合に、それに対する HTTP 応答を生成するための Lambda 関数を、Response Generation を使用して記述できるようになりました。さらに、Lambda@Edge 関数にカスタマイズされたログ記録ステートメントを追加し、そのログを Amazon CloudWatch に記述できるようになりました。これにより、エッジロケーションで実行される Lambda@Edge 関数のデバッグとモニタリングを行えます。詳細については、お知らせのページを参照してください。プレビュー版にサインアップするには、Lambda@Edge プレビューのページを参照してください。

オーストリア初となるウィーンの新しいエッジロケーションについてのお知らせ

日付: 2017 年 2 月 7 日

詳細: 新しいエッジロケーションがウィーンに追加されたことをお知らせします。これはオーストリア初のエッジロケーションです。ウィーンに新しいエッジロケーションが追加されたことにより、Amazon CloudFront では世界各地の 70 のエッジロケーションがご利用いただけます。詳細については、お知らせのページを参照してください。

ドイツで 7 番目のエッジロケーションとなる Amazon CloudFront 用の新しいミュンヘンエッジロケーションを発表

日付: 2017 年 1 月 25 日

詳細: Amazon CloudFront 用の新しいエッジロケーションが、ミュンヘン (ドイツ) に追加されました。ミュンヘンロケーションは、フランクフルト、ベルリンに次ぐドイツにおける 3 番目のロケーションであり、7 番目のエッジロケーションとなります。これにより、世界のエッジロケーションの数は 69 となります。詳細については、お知らせのページを参照してください。

Lambda@Edge をプレビューで紹介 – ユーザーに最も近い AWS のエッジロケーションで Lambda 関数を実行する

日付: 2016 年 12 月 1 日

詳細: 現在プレビューで利用可能な Lambda@Edge を使用すると、CloudFront に応答してエッジロケーションの AWS ネットワークにデプロイされた関数を記述できます。この新機能により、ネットワークレイテンシーを最小限に抑えながら、エンドユーザーの近くでコンテンツをカスタマイズまたはパーソナライズできます。例えば、HTTP ヘッダーを変更して各ユーザー向けのアプリケーションをパーソナライズしたり、カスタム認証や暗号化ロジックをエッジで実装したり、デバイスごとにユーザーを検出またはグループ化したり、ビューワーの応答でコンテンツを再フォーマットしてレガシーデバイスをサポートしたりできます。

Lambda@Edge は Amazon CloudFront と統合されており、CloudFront イベントをトリガーとして使用して AWS のエッジロケーションで関数を自動的に実行します。サーバーの実行や管理は必要ありません。ただ Lambda コンソールを使用して Node.js 関数を記述およびアップロードし、CloudFront のトリガーイベントを選択するのみです。Lambda@Edge がエンドユーザーに最も近いエッジロケーションに関数を配布します。Lambda と同じように、関数が実行されるたびに、また実際に使用したコンピューティングの時間に対してのみ請求されます。関数を実行していないときは課金されません。

Lambda@Edge の詳細についてはこちらをクリックしてください。詳細およびサービスの制限については CloudFront デベロッパーガイドを参照してください。パブリックプレビューにサインアップするには、こちらをクリックしてください。 

Amazon CloudFront 用のリージョン別エッジキャッシュを発表

日付: 2016 年 11 月 29 日

詳細: 本日、ビューワーに対するパフォーマンスをさらに向上させるのに役立つ、リージョン別エッジキャッシュと呼ばれる新しいタイプのエッジロケーションが Amazon CloudFront に追加されたことをお知らせします。リージョン別エッジキャッシュを利用すると、パフォーマンスを向上させながらオリジンリソースの負荷を軽減し、スケーリングに関連した運用上の負担とオリジンコストを最小限に抑えることができます。新しい 9 つのリージョン別エッジキャッシュロケーションはバージニア北部、オレゴン、サンパウロ、フランクフルト、シンガポール、ソウル、東京、ムンバイ、シドニーにあります。

リージョン別エッジキャッシュは、CloudFront ディストリビューションではデフォルトで設定されてるため、この機能を利用するためにお客様の CloudFront ディストリビューションを変更する必要はありません。また、この機能の使用に追加料金は発生しません。詳細については、お知らせのページを参照してください。

Amazon CloudFront の新しいエッジロケーションとして、ミネソタ州ミネアポリス、ベルリン (ドイツ)、ダブリン (アイルランド)、ロンドン (英国) (4) が追加されました。

日付: 2016 年 11 月 23 日

詳細: ミネソタ州ミネアポリスとベルリン (ドイツ) の新しいエッジロケーションについて発表できることをうれしく思います。また、ロンドン (英国) にも 4 番目のエッジロケーションが追加されました。これにより、世界のエッジロケーションの数は 68 になりました。詳細については、お知らせのページを参照してください。

Amazon CloudFront 向けに香港で 3 番目のエッジロケーションを発表

日付: 2016 年 11 月 18 日

詳細: 香港に Amazon CloudFront 用の新しいエッジロケーションが追加されました。これは、香港で 3 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 65 となりました。詳細については、お知らせのページを参照してください。

日本で 4 番目の Amazon CloudFront 用エッジロケーションを発表

日付: 2016 年 11 月 11 日

詳細: 東京 (日本) (アジアパシフィック) に Amazon CloudFront 用の新しいエッジロケーションが追加されました。東京では 3 番目、日本では 4 番目のエッジロケーションです。これでエッジロケーションの数は世界中で合計 64 になります。詳細については、お知らせのページを参照してください。

AWS Certificate Manager を使って自分の SSL/TLS 証明書を使用可能に

日付: 2016 年 10 月 21 日

詳細: AWS Certificate Manager (ACM) を使用して、数分で、サードパーティー認証機関 (CA) により発行された SSL/TLS 証明書をインポートし、CloudFront ディストリビューションに関連付けられるようになりました。AWS マネジメントコンソールを使用して、インポートされた証明書の有効期限をモニタリングし、新しいサードパーティーの証明書をインポートして、期限が切れるものと置き換えられます。証明書のインポートには一切費用がかかりません。お支払いいただくのは、アプリケーションを実行するために利用した AWS リソースの料金のみです。CloudFront では、Identity and Access Management (IAM) 証明書ストアにアップロードした証明書の使用も引き続きサポートされます。証明書インポートの前提条件の詳細については、ACM のお知らせとドキュメントを確認してください。

Amazon CloudFront の Internet Protocol Version 6 (IPv6) サポートを発表

日付: 2016 年 10 月 6 日

詳細: 本日より、Amazon CloudFront で HTTP/HTTPS を使用して IPv6 と IPv4 の両方によるコンテンツ配信が可能になりました。

IPv6 は、本日以降、新しく作成されるすべての Amazon CloudFront ウェブディストリビューションではデフォルトで有効になります。既存のウェブディストリビューションについては、Amazon CloudFront コンソールまたは API から IPv6 を有効にすることができます。IPv6 経由で Amazon CloudFront エッジロケーションに接続するビューワーやネットワークには、自動的に IPv6 経由でコンテンツが配信されます。IPv4 経由で接続するビューワーやネットワークも引き続き使用可能です。オリジンサーバーへの接続は IPv4 のままです。

本日より段階的に、すべての自律システム (AS) で IPv6 が有効になり、今後数週間以内にすべてのネットワークで展開が完了する予定です。Amazon CloudFront の IPv6 サポートの詳細については、Amazon CloudFront デベロッパーガイドとよくある質問を参照してください。

フランクフルト (ドイツ) に Amazon CloudFront 用の 2 つの新しいエッジロケーションを追加

日付: 2016 年 9 月 23 日

詳細: フランクフルト (ドイツ) に Amazon CloudFront 用の 2 つの新しいエッジロケーションが追加されました。これでフランクフルト市のエッジロケーションは 5 つになり、世界各地にあるエッジロケーションの数は合計 63 となりました。詳細については、お知らせのページを参照してください。

ムンバイ (インド) (アジアパシフィック) に Amazon CloudFront 用の 2 つ目のエッジロケーションを追加

日付: 2016 年 9 月 19 日

詳細: ムンバイ (インド) (アジアパシフィック) に Amazon CloudFront 用の新しいエッジロケーションが追加されました。これは、ムンバイで 2 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 61 となりました。詳細については、お知らせのページを参照してください。

ジョージア州アトランタに Amazon CloudFront 用の 2 つ目のエッジロケーションを追加

日付: 2016 年 9 月 12 日

詳細: ジョージア州アトランタに Amazon CloudFront 用の新しいエッジロケーションが追加されました。これは、アトランタで 2 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 60 となりました。詳細については、お知らせのページを参照してください。

Amazon CloudFront が HTTP/2 に対応

日付: 2016 年 9 月 7 日

詳細: Amazon CloudFront ディストリビューションで HTTP/2 を有効にできるようになりました。これにより、新しい HTTP/2 プロトコルに対応しているクライアントに配信されるウェブコンテンツのパフォーマンスが向上します。

HTTP/2 は HTTP のアップグレードバージョンで、多重化、ヘッダー圧縮、ストリームの優先度により、ページの読み込みとレンダリングが高速化しています。新規の Amazon CloudFront ディストリビューションすべてについては、デフォルトで HTTP/2 が有効になっています。既存のディストリビューションについては、HTTP/2 を有効にするよう、ディストリビューションの設定を編集できます。この機能を使用するのに追加料金はかかりません。また、HTTP/2 に対応していないクライアントと HTTP/2 を有効にした Amazon CloudFront ディストリビューションとの間の通信には、引き続き HTTP/1.1 を使用できます。

HTTP/2 の詳細については、Amazon CloudFront デベロッパーガイドの「対応している HTTP のバージョン」をご覧ください。

Amazon CloudFront のクエリストリングホワイトリストを発表

日付: 2016 年 8 月 30 日

詳細: Amazon CloudFront では、すべてのパラメータをオリジンに転送しつつ、Amazon CloudFront がキャッシュのために使用するクエリストリングパラメータのホワイトリストを指定できるようになりました。選択されたクエリストリングパラメータに基づいてキャッシュを実行することで、キャッシュのヒット率が向上し、オリジンの負荷が軽減されます。その結果、エンドユーザーのパフォーマンスが大幅に向上します。

クエリストリングホワイトリストの詳細については、Amazon CloudFront デベロッパーガイドの「クエリ文字列パラメータに基づいてキャッシュするように CloudFront を設定する」を参照してください。Amazon CloudFront の詳細については、Amazon CloudFront 製品ページを参照してください。

Amazon CloudFront のコスト配分タグ付けを発表

日付: 2016 年 8 月 9 日

詳細: Amazon CloudFront ディストリビューションにコスト配分タグを追加できるようになったことをお知らせいたします。タグを使用すると、AWS リソースの分類とグループ化によるコスト配分や経費の削減が簡単になります。例えば、タグを使用して、管理者、アプリケーション名、コストセンター、または特定のプロジェクトごとにリソースをグループ化できます。

コスト配分タグ付けの詳細については、コスト配分タグの使用を参照してください。CloudFront ディストリビューションにタグを追加する準備が整ったら、Amazon CloudFront にタグを追加ページを参照してください。

カナダで初めての新しいエッジロケーションとしてモントリオールとトロントを追加

日付: 2016 年 8 月 8 日

詳細: カナダで初めてのエッジロケーションとして、モントリオールとトロントで最新のエッジロケーションが開設されました。また、ブラジルで 3 番目のエッジロケーションとして、サンパウロで 2 番目のエッジロケーションが追加されました。

カナダで初めてのエッジロケーション 2 か所とサンパウロで 2 番目のエッジロケーションを追加したことにより、Amazon CloudFront のエッジロケーションは、全世界で合計 59 か所となりました。Amazon CloudFront の世界各地のエッジロケーションのリストについては、こちらを参照してください。サービスの詳細については、登録のうえ、マンスリーオフィスアワーセッションにご参加ください。セッションには、Amazon CloudFront のエンジニアやプロダクトマネージャーとの質疑応答も含まれています。 

Amazon CloudFront 用にニューデリー (インド) で新しいエッジロケーションを開始

日付: 2016 年 6 月 14 日

詳細: Amazon CloudFront および Amazon Route 53 用の新しいエッジロケーションが、ニューデリー (インド) に追加されました。ニューデリーのロケーションは、インドで (ムンバイとチェンナイに続き) 3 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 56 となりました。Amazon CloudFront の世界各地のエッジロケーションのリストについては、こちらを参照してください。

Amazon CloudFront 向けに韓国のソウルで 3 番目のエッジロケーションを発表

日付: 2016 年 5 月 13 日

詳細: Amazon CloudFront 用の新しいエッジロケーションがソウル (韓国) に追加されました。これは、ソウル (韓国) で 3 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 55 となりました。詳細については、お知らせのページを参照してください。

Amazon CloudFront が AWS Certificate Manager と統合

日付: 2016 年 1 月 21 日

詳細: SSL/TLS 証明書のプロビジョニングと CloudFront ディストリビューションへの関連付けが数分で行えるようになりました。新しい AWS Certificate Manager (ACM) を使用して証明書をプロビジョンし、わずか数クリックで CloudFront ディストリビューションにデプロイしてしまえば、後は ACM によって証明書の更新管理が実行されます。ACM を使うことで、証明書のプロビジョン、デプロイ、および管理を追加料金なしで実現できます。

CloudFront では、サードパーティー認証機関から取得し、IAM 証明書ストアにアップロードした証明書も引き続きサポートされています。詳細については、Jeff Barr のブログを参照してください。

Amazon CloudFront とオリジンとの間で TLSv1.1 と TLSv1.2 に HTTPS 接続およびサポートを適用

日付: 2016 年 1 月 13 日

詳細: ビューワーのリクエスト作成で使用されたのが HTTP か HTTPS かにかかわらず、オリジンサーバーへの接続に HTTPS を使用するよう、CloudFront を設定できるようになりました。 

CloudFront とオリジンサーバーの間の接続で TLSv1.1 と TLSv1.2 を有効にすることもできます。この機能の一環として、オリジンと通信する際に CloudFront で使用するプロトコル (SSLv3、TLSv1.0、TLSv1.1、TLSv1.2) を選択することもできます。

CloudFront オリジンの新しいセキュリティ機能の詳細については、こちらをご覧ください。

Amazon CloudFront からオリジンに転送されたリクエストのヘッダーの追加または変更が可能

日付: 2015 年 12 月 28 日

詳細: オリジンに転送されたリクエストに対して、カスタムヘッダーの追加または既存ヘッダーの値のオーバーライドを行うよう、Amazon CloudFront を設定できるようになりました。これらのヘッダーを使用すると、オリジンに対して行われたリクエストが CloudFront から送信されたものであることを検証するのに役立ちます。また、指定したカスタムヘッダーの値を含むリクエストのみを許可するよう、オリジンを設定することもできます。さらに、同じオリジンで複数の CloudFront ディストリビューションを使用している場合、カスタムヘッダーを使って、オリジンのリクエストをディストリビューションごとに区別できます。最後に、カスタムヘッダーを使用すると、リクエストに対して返される適切な CORS ヘッダーを判断するのに役立ちます。カスタムヘッダーは、CloudFront API や AWS マネジメントコンソールを使って設定できます。この機能に追加料金はかかりません。

カスタムヘッダーの設定方法に関する詳細については、こちらをご覧ください。

Amazon CloudFront、エッジで自動 GZIP 圧縮のサポートを開始

日付: 2015 年 12 月 17 日

詳細: テキストおよび他の圧縮可能なファイル形式について、ブラウザや他のクライアントによって圧縮オブジェクトがリクエストされた場合に自動的に GZIP 圧縮が適用されるよう、Amazon CloudFront を設定できるようになりました。これは、既に Amazon S3 を使用しているのであれば、CloudFront でこの種のコンテンツを透過的に圧縮できるということです。オリジンが S3 の外にある場合、圧縮はエッジ側で実行されるため、オリジン側で圧縮にリソースを使用する必要がありません。圧縮されたオブジェクトはサイズが小さくなるため、ダウンロードは高速になり、CloudFront データ転送料金も下がります。

この機能の詳細については、CloudFront デベロッパーガイドの GZIP に関するセクションを参照してください。

Amazon CloudFront および Amazon Route 53 用の新しいエッジロケーションをシカゴ (イリノイ州) に追加

日付: 2015 年 12 月 1 日

詳細: Amazon CloudFront および Amazon Route 53 用の新しいエッジロケーションがシカゴ (イリノイ州) に追加されました。新しいエッジロケーションは、Amazon CloudFront と Amazon Route 53 のすべての機能を追加コストなしでサポートし、アプリケーションのエンドユーザーに対するパフォーマンスと可用性の向上に役立ちます。シカゴにエッジロケーションを追加したことにより、エッジロケーションの合計数は、米国で 21、全世界で 54 となりました。

Amazon CloudFront の世界各地のエッジロケーションのリストについては、こちらを参照してください。

AWS WAF を使用した CloudFront コンテンツへのアクセス制御

日付: 2015 年 10 月 6 日

詳細: CloudFront のウェブディストリビューションを AWS WAF に統合できるようになりました。AWS WAF は、IP アドレス、HTTP ヘッダー、カスタム URI 文字列に基づいてルールを設定してウェブアプリケーションを攻撃から保護するための、ウェブアプリケーション用ファイアウォールです。AWS WAF では、これらのルールを使用して、ウェブアプリケーションに対するウェブリクエストをブロック、許可または監視 (カウント) できます。

AWS WAF では、お客様が利用された分に対してのみお支払いいただきます。AWS WAF の料金は、デプロイするルールの数とウェブアプリケーションが受け取るリクエストの数に基づいて決定されます。最低料金や前払いの義務はありません。詳細については、Jeff Barr のブログ記事を参照してください。

Amazon CloudFront が PCI DSS に準拠したサービスの 1 つに

日付: 2015 年 8 月 4 日

詳細: Amazon CloudFront は、ペイメントカード業界データセキュリティ基準 (PCI DSS) の加盟店レベル 1 (サービスプロバイダーの最高準拠レベル) に準拠した一連のサービスに含まれるようになりました。

PCI DSS コンプライアンスは、クレジットカードデータを保存、処理、転送するすべてのビジネスに対する要件です。Amazon CloudFront の PCI コンプライアンスにより、リテール e コマース、トラベル予約、チケット販売、アプリ内購入などのアプリケーションで、アーキテクチャの一部として Amazon CloudFront を簡単に統合し、PCI DSS に準拠できるようになりました。Amazon CloudFront では、動的および静的なコンテンツ配信がサポートされるため、e コマースビジネスなどのお客様は、サイト全体の配信に同じセキュアサービスを使用して、サイト訪問者による参照とショッピングカートエクスペリエンスの両方を加速することができます。

Amazon CloudFront の PCI DSS コンプライアンスについては、ブログ内のお知らせを参照してください。

設定可能なデフォルト TTL と最大 TTL を Amazon CloudFront でサポート開始

日付: 2015 年 6 月 17 日

詳細: Amazon CloudFront では、最大有効期限 (TTL) およびデフォルト TTL を設定して、CloudFront がオブジェクトをエッジロケーションにキャッシュする期間を指定できるようになりました(以前は、Amazon CloudFront で最小 TTL を設定できました)。これらの新しい機能を使用すると、CloudFront のキャッシュ期間をさらに細かく制御できます。詳細については、お知らせのページを参照してください。

Amazon CloudFront で複数のオブジェクトの無効化が容易に

日付: 2015 年 5 月 21 日

詳細: CloudFront キャッシュから有効期限が切れる前にオブジェクトを削除することができる Amazon CloudFront の無効化機能で、ワイルドカード文字として * がサポートされるようになりました。無効化パスの末尾に * ワイルドカード文字を追加すると、このパスに一致するすべてのオブジェクトを削除できます。以前は、複数のオブジェクトを無効化するにはすべてのオブジェクトパスを別々にリストする必要がありました。現在は、* ワイルドカード文字を使用して、簡単に複数のオブジェクトを無効化できるようになっています。詳細については、お知らせのページを参照してください。

新しい Amazon CloudFront デバイスレポート、CSV エクスポート機能、およびその他

日付: 2015 年 3 月 25 日

詳細: Amazon CloudFront から配信されるコンテンツにアクセスするためにエンドユーザーが使用するデバイスについて、詳しい情報を得ることができるようになりました。新しいデバイスレポートには、指定の期間中にモバイル、タブレット、デスクトップおよびスマート TV から送信されたリクエストの数が示されます。他にも、AWS マネジメントコンソールの [Reports & Analytics] セクションを使いやすくするために、CSV エクスポート機能など、いくつかの機能強化が行われています。詳細については、お知らせのページを参照してください。

お知らせ: スマート TV のデバイス検出サポート

日付: 2015 年 3 月 13 日

詳細: Amazon CloudFront を使用し、User-Agent ヘッダーの値に基づいて、カスタマイズされたコンテンツをキャッシュしてスマート TV のビューワーに配信できるようになりました。詳細については、Amazon CloudFront デベロッパーガイドで、このトピックを参照してください。

Amazon CloudFront により、プライベートコンテンツに署名付き Cookie の追加

日付: 2015 年 3 月 12 日

詳細: Amazon CloudFront では、新しい方法でプライベートコンテンツを保護できるようになりました。それが CloudFront 署名付き HTTP Cookie です。以前は、各オブジェクト URL にカスタム署名を追加することで、CloudFront コンテンツにアクセスできるユーザーを制限していました。今後は、HTTP Cookie に署名を含めることで、これと同じレベルの制御を行うことができます。詳細については、お知らせのページを参照してください。

Amazon CloudFront と Amazon Route 53、韓国のソウルで新しいエッジロケーションを発表

日付: 2015 年 1 月 26 日

詳細: Amazon CloudFront および Route 53 用の新しいエッジロケーションがソウル (韓国) に追加されました。これは、ソウル (韓国) で 3 番目のエッジロケーションであり、これで世界各地にあるエッジロケーションの数は合計 53 となりました。詳細については、お知らせのページを参照してください。