はてなブックマークで利用しているCloudFrontのAWSアカウントを移行した - Hatena Developer Blog
こんにちは、id:cohalzです。2023年4月に実施したはてなブックマークのメンテナンスではCloudFrontを別のAWSアカウントに移行しました。 この記事ではCloudFrontを別のAWSアカウントに移行した背景とどのように移行したのかを説明します。 はてなブックマークのインフラのこれまで 移行したいモチベーションが出てきた理由 切り替えで設定が変わらないように気を付ける キャッシュポリシーに移行する 移行方法について検討する AWS CLIでCloudFrontを移行する手順を作成する アクセスログを配送する部分も移行する まとめ はてなブックマークのインフラのこれまで はてなブックマークのインフラはこのようにCloudFrontと関連リソースだけ別のAWSアカウントで利用していました。 移行前 この状況になっていた経緯をまず説明すると、はてなブックマークでは2018年からオ
[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ | DevelopersIO
[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ CloudFrontからS3へのアクセス制限として従来のOAIに加えて、新たにOACが利用可能になりました。セキュリティが強化されSSE-KMSなどのサポートが行われています。OAIも引き続き利用可能ですが、今後はOACを使用しましょう。 はじめに 清水です。今朝（日本時間2022/08/26、現地時間2022/08/25）のアップデートでAWSのCDNサービスであるAmazon CloudFrontにOrigin Access Control (OAC)という機能が追加されました。CloudFrontからオブジェクトストレージサービスAmazon S3へのアクセス制限を行う新たな方法となります。これまでもOrigin Access Identi
![[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ | 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)
Route 53とCloudFrontを使った中国ユーザーためのパフォーマンス最適化 | Amazon Web Services
Amazon Web Services ブログ Route 53とCloudFrontを使った中国ユーザーためのパフォーマンス最適化 中国は、グローバル企業にとって重要な市場です。グローバルにビジネスを展開する企業もスタートアップ企業も、中国で拡大するユーザー市場に参入する方法を模索しています。お客様のクラウドジャーニーを加速し、新しい市場に迅速に進出できるよう、2016年に AWS 中国（北京）リージョンが、2017年に AWS 中国（寧夏）リージョンが開始されました。これらのリージョンは、お客様が中国本土でサービスを提供する際に最高の体験を提供します。 最近、中国で Amazon Route 53 がローンチされたことにより、お客様は中国のエンドユーザーに高パフォーマンスのサービスを提供するための強力なツールをまた一つ手に入れました。Amazon Route 53 は、可用性と拡張性に
【アップデート】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 サーバで
L@EとCF2が不要に？！CloudFront単体でレスポンスヘッダーが設定できるようになりました | DevelopersIO
CX事業本部@大阪の岩田です。CloudFrontに待望のアップデートがあり、CloudFront単体でもレスポンスヘッダーが設定できるようになりました！ これまではCloudFront単体でレスポンスヘッダーを設定することができませんでした。S3 & CloudFrontの構成でSPAを配信するのは非常に一般的な構成ですが、この構成でそのまま脆弱性診断を受けると、セキュリティ関連のヘッダが設定されていないと指摘されるのも「あるある」でした。Lambda@Edge(L@E)やCloudFront Function(CF2)を介入させればオリジンレスポンスやビュワーレスポンスが加工できるので、これまではL@EやCF2でレスポンスヘッダを追加付与するという対応がよく採用されていました。 が、静的なレスポンスヘッダ付与のためにいちいちコードの実行が必要になるというのは、どうも無駄が多いように感じ
[UPDATE] Amazon CloudFrontでクライアントのIPアドレスと接続ポートを確認できるCloudFront-Viewer-Addressヘッダが利用可能になりました | DevelopersIO
はじめに 清水です。本日お届けするアップデート情報はこちら、AWSのCDNサービスであるAmazon CloudFrontでクライアントのIPアドレスと接続ポート情報を確認できるCloudFront-Viewer-Addressヘッダが利用可能になりました。2021/10/25付でポストされたアップデート内容になります。 Amazon CloudFront adds support for client IP address and connection port header CloudFront-Viewer-Addressヘッダをオリジンサーバに転送するようCloudFrontを設定することで、オリジンサーバ側でクライアントのIPアドレスならびに接続ポート情報の確認がリアルタイムに行えます。これまでだと接続元IPアドレスの確認はX-Forwarded-Forヘッダの解析が必要、接続ポ
CloudFront の Cache Policy と Origin Request Policy を理解する - Qiita
はじめに CloudFront の Management Console で Behavior を設定していると、こんな見慣れない機能が表示されるようになっていた。 これは何ぞや、と思って調べてみたら 2020/07 のアップデート内容のようだ。 Amazon CloudFront キャッシュポリシーとオリジンリクエストポリシーを発表 かなり新しい機能で、まだ資料が少なかったので自分の理解のために従来と比較して何がうれしいのかをまとめてみた。 TL; DR この機能の実装前はオリジンへのForwardとキャッシュキーの項目が自動的に一致していた Policyの実装によって、キャッシュキーとオリジンへの項目転送を分離してより柔軟で直感的なキャッシュルールを定義できるようになった 1度書いた設定を複数の Behavior で再利用できるようになった 1. CDN / CloudFront の仕
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
CloudFrontで素早くコンテンツを更新させたい場合にTTLを短くしInvalidationを行わないキャッシュ戦略を考える | DevelopersIO
CloudFrontで素早くコンテンツを更新させたい場合にTTLを短くしInvalidationを行わないキャッシュ戦略を考える CloudFrontで頻繁に更新されるコンテンツではないため長くキャッシュさせておきたいが、更新があった場合はすぐに反映させたい、というケースではTTLを短くしておきましょう。オリジンからのデータ本体の転送は更新の際にしか実施されません。 はじめに 清水です。AWSのCDNサービスであるAmazno CloudFrontを利用する場合に、頻繁に更新されるファイルではないため、なるべく長くCloudFrontにキャッシュさせオリジンへのアクセスやデータ転送の負荷などは極力少なくしたい。けれどオリジン側でファイルの更新があった場合は、なるべく早くCloudFront側でもキャッシュの反映を行いたい、といったことがあります。 このようなケースで1つ考えられる方法は、C
CloudFront+S3なSPAにLambda@EdgeでOGP対応する | DevelopersIO
吉川@広島です。 案件でCloudFront+S3なSPAに対してOGP対応が必要になってきそうなため、Lambda@Edgeを使った対応について検証しました。 現状、FacebookやTwitterのBotは基本的にクライアントサイドJSを解釈できず、SPA単体でのOGP対応は難しいとされています。OGPメタタグはSSRで返してあげる必要があるため、「UserAgentでBot判定し、その時だけOGPメタタグ入りのHTMLをエッジサーバでレンダリングして返す」というのが基本戦略になります。 SPAをホスティングするCloudFront+S3を作成する S3バケットを作成する バケット名だけ入力し、後はデフォルト値で作成します。 そして、本来であればSPA用のHTML/JS/CSSリソースをアップロードするのですが、今回はLambda@Edgeの動作確認ができれば良かったためパスしました（
固定IPアドレスでフルマネージドなリダイレクト環境をAWSで構成する | DevelopersIO
ALBのリダイレクト機能とGlobal Acceleratorを組み合わせることで、AWSで固定IPアドレスなフルマネージドリダイレクト環境が構成できます。事情により名前解決をAレコードで行う必要がある場合にベストなリダイレクト環境かと思います。 はじめに 清水です。固定IPアドレスでアクセスできるリダイレクト環境が必要になり、AWSでの構成を考えてみました。S3+CloudFrontのリダイレクト環境だとIPアドレスが可変であるため要件にマッチしません。それならEC2上でHTTPサーバを稼働させる必要があるかな、と考えていたのですが、ALBのリダイレクト機能とGlobal Acceleratorの固定IPアドレスを利用することで実現が可能だということに気が付きました。AWSのフルマネージドなサービスのみで実現できるため、管理運用の手間もありません。ACM証明書も利用可能です。そもそもどう
CloudFrontのCNAMEをディストリビューション間でダウンタイム無しにアトミックに移行できるようになりました | DevelopersIO
Amazon CloudFrontはディストリビューション間のCNAMEの重複が許可されていません。 そのため、この CNAMEAlreadyExists 回避のために、 AWSサポートに対応を依頼 ワイルドカード形式のCNAMEを経由して付け替え といった対応が行われてきました。 CloudFrontのCNAMEAlreadyExistsエラーを回避しつつCNAMEを付け替える | DevelopersIO CloudFront エラー「CNAMEAlreadyExists」の解決 今回のアップデートにより、条件付きではありますが、ダウンタイム無しにディストリビューション間でアトミックにCNAMEを付け替えられるようになりました。 New APIs and functionality for managing Amazon CloudFront CNAMEs | Networking &
AWS、エッジにおけるJavaScript実行環境に本格参入。Cloudflare WorkersやDeno Deployなどと競合へ
AWS、エッジにおけるJavaScript実行環境に本格参入。Cloudflare WorkersやDeno Deployなどと競合へ Amazon Web Services（AWS）は、エッジ環境で軽量なJavaScriptによる処理を実行可能な新サービス「Amazon CloudFront Functions」を発表しました。 AWSではすでにエッジで処理を行う「Lambda@Edge」を提供しており、そこでNode.jsとPythonによるコードを実行可能です。 しかしLambda@Edgeは13カ所のリージョナルエッジキャッシュにおいて処理が行われるのに対し、CloudFront Functionsは218カ所以上のCloudFront Edge Locationsにおいて処理が行われるため、よりユーザーに近い広範囲なロケーションで実行されます。 また、実行時間もLambda@Ed
エッジで爆速コード実行！CloudFront Functionsがリリースされました！ | DevelopersIO
珍しく早起きをしてRSSを眺めてるとアッツアッツなアップデートが来ていました。 Amazon CloudFront announces CloudFront Functions, a lightweight edge compute capability 今回はCloudFront Functionsをご紹介していきます。 CloudFront Functionsとは？ CloudFront Functions(CF2)はLambda@Edgeより手前で、シンプルな処理をより高速に、素早く、安価に実行できるサービスです。 CloudFront Functionsを使うことでこれまでLambda@Edgeで実行していたシンプルな処理をよりユーザーに近いEdge Locationで実行しつつ、高速に処理を行う事ができます。 また、CloudFront FunctionsとLambda@Edge
CloudFrontエッジキャッシュクリアのみを行うユーザーの作成 | DevelopersIO
こんにちは、吉井です。 いかがお過ごしでしょうか。 みなさまはCloudFrontをお使いでしょうか。 CloudFrontの管理は自社で行い、Webコンテンツ作成・アップロードは外部委託しているケースはよくあると思います。 コンテンツアップロード後には、それらのエッジキャッシュをクリアする必要があります。 即時性を考えるとコンテンツ作成担当者にCloudFrontエッジキャッシュのクリアまでお願い出来ればハッピーです。 今回は依頼を受けて、エッジキャッシュクリアだけ可能なIAMユーザーを作成します。 IAMユーザーの作成 AWSマネジメントコンソールへログインし、IAM画面を開きます。 ポリシー作成 ポリシー作成画面でJSONタブをクリックし以下のポリシーをペーストします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Al
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた | DevelopersIO
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた CloudFront-ELB-EC2な構成でEC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返す際に、リダイレクト先ドメインが変わってしまう、リダイレクト先のプロトコルが変わってしまう、という問題に遭遇しました。CloudFrontのHostヘッダ転送、HTTPSリダイレクト機能を用いてAWS側のみで対応する方法を検討してみました。 はじめに 清水です。先日以下のようなCloudFront-ELB-EC2な構成で、EC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返したときに発生する問題と出くわしました。解決策をできる限りAWS側で対応する方法を検討してみたのでまとめてみます。 A
CloudFront-Forwarded-Protoヘッダを使ってCloudFrontへの通信プロトコルをオリジン側で確認してみた | DevelopersIO
CloudFront-Forwarded-Protoヘッダを使ってCloudFrontへの通信プロトコルをオリジン側で確認してみた CloudFrontでCloudFront-Forwarded-Protoヘッダをオリジンに転送するよう設定し、オリジン側でリクエストに含まれるヘッダ情報を確認することで、クライアントがClouｄFrontにどの通信プロトコルで接続しているのか判別できることを確認してみました。 はじめに 清水です。前回のエントリに続いて、今回もCloudFront-ELB-EC2な構成でのネタです。ユーザからの通信がHTTPSまたはHTTPだとして、かつCloudFront-ELB間はHTTPS通信と設定した環境とします。オリジンであるEC2側ではユーザからCloudFrontへの通信プロトコルをどのように判別すればよいか調査してみました。 ELB-EC2のような構成でEC2
Amazon CloudFrontへのアクセスをAWS WAFでRefererによって制御してみた | DevelopersIO
Amazon CloudFrontへのアクセスをAWS WAFでRefererによって制御してみましたのでご紹介します。 概要 Amazon CloudFront(img.example.com)へ直接アクセスはできない。 特定のドメイン (www.example.com) からのみアクセス可能。 AWS WAFでRefererによって制御する。 設定方法 マネジメントコンソールで設定していきます。 Web ACLを作成する Create web ACL をクリックして web ACL を作成します。 Step 1: Name web ACL Web ACL name* : Web ACL の名前を入力 CloudWatch metric name* : 自動でCloudWatch metric名が入ります。 Region* : Global (CloudFront) AWS resour
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - aws-samples/cloudfront-authorization-at-edge: Protect downloads of your content hosted on CloudFront with Cognito authentication using cookies and Lambda@Edge
AWSのデータ転送無料枠が拡張されます。リージョンからの転送は月100GBまで無料、CloudFrontからの転送は月1TBまで無料に。 | DevelopersIO
