Amazon CloudFront now offers Origin Access Control, a new feature that enables CloudFront customers to easily secure their S3 origins by permitting only designated CloudFront distributions to access their S3 buckets. Customers can now enable AWS Signature Version 4 (SigV4) on CloudFront requests to S3 buckets with the ability to set when and if CloudFront should sign requests. Additionally, custom
先日業務でCloudFrontを活用していて、単純ですがCORSエラーが出ないための設定で一瞬ハマりかけたことがあるため皆さんに共有いたします。 CloudFront(というよりCDN)はキャッシュ戦略といい、奥が深いなぁということを感じました(小並感) やること TerraformでS3をオリジンとしてCloudFrontを立てる 特定のサイトからだけクロスオリジンリクエストを許可する様にS3とCloudFrontにルールを設定する curlで動作を確認していく 前提知識 CloudFrontがどのようなサービスか概要を知っている CORSの基本的な知識 CORSについてはたくさん良さそうな記事がありますので、検索してみてください。 結論 先に結論をご説明いたしますと、AWSの公式で提示してくださっています。 必要なことを列挙すると以下の様になりますが、一つ一つ説明して行きたいと思います
Amazon CloudFront が、stale-while-revalidate および stale-if-error キャッシュ制御ディレクティブをサポート
Amazon CloudFront は、stale-while-revalidate および stale-if-error のキャッシュ制御ディレクティブのサポートを発表しました。これらはパフォーマンスと可用性を向上させます。stale-while-revalidate ディレクティブは、バックグラウンドでキャッシュを再検証している間に、ユーザーに古いレスポンスをただちに配信するよう CloudFront に指示します。stale-if-error ディレクティブは、エラーが発生した場合に CloudFront が古いレスポンスを再利用する時間を定義します。これにより、ユーザーエクスペリエンスが向上します。 stale-while-revalidate を使用すると、CloudFront は 480 以上のエッジロケーションから、より高速なレスポンスを配信できます。また、キャッシュヒット率
署名付きCookieはCloudFrontで配信するコンテンツをプライベートなコンテンツとして配信するための機能です。よく似た機能で署名付きURLもあります。今回は署名付きCookieでコンテンツの制限とアクセス検証します。 信頼されたキーグループのキーペアの作成 CloudFront + S3でコンテンツの配信準備 コンテンツを署名付きCookieで制限しプライベートコンテンツとして配信 CloudFrontの署名付きCookieを使ってプライベートコンテンツの配信を試します。以前はrootユーザでCloudFrontのキーペアを作成していました。現在は非推奨であり、通常のIAMユーザでCloudFrontのキーペアを作成する方法が推奨されています。ということで、推奨方法でキーペアを作成するところからはじめます。 署名付きCookie 信頼されたキーグループのキーペアの作成 署名者のキー
Amazon Web Services ブログ Amazon CloudFront を活用したウェブサイトの可用性向上 Amazon CloudFront は、キャッシュ機能によるオリジンサーバー（CloudFront がコンテンツを取得する元のウェブサーバー）の負荷軽減とコンテンツ配信のパフォーマンス向上を実現できますが、可用性の向上もCloudFrontを活用することで得られる大きなメリットの1つです。CloudFront を利用する対象のウェブサイトのオリジンサーバーがAWS 上に存在する場合、オリジンサーバー側でもELB の活用や複数のアベイラビリティーゾーンの活用など可用性向上の為の様々なアプローチがありますが、CloudFront を利用することで更に高い可用性をウェブサイトにもたらすことが出来ます。 ウェブサイトの可用性を向上することは、ウェブサイトの応答速度の向上と同様にウ
AWSチームのすずきです。 Amazon CloudFront、リアルタイムなアクセスログ出力をサポートするアップデートがありました。 Amazon CloudFront announces real-time logs Kinesis Data Streams へのログ出力設定と、アクセスログが参照可能になるまでのタイムラグを確認する機会がありましたので、紹介させていただきます。 AWS設定 Kinesis バージニア(us-east-1)リージョンに、Kinesis Data Stream を設置しました。 今回、シャード数は「1」で設定しました。 ログが発生量が多くスロットルが発生する場合には、シャード数を適量まで追加してご利用ください。 CloudFrontダッシュボードに「Logs」が追加されました。 「Real-time log configurations」の「Create
CloudFront から (出力された)「リクエストされたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しません」というエラーは、どうすれば解決できますか? 解決策 オリジンのクロスオリジンリソースシェアリング (CORS) ポリシーで、オリジンに Access-Control-Allow-Origin ヘッダーを返すことが許可されていることを確認します **注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、使用している AWS CLI が最新バージョンであることを確認してください。 次のコマンドを実行して、オリジンサーバーから Access-Control-Allow-Origin ヘッダーが返ることを確認します。**example.com ** を必要なオリジンヘッダーに置き換えてください
CloudFrontとLambda@EdgeでA/Bテストをサクッと導入してみる | DevelopersIO
ウェブサイトでA/Bテストする場合、以下の流れで作業します A/B 2パターンのサイト(機能)を用意 ユーザーをどちらかに振り分ける A/Bのどちらが有効か評価 この2つ目のユーザー振り分けは実現方法が色々考えられます。 本ブログでは、Amazon CloudFront とエッジコンピューティングの Lambda@Edge(以下L@E) を使い、アプリ改修なしに、同じURLを利用しながら、ユーザーをA/Bに振り分ける方法を紹介します。 完成図 ポイント ポイントは次の3点です アプリケーションは改修しない L@EでA/Bテスト用のCookieを発行し、A/B振り分ける CloudFrontではA/Bテスト用のCookieをキーにキャッシュ 前提として、A/Bを実装したアプリケーションに異なるホストを割り当て、URIパス部の仕様は同じとします。 1. アプリケーションは改修しない アプリケー
Amazon Web Services ブログ CloudFront Functions を使用したコンテンツの保護 AWS の高速コンテンツ配信ネットワーク（CDN）サービスである Amazon CloudFront から配信されるビデオコンテンツを保護するには、署名付き Cookieと署名付き URL の 2つの方法があります。 お客様はユースケースに応じて、どちらか一方または両方を使用することができます。 例えば HTTP Live Streaming（HLS）のセキュアなビデオ再生のために、メインマニフェスト、サブマニフェスト、トランスポートストリームセグメントを含む、全てのコンテンツに権限を与えるワイルドカード文字を持つリソース URL を承認するために、署名付き Cookie を選択することができます。 一方、クライアントが Cookie をサポートしていない、または Cook
[CloudFront] Lambda@EdgeでHTTPセキュリティヘッダーを追加する方法 | DevelopersIO
Lambda@EdgeはAmazon CloudFrontの機能で、CloudFrontのイベントに応じてLambda関数を実行できます。この機能を利用して、CloudFrontで配信しているコンテンツのレスポンスヘッダーにHTTPセキュリティヘッダーを設定します。 Lambda@Edge | AWS HTTPセキュリティヘッダーは、Webブラウザのセキュリティ対策のためにWebアプリで使用されるHTTPヘッダーです。HTTPセキュリティヘッダーを設定することで、クリックジャッキングやクロスサイトスクリプティング（XSS）など、クライアント側の脆弱性を利用した攻撃を困難にします。 OWASP Secure Headers Project Lambda@Edgeの仕組み Lambda@Edgeはオリジのレスポンスをトリガーにした場合、CloudFrontがオリジンから取得したコンテンツをキャ
Herokuでカスタムドメイン（ルートドメイン）を使うためにCloudFrontを設定する - アジャイルSEの憂鬱
Route53で取得したカスタムドメインをHerokuで使うためにCloudFrontの設定をしたのでブログに書いておく。 コード例は foo.herokuapp.com で動くアプリケーションを foo-example.com でアクセスできるようにする設定です。 AWS側の設定 CloudFrontで使うacmはvirginiaで作成 ttlは0にしてキャッシュしない /assets や /packs はキャッシュした方が良いけど、まだ未対応 locals { foo_domain = "foo-example.com" foo_origin_id = "foo-heroku" } module "acm" { source = "terraform-aws-modules/acm/aws" version = "2.12.0" providers = { aws = aws.virg
[新機能] Amazon CloudFrontでより詳細なジオロケーションヘッダが利用できるようになりました | DevelopersIO
はじめに 清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、これまでもカスタムヘッダによりアクセス元の国コードを取得することが可能でしたが、（[新機能] Amazon CloudFrontがジオターゲティングに対応しました | Developers.IO）今回さらに、都市名や郵便番号、タイムゾーンといったより詳細なロケーションに関する情報がカスタムヘッダにより取得できるようになりました。（2020/07/24にポストされたアップデート内容になります。） Amazon CloudFront adds additional geolocation headers for more granular geotargeting 新たに取得できるようになったジオロケーションヘッダについてはドキュメントの以下ページに詳細がまとめ
AWSのデータ転送無料枠が拡張されます。リージョンからの転送は月100GBまで無料、CloudFrontからの転送は月1TBまで無料に。 | DevelopersIO
AWSのデータ転送無料枠が拡張されます。リージョンからの転送は月100GBまで無料、CloudFrontからの転送は月1TBまで無料に。 AWSデータ転送量の無料枠が拡張されます。EC2等のリージョンからインターネットへの転送量は月1GB→月100GBへ無料枠引き上げ。CloudFrontからの転送量は月50GB→月1TBへ、HTTPやHTTPSリクエスト数は月2百万回→月1千万回へ無料枠引き上げ。CloudFrontは最初の12ヶ月間の制限も無くなります。2021年12月1日から適用。
X-Forwarded-For の正しい取り扱い方とCloudFrontを通したときのクライアントIPの取得方法 - mrk21::blog {}
X-Forwarded-For ってなに？ プロキシやロードバランサーを通してサーバーにアクセスすると、サーバーから見たクライアントIPはプロキシのものになってしまいます。それを解決するために、プロキシで X-Forwarded-For HTTP Header にクライアントの Remote IP を記録して、サーバーではその値を見ることでクライアントIPを取得できるようになります。 X-Forwarded-For からクライアントIPを取得する X-Forwarded-For HTTP Header は以下のようなフォーマットになっています。 X-Forwarded-For: <client>, <proxy1>, ... そのためクライアントIPを得るためには X-Forwarded-For の先頭のIPを参照すればよさそうです。 しかし、この方法には問題があります。というのもプロキシ
前提 すでに、CloudFrontの設定は済んでいる Origin側との接続も済んでいる 準備：パスワードの文字列作成 まず、パスワードの文字列を作ります。 以下のパスワードを作ることを想定しています。 ID：classmethod Password：0912cm CloudShellが使えるリージョンに行きます。ここでは Tokyo リージョンを使用します。 以下のように入力 echo -n "classmethod:0912cm" | base64 出てきた文字列を記録します。 Y2xhc3NtZXRob2Q6MDkxMmNt CloudFront Functions の作成 CloudFront から Functions に行きます。 Create Functionをクリックします。 Functionの名前を決めます。任意の名前で大丈夫ですが、ここでは「s3-cf-keisuke-f
できます。 ここにある通り、S3 の設定ページで エラードキュメント に index.html をセットするだけで良いです。CloudFront がなくてもできます。 （完） ただ、たとえば /about でリロードして、404 Not Found になっていたものが、エラードキュメントに index.html を指定したら /about が見れるって違和感ありませんか？ 少なくとも私は「index.html に redirect するのだから、そこで見えるものって / なのでは！なんで/about が見えるんですか!？」という疑問を持っていました。 あと、「S3 SPA」で検索すると、CloudFront 前提だったり、index.html を書くことで解決される理由は書かれてなさそうなので、そういうのを解説したいと思います。 どうして SPA のホスティングで悩むのか SPA(Sing
CloudFrontのオリジンをEC2にしてHTTPS通信を強制する構成について | DevelopersIO
余談 : HOSTヘッダ転送時のSNIホスト名について HOSTヘッダを転送した場合はオリジンアクセス時のSNIホスト名(NGINXだと$ssl_server_name)もヘッダと同じ値に設定され、パケットキャプチャの結果も確かにそうなっていました。 (HOSTヘッダを転送しない場合はSNIホスト名はオリジンドメイン名となる) 本記事の内容にはあまり関係ないとは思いますが一応記録だけ残しておきます。 試してみた ここからは簡単な検証環境を作って実際に試した結果を共有します。 検証環境は私の検証用AWSアカウントになります。 1. EC2単体でのサーバー公開 最初に東京リージョンにVPC環境とEIPを持つAmazon Linux 2023 EC2インスタンスを一台用意し、www.example.shibata.techというDNS名を与えておきます。 DNSはRoute 53を使っています。
Amazon CloudFront の CNAME を管理するための新しい API と機能について | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront の CNAME を管理するための新しい API と機能について Amazon CloudFront は、ListConflictingAliases と AssociateAlias という 2 つの新しい API のリリースを発表しました。これらの API は、 CNAMEAlreadyExists エラーコードが発生した際に、代替ドメイン名（CNAME）を探したり、移動させたりする必要がある場合に便利です。さらに、アカウント間でワイルドカードの CNAME を使用する際に、より多くのユースケースで利用することが可能になりました。API について詳細を紹介する前に、このブログではまず CNAMEAlreadyExists エラーコードの背景を少し説明し、CloudFront ディストリビューションで CN
自分が触ったところだけですがメモします。主に署名URL周りです。 触ってみて理解が少し進んでいるところは自分なりの言葉でかみ砕いて書いています。 よくわからず情報もない部分は書籍や管理画面の英語解説を google翻訳でほぼそのままな部分、本家サイトのリンクを紹介しているものもあります。 CloudFrontって何?という方は最下部に簡単な解説を書いています。 General 設定項目 解説
CloudFront + Lambda@edge + JWTで認証フローを作りS3オブジェクトを守る - Tech Blog
こんにちは、サーバーサイドエンジニアのiwamu(@k_iwamu)です。 CloudFrontからS3のプライベートなコンテンツへのアクセス制御はどのように管理されているでしょうか。 アクセス制御の主要な方法の1つとしては、CloudFrontの署名付きURLを作成し、一時的に権限を与える方法が挙げられるかと思います。 しかし、Lambda@edgeを用いれば、アクセス制御をプログラムでもっと柔軟に、かつCloudFront+Lambda@edgeの特性上レイテンシも少なく実装することができます。 今回は、CloudFrontは署名付きURLを使用せず、Lambda@edgeとJWTを使ってアクセス制御を行うように実装したので共有します！ ボツになってしまった案とその課題 内部事情ですが、設計の前提としてCloudFrontのURLをクライアント側で保存している箇所がありました。 その前
CloudFront で Lambda@Edge を使って OpenID Connect (OIDC) 認証 - Qiita
CloudFront と S3 を使ってサーバーレスなウェブサイトを構築し、特定のユーザーにのみ公開するために Google, GitHub など外部の認証プロバイダ (IdP) を使って認証をおこなう方法です。CloudFront ではリクエスト中継時に Lambda 関数を実行し認証などの処理をおこなうことができるため、それを使うことにします。 OpenID Connect による認証シーケンス CloudFront にアクセスした際のシーケンスは以下のようになります。 構築手順 OpenID Connect (OIDC) による認証をおこなう Lambda 関数を Widen/cloudfront-auth というツールを使って生成します。様々な認証プロバイダに対応していますが、ここでは Google で認証し、特定ドメインのメールアドレスのユーザーのみをアクセス許可してみます。 ※
WebSocket API Gateway の前段にCloudFrontディストリビューションを置く構成を作成する機会がありましたのでレポートします。 この構成のメリット WebSocketと他のリソースを同じFQDNから配信できる CloudFrontディストリビューションは、Behaviors(Cache Behaviors)という機能を活用することで複数のオリジンを同一FQDNから配信することができます。 例えば以下のようなことができます。 /websocket パス以下をWebSocket API Gatewayオリジンにする 他のパスは他のオリジンを使う(S3、ALBなど) ※とはいえ、FQDN分けてしまえるならその方がシンプルな構成になり良いかと思います。 ネットワークの最適化 2020/08/14現在、CloudFrontの接続ポイントは42か国84都市にある216箇所が提供
CloudFrontのアクセスログ保存用S3バケットにはACL有効化が必要なので注意しよう | DevelopersIO
はじめに 清水です。先日、Amazon S3のACL無効化が推奨されたことで、S3のサーバアクセスログ記録保存用のS3バケットの権限設定においてもACLではなくバケットポリシーを使用するようになっていた、というブログを書きました。 ACL無効化が推奨されたことでS3のサーバアクセスログ記録のためのアクセス許可はどうなったのか!?確認してみた | DevelopersIO re:Invent 2021期間中に発表されたS3のACL無効化機能に伴う変更です。（【アップデート】S3でACLを無効化できるようになりました #reinvent | DevelopersIO）上記エントリではS3のサーバアクセスログ記録保存用となるS3バケットについて確認しましたが、CloudFrontのアクセスログ記録用となるS3バケットについて、ACL無効化の影響（ACLを無効にしたS3バケットをCloudFron
【AWS/CloudFront/S3/Cognito】静的ウェブサイトにCognitoの認証をつけたい（dbt） - データベース技術調査ブログ
タイトルの内容に入る前になぜこのようなことをしたいかという背景を少し語ります。 最近DWHをいかにアジャイルに構築して運用していくかについて考えています。商用のツールを使えばいいアプローチはいくらでもありますが、この手のツールはとても高価なイメージがあります。 そこで目に入ってきたのがdbt (data build tool) というOSSです。 dev.classmethod.jp dbtというツールはいくつもいい点があるのですが、一番好きななのはドキュメントを自動生成してくれるというところにあります。 dbtはOSSのCLI版とSaaS版があります。 www.getdbt.com チーム版は開発ユーザ当たり50$/月ということで、そこまでお高くはない気がしますが、そもそもあまりクラウドサービスをがっつり使うことに抵抗があったりする場合もあるなと思ったりします。（そんな抵抗ない場合は使う
CloudFront Functions を使用して Amazon S3 の Amazon CloudFront オリジンでデフォルトディレクトリインデックスを実装 | Amazon Web Services
Amazon Web Services ブログ CloudFront Functions を使用して Amazon S3 の Amazon CloudFront オリジンでデフォルトディレクトリインデックスを実装 Amazon CloudFront Functions により、以前は AWS Lambda@Edge でしかできなかったことを、より高性能な方法で行うことができるようになりました。たとえば、Amazon CloudFront のオリジンアクセスアイデンティティ (OAI) を使用してオリジンを保護する場合に必要不可欠である URI パスを操作できます。 2017年に私が書いた投稿 (Implementing Default Directory Indexes in Amazon S3-backed Amazon CloudFront Origins Using Lambda@E
5分でできるS3とCloudFrontを利用したセキュアな静的Webサイトの作り方 | DevelopersIO
5分強で設置できるセキュアなCloudFrontとS3の静的ウェブサイトの設定内容について紹介します。 AWSチームのすずきです。 CloudFrontとS3の静的ウェブサイトを採用する利点について、諏訪より紹介させて頂きました。 今回、実際の設置に利用しているCloudFormationテンプレートの紹介と、 主に非機能要件のため実施している設定内容について、紹介させていただきます。 設定 S3(静的コンテンツ) 静的ウェブサイト(WebsiteConfiguration)を有効としたS3バケットです。 S3Bucket: Type: AWS::S3::Bucket DeletionPolicy: Retain Properties: BucketName: !Sub '${AWS::StackName}' LifecycleConfiguration: Rules: - Id: Non
JavaScriptが解釈できないクローラーが正しくogpタグを読めるようにするために、どのようなアーキテクチャでSPAのサイトを構築すればいいかというお話Read less
Single Page Applicationで静的コンテンツの配信にCloudFrontの署名付きCookieを利用してみた | DevelopersIO
Single Page Applicationで静的コンテンツの配信にCloudFrontの署名付きCookieを利用してみた こんにちは。さかいです。 Single Page Application(以下 SPA)で画像ファイルなどの静的コンテンツを配信をどのように実装してますか？ パブリックに公開するのであれば、あまり迷わなくて済むのですが、 コンテンツの配信は認証済みユーザのみアクセスできるようにしたい サイズが大きいコンテンツやコンテンツ数も多いので大容量保存できるようにしたい 特定のオブジェクトは特定のユーザだけがアクセスできるようにしたい … などの要件があると、どのように実装できるだろうか？と迷うこともあるかと思います。 そんな時の実装案の１つとして、S3 + CloudFrontで署名付きCookieを利用してコンテンツの配信をやってみます。 構成イメージ 今回作成するイメ
Amazon CloudFront と AWS Lambda@Edge による署名付き Cookie ベースの認証 : パート 1 – 認証 | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront と AWS Lambda@Edge による署名付き Cookie ベースの認証 : パート 1 – 認証 この 2 部構成のブログシリーズでは、メールアドレスとドメイン名を使用してユーザー認証を行う方法を学習します。この方法では、静的な Web サイトへの資格情報を使用しないユーザーアクセスを制限します。 この最初のブログでは、認証メカニズムの実装方法を学びます。第 2 部のブログ記事では、認可メカニズムを実装してソリューションを完成させる方法を学習します。 このソリューションでは、Amazon Simple Storage Service (S3) にコンテンツを保存し、Amazon CloudFront 経由でコンテンツを配信します。AWS Lambda@Edge を介してエンドユーザーへの認証を処理し
【AWS】 Route 53 + ACM + CloudFront + S3 の構成を構築する際にいろいろつまずいた件 - Qiita
この記事の対象者 Route 53 + ACM + CloudFront + S3 構成を構築しようと試みている人 Route 53 + ACM + CloudFront + S3 構成を構築してみたがいまいち全体像がわからない人 AWS で独自ドメインで HTTPS 通信で Web サイトを配信したい人 AWS 初心者 はじめに AWS で Web サイトを独自ドメインで配信するにはどうしたらいいのか調べてたところ、どうも Route 53 + ACM + CloudFront + S3 の構成がスタンダードのようでした。 【参考】 ・AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） そして、この構成についての参考になるサイトがたくさん存在します。 以下リンクになります。 ・AWSで独自ドメインのhttpsな静的Webサイトを構築する（ACM+S3＋CloudFro
Amazon CloudFront はじめに 本ページは、AWS に関する個人の勉強および勉強会で使用することを目的に、AWS ドキュメントなどを参照し作成しておりますが、記載の誤り等が含まれる場合がございます。 最新の情報については、AWS 公式ドキュメントをご参照ください。 Contents Amazon CloudFront はじめに Contents Amazon CloudFront とは CloudFront の基本 ディストリビューション オリジン エッジロケーション リージョン別エッジキャッシュ ビヘイビア（Behavior） キャッシュ無効化（Invalidation） 圧縮機能 料金クラス 署名付き URL と署名付き Cookie S3 オリジンへのアクセス制限 ALB オリジンへのアクセス制限 コンテンツを地理的に制限 AWS Shield AWS WAFによるアク
AWS CDK v2でOACってどうやってやるの？CloudFront+S3+OAC構築（コード付き-Typescript） - Qiita
AWS CDK v2でOACってどうやってやるの？CloudFront+S3+OAC構築（コード付き-Typescript）AWSS3TypeScriptCloudFrontAWSCDK はじめに AWS CDKでリソース作ってますか？？ 最近、AWS CDKを見ること、触ることが多く、少しずつ仲良くなってきました。そんな中、AWS CDKでAmazon CloudFront オリジンアクセスコントロールをどうやってやるのか、困ったのでご紹介です。 アーキテクチャ 以下の通り、利用者からアクセスされ、オリジンサーバとなるS3から表示用HTMLを利用者に返却するアーキテクチャです。よくあるやつですね。 上記のCloudFrontとS3のアクセス部分でオリジンアクセスコントロール（OAC）を利用します。OACを利用することでS3自体をパブリックにする必要がなくなり、S3への直接的な意図しないア
WordPressで構築されているウェブサイトにCloudFrontを立てて高速化＆セキュリティ強化② | ソフトウェア開発のギークフィード
概要 前回、WordPressで構築した自社サービスサイトの表示速度が遅い、という問題が生じていたのですが、CloudFrontを利用することで、サーバーの移行等をせずに、高速化対応できたお話しをいたしました。 ポイントとしてはWordPressが動いているサーバーはEC2上でなく、他社レンタルサーバーや他社VPSでも、CloudFrontを利用できるという点です。 前回記事はこちら 今回は実際に弊社YouWireサービス紹介サイト https://www.youwire.jp/ を設定した際の具体的な設定方法を解説します。 変更前と変更後の構成 変更前 YouWireのサイトは単一のVPS上に構築されており、111.111.111.aaaのGlobalIPアドレスを持っているとします。 DNSサーバー上ではwww.youwire.jpのFQDNとグローバルIP111.111.111.aa
WEBサイトに動画を埋め込む必要があり、実際にやってみたのでその備忘録になります。 対象者 自分のWEBサイトに動画を埋め込みたい方 WEBサーバー内に動画を置きたくない場合 やること Youtubeのよう好きなタイミングで動画を視聴できるオンデマンド配信 自サイトからS3の動画ファイルを読み込み、再生 やらないこと 生放送のようなリアルタイムのライブ配信 動画の自動変換 構成 ユーザー目線で行くと、WEBサイトを経由してCloudFrontを介し、動画ファイルを閲覧する流れになります。 また、AWS内では動画をS3に動画をアップロードし、ElementalMediaConvertにて動画を変換します。 各詳細については後述。 料金 この構成だと若干料金がかかります。動画サイズは小さめのものにしておきましょう。 手順 S3バケット作成 特に細かい設定はいまのところありません。バケット名を入
ポピュラーであるがゆえに、セキュリティリスクが高い ご存じの通り、WordPressは世界で最も利用されているCMSです。 有名であるがゆえのデメリットがあります。攻撃対象になりやすいことです。攻撃者の視点から考えると、一つの脆弱性を見つけることができれば、より多くのサイトを攻撃することができます。 サイト運営者は、脆弱性対策をするために定期的なバージョンアップをする必要があります。実際に運用してみるとわかりますが、バージョンアップには多くの工数がかかります。時には動かなくなり、改修が必要になることもあります。 動的にページ表示させるため、表示が遅い（ある程度のサーバースペックが必要） WordPressは、記事の追加や修正、デザインの変更をすると、即時反映されます。毎回、phpを動作させて、動的にページ表示させることで実現しています。 利便性が上がる半面、表示速度が遅くなるというデメリッ
CloudFrontにキャッシュしたS3上のWordPress記事に独自ドメインでアクセスする - Qiita
はじめに 最終的には以下のような構成を目指して構築します。 構築作業の覚書としてQiita記事を作成しておきます。 また、この記事ではRoute53経由で、CloudFrontでキャッシュしたS3上の記事にアクセスする方法を記載します。 前段のEC2とS3の部分は以下の記事で。 WordPressで作成した記事をS3に連携しエンドポイントでホスティングする 本アーキテクチャのメリット ColoudFront CDNを咬ますことで負荷に強くなったりレンダリング速度が上がる S3、Route53との連携が簡単 サーバー容量も気にしなくて良い（訳ではないが、EC2に直接配置するよりはまし） WordPressが稼働できればいいのでインスタンスタイプも小さくてよくなる Route53は可用性100% 構築手順 前提 ドメインをお名前.com等で取得していることが前提になっています。 後述のRout
はじめに CloudFrontのOrigin Access Control（OAC）がLambda Functions URLに対応しました。 つまり、Functions URLとCloudFrontのインテグレーションが実現できるようになりました！うおおおお！ と、このアプデの何がすごいの？ という点がいまいち伝わってない人向けに、この記事ではもろもろの経緯とユースケースを紹介します。 経緯 Functions URLs、その課題 2022/4にLambdaの組み込みエンドポイントとしてLambda Functions URLが利用できるようになりました。 これは従来ALBやAPI Gateway経由のリクエストしか扱えなかったAWS Lambdaにとって、同期リクエストを受ける便利な選択肢です。API Gatewayでネックだった29秒制限もないので、Lambdaの起動時間（最大900
はじめに DVA 取得と、デプロイについての知識とそれを含めた開発スキルのレベルアップのために色々とやっているのでそれの途中経過をアウトプット。 前提として以下の記事の話があります。 React と DRF の SPA で JWT を Cookieで管理してみた話 もくもく会アウトプット:Django で JWT を Cookie で処理するやつを理解したい やったこと フロント側(React)を CodePipeline・CodeBuild・Route53・CroudFront・S3 の構成でデプロイ サーバー側(DRF)を EC2 インスタンス 1 台を使ってデプロイ 上記を Https でやり取りするようにして連携 ひとまず今回は Code シリーズを使った S3 静的 Web ホスティングでの React デプロイと同時にクロスオリジンでの SPA デプロイの体験を行うというのがテ
【やってみた】 Amazon Lightsail インスタンスと AWS CloudFront を使って HTTPS 化してみた | DevelopersIO
現在は Secury Hub に発報される内容であるため、よりセキュアな方法としては Lightsail ロードバランサーで SSL 終端する方法も検討してください｡ テクニカルサポートの丸屋 正志(まるちゃん)です｡ 1. 今回使用する AWS サービス一覧 【Amazon Lightsail インスタンス】 【Amazon Route 53】(Route53) 【AWS CloudFront】(CF) 【AWS Certificate Manager】(ACM) 2. 前提条件 Route53に対して任意のホストゾーンが登録されている必要があります｡ ここでは､ホストゾーンを example.com とします｡ 最終的なアクセス名は下記です｡ a.example.com 3. Amazon Lightsail 側にて Amazon Lightsail のコンソール画面にて､インスタンス
サマリー Webサイトの安全性は、サイバー攻撃の狙いを見抜く洞察力にかかっています。Loggol（ロゴル）は、Webアクセスログを自動的に解析し、隠された攻撃の足跡を発見します。あなたのサイトはいつ、誰に、どのように攻撃されているのでしょうか。 課題 Webサイトのアクセスログには、様々なセキュリティ的な情報が含まれています。しかしながら、これらのログを正しく分析せずに放置しているケースが多く見受けられます。その結果、未知の脅威やサイバー攻撃の兆候が見落とされる可能性があり、Webサイトのセキュリティを確保することが難しくなっています。また、分析を行っているシーンでも、Webのアクセスログ特有の圧倒的な量の前に、作業が追いつかない場合もあるでしょう。Loggolはこうした課題にアプローチし、Webアクセスログのセキュリティ分析を手軽に行うためのソリューションを提供します。 サービス内容紹介
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon CloudFront launches Origin Access Control (OAC)
CloudFrontでCORS設定をするための3つのポリシーについて
CloudFrontの署名付きCookieでプライベートコンテンツの配信 | DevelopersIO
Amazon CloudFront を活用したウェブサイトの可用性向上 | Amazon Web Services
リアルタイムログ出力をサポートしたCloudFrontを試してみた | DevelopersIO
CloudFront からの「アクセス制御-オリジン許可ヘッダなし」エラーを解決する
CloudFront Functions を使用したコンテンツの保護 | Amazon Web Services
CloudFront FunctionsでBasic認証のパスワードをかける | DevelopersIO
S3にSPAはデプロイできるのか -HostingとRouting-
CloudFrontの設定項目（少しかみ砕いて書いてみました） - Qiita
WebSocket API Gateway の前にCloudFrontを置く | DevelopersIO
SPA時代のOGPとの戦い方
【初心者向け】Amazon CloudFront について改めて整理してみた
AWSで動画配信(オンデマンド配信)をするための手順 - Qiita
S3とCloudFrontで、WordPressを静的サイト配信事例｜ディーネット
CloudFrontがLambda Functions URLへのOACに対応！ の何がすごいか - Qiita
AWSを使ってReact・Django(DRF)のウェブアプリをデプロイしたい - Qiita
Loggol(ロゴル): Webアクセスログのセキュリティ分析
delishkitchen.tv
nishispo.nishinippon.co.jp
academy.binance.com
ameblo.jp/masatakayukiya
digital.asahi.com
pocket.shonenmagazine.com