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
CloudFrontで特定のパスへのアクセスをリダイレクトさせる | DevelopersIO
こんにちは、坂巻です。 今回はCloudFrontを利用し、以下2つの構成で特定のパスへのアクセスをリダイレクトしてみたいと思います。 CloudFront + Custom Origin(ALB) CloudFront + S3 Origin（ウェブサイトホスティング） CloudFront + Custom Origin(ALB) 構成 https://region.nochan.tk/nekoへのリクエストは、CloudFrontを経由させALBの機能でhttps://dev.classmethod.jpにリダイレクトさせます。（httpの場合はhttpsにリダイレクト） 同様にhttps://region.nochan.tk/inuへのリクエストはhttps://twitter.com/classmethodにリダイレクトさせます。 それでは、リソース毎の設定をみていきたいと思いま
Amazon CloudFront のアクセスログを大規模に分析する | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront のアクセスログを大規模に分析する 多くの AWS の顧客が、グローバルなコンテンツ配信ネットワーク (CDN) サービスである Amazon CloudFront を使用しています。低いレイテンシーと高い転送速度で、ウェブサイト、動画、API 操作をブラウザやクライアントに配信します。 Amazon CloudFront は、キャッシングまたはウェブアプリケーションファイアウォールによって、大量の負荷や悪意のあるリクエストからバックエンドを保護します。その結果、バックエンドに届くのはすべてのリクエストのごく一部になります。Amazon Simple Storage Service (S3) へのすべてのリクエストの詳細情報とともにアクセスログを保存するように Amazon CloudFront を設定するこ
CloudFrontのアクセスログを高速に集計する - Qiita
CloudFrontのアクセスログ集計 サービスを構築するときにCDNであるCloudFrontを前面においてインフラ構築することが多いと思います。 この構成の場合、全てのアクセスはCloudFrontを経由するため、 CloudFrontのログ解析が極めて重要になります。（アクセスログがCloudFrontに集約される） AWS Athenaを使うことで出力されたアクセスログファイルに対してSQLでのデータ集計が可能になります。 Athenaに関してパーティショニングがほぼ必須なのですが、 CloudFront+Athenaのパーティショニング構成に関して今ひとつまとまっている情報がなかったので この記事にまとめておきます。 次図のような構成を想定しています。 CloudFrontにてアクセスログファイルをS3バケットに格納するように設定します。 この例の場合、S3のlogs-cloud
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
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からカスタムオリジンまでの通信をHTTPS化する方法を2パターン | DevelopersIO
西澤です。サーバ証明書を利用した試験もACMが利用できるようになってやりやすくなりましたね。今回は、CloudFrontからカスタムオリジン（今回はELBオリジンの想定です）までの通信をHTTPS化したいときの構成パターンについて整理します。 前提条件 CloudFrontからAWSの各VPC内に用意したAWSリソースまでの通信は、インターネットを経由することになります。VPCに入るまでの通信はHTTPSにしておきたいというのが今回やりたいことです。ここで、CloudFrontからカスタムオリジンまでの通信をHTTPSにしたい場合には、オリジン側で下記のいずれかの証明書を用意する必要があります。 証明書のドメイン名の 1 つは、次の値の 1 つまたは両方と一致する必要があります。 ディストリビューションの該当するオリジンの [Origin Domain Name] に指定した値。 Host
CloudFront で SSL/TLS 証明書を使用するための要件 - Amazon CloudFront
このトピックでは、SSL/TLS 証明書の要件について説明します。これらの要件は、特に注記がなければ、以下の両方の証明書に適用されます。 証明書の発行者 AWS Certificate Manager (ACM) で発行された証明書を使用することをお勧めします。ACM からの証明書の取得の詳細については、AWS Certificate Manager ユーザーガイドを参照してください。CloudFront で ACM 証明書を使用するには、米国東部 (バージニア北部) リージョン (us-east-1) の証明書をリクエスト (またはインポート) していることを確認します。 CloudFront は Mozilla と同じ認定権限 (CA) をサポートしているため、ACM を使用しない場合は、「Mozilla に付属する CA 証明書一覧」の CA が発行する証明書を使用します。証明書の取
Nginxを利用してCloudFront対応のWordPressを環境を最適化してみた | DevelopersIO
はじめに AWSチームのすずきです。 先日紹介させて頂いた、CloudFront、ELB、EC2を利用したWordPress環境。 ELBやEC2のパブリックIPアドレスを知り得た第三者により WordPressの実行環境が直接攻撃される事があった場合、DDoSなどの被害を受けやすいリスクがありました。 今回、この対策としてNginxをリバースプロキシとして導入し、 CloudFrontを経由と、正しい認証情報を持つ管理者のリクエストのみWordPress環境に中継、 他の不正なアクセスは遮断する方法を紹介させていただきます。 構成図 環境 OSは、Amazon Linux2のAMI (amzn2-ami-hvm-2.0.20190508-x86_64-gp2) を利用しました。 CloudFront、ELB、EC2の各リソースは、以下の環境を一部変更して利用します。 CloudFront
Lambda@Edgeを使いNginxでクライアントIPアドレスを受け取る | DevelopersIO
コンニチハ、千葉です。 CloudFront + ELB + Nginxの構成で、NginxのログにクライアントIPアドレスを保存したいという要件がありました。 色々な方法があるので、整理してみました。また、Lambda@Edge使ったらなんとかいけるんじゃないかと思い試してみたらいけたのでお届けします。今回はNginxで試しましたがApacheや他アプリでも応用できるんじゃないかと思います。 いろいろなやり方 案1:X-Forwarded-Forを使ってCloudFrontのIPアドレス帯をメンテする X-Forwarded-Forの値を使って、remote_addrを書き換えるという内容です。 例えば、以下のようにnginx.confを書き換えます。 set_real_ip_from VPCのセグメント; set_real_ip_from CloudFrontのIPセグメント1; se
CloudFront のキャッシュ時間に関する問題をトラブルシューティングする
Amazon CloudFront ディストリビューションがオブジェクトをキャッシュする時間を指定しようと考えて、オリジンに Cache-Control または Expires ヘッダーを追加しました。しかし、CloudFront が指定した時間においてオブジェクトのキャッシュを実行しない、またはCloudFront がキャッシュを一切行わないことがあります。 解決策 Cache-Control または Expires ヘッダーに設定したディレクティブが互いに競合していないことを確認します。Expires ヘッダーの代わりに Cache-Control max-age ディレクティブを使用することをお勧めします。両方に値を指定した場合、CloudFront は Cache-Control max-age に設定した値のみを使用します。 CloudFront ディストリビューションに設定した
[AWS] Amazon CloudFrontのキャッシュ無効化(TTL設定) | DevelopersIO
こんぬづは、昨日飲みの席でインターン時代の先輩から「ドープ」というスラングを教えてもらいました田中です。 "Awesome"とかと同じ感じで「スゲェ」とか「最高」とかの意味らしいです。イケてないのは「ノー ドープ」と言う用法らしいです。 今日はCloudFrontのキャッシュ無効化設定の方法を紹介します。 TTL設定とは まずTTLというのはTime to liveの省略で、生存期間を示す言葉です。 今回はCloudFrontのキャッシュのTTLなので、CloudFrontのエッジサーバーにキャッシュが保存される期間の設定の話になります。 キャッシュの無効化方法 オリジンサーバーのCache-Controlを設定する 今回の例はEC2上のnode.js/expressで設定。 レスポンスヘッダのCache-Controlにno-cacheか、max-ageを0に設定します。 // inde
![[AWS] Amazon CloudFrontのキャッシュ無効化(TTL設定) | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/05bf92c3dad6e282bf2cded7bb4b61f42547e50e/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F05%2FAmazon_CloudFront.png)
サーバーレスの実践といくつかの罠、そしてこれから - Qiita
[ニュースメディアWWD JAPAN.comを支えるSPA+Aurora+サーバーレス, サーバーレスの現実と夢と今 にも同様のトピックをまとめました] WordPress + MovableType で運用されていた WWD JAPAN.com というウェブメディアをサーバーレスに置き換えました。 2016 年 1 月からモックアップの開発を始めて、9 月のローンチまでに大部分の古典的リソースを捨て、トラフィックの影響を受けないサーバーレスなアーキテクチャへと刷新できました。 TL;DR AWS を利用したサーバーレスアーキテクチャは以下のような構成になりました。 リクエストを受け付けるのは CloudFront フロントエンドは S3 で HTML/JS/CSS バックエンドは Lambda で Node.js 管理画面専用に EC2 で WordPress( PHP ) 旧構成と新構
CloudFrontを使用してS3静的ウェブサイトを提供する手順 | DevelopersIO
S3静的ウェブサイトを、CloudFrontを通じて提供したいと思います。今回はいくつかの前提の元、実施してみました。 DNS管理者、AWS管理者、コンテンツ管理者がそれぞれ別の部などでわかれ、AWSにて提供するウェブサイトは随時増えていく想定です。 こんにちは、坂巻です。 S3静的ウェブサイトを、CloudFrontを通じて提供したいと思います。今回はいくつかの前提の元、実施してみました。 前提／構成 DNS管理者、AWS管理者、コンテンツ管理者がそれぞれ別の部等にわかれ、AWSにて提供するウェブサイトは随時増えていく想定です。イメージは以下となります。 DNS管理者 AWS外のネームサーバでDNSレコード設定等を行います。ドメイン、SSL証明書をAWS外で調達します。調達した証明書はAWS管理者に連携します。 AWS管理者 CloudFront、S3バケットなど、AWSの構築、管理を行
CloudFront を使用してプライベートコンテンツを供給する - Amazon CloudFront
インターネット経由でコンテンツを配信する多くの企業が、選ばれたユーザー (料金を支払っているユーザーなど) のドキュメント、ビジネスデータ、メディアストリーム、またはコンテンツに対して、アクセスを制限する必要があると考えています。CloudFront を使用してこのプライベートコンテンツを安全に供給するには、以下の方法を使用できます。 特別な CloudFront 署名付き URL または署名付き Cookie を使用してプライベートコンテンツにアクセスするようユーザーに要求します。 オリジンサーバー (Amazon S3 やプライベート HTTPサーバーなど) 上のコンテンツに直接アクセスするURLではなく、CloudFront の URLを使用してコンテンツにアクセスするようユーザーに要求します。CloudFront URL を要求する必要はありませんが、ユーザーが署名付き URL や
CloudFront+S3で署名付きURLでプライベートコンテンツを配信する | DevelopersIO
はじめに S3をWebコンテンツの置き場所として使う場合、Webアプリケーション側でそのS3上のコンテンツに対するPre-signed URLを生成することで、Webアプリケーションで認証されたユーザに限りコンテンツにアクセス可能とするような仕組みを作ることは良くあります。 ただしこのS3アクセス用として生成したPre-signed URLは、CloudFrontを経由した形では使えません。 CloudFront経由で、限られたユーザのみS3からコンテンツを取得出来るようにするためには、CloudFront用の署名付きURLを発行する必要があります。 そこで今回は、CloudFront+Amazon S3を組み合わせて、署名付きURLを使った制限されたコンテンツ(プライベートコンテンツ)の配信を試してみました。 やってみる 今回試したことは、以下のAWSのドキュメントを参照しながら行ってい
WordPressをCloudFront+ALBにて配信する - Qiita
こんにちは。wevnal大城です。 前回(wpXクラウドで運用しているWordPressをAWS for KUSANAGIに移行した話)、WordPressをwpXクラウドからAWSへ引っ越しました。 今度は高トラフィックに対応できるようにCloudFront経由でサイトを配信できるよう設定します。合わせてサイトをSSL化するためにApplication Load Balancer(以下、ALB)を利用します。 また、SSL証明書はAWS Certificate Manager（以下、ACM）を利用して取得します。 目次 1.構成 2.Route53の設定 3.ACMによるSSL証明書の取得 4.ALBの設定 5.CloudFrontの設定 構成 前回作ったEC2の通信の前段に高トラフィック対応としてのCloudFrontとサイトSSL化のALBを配置します。 AWSではCloudFron
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Loading...
S3にCloudFrontを通すことで月20万ぐらい節約した話 - Qiita
AWS CloudFrontとS3、ALB(ELB)でSPAを構築する - ブロックチェーンエンジニアの備忘録