タグ

CloudFrontに関するrochefortのブックマーク (7)

  • AWS CloudFrontを使って動的にリサイズ可能な画像をセキュアに見れる仕組みを作った | PSYENCE:MEDIA

    画像アップロード時のシーケンス図 今回は大量のuploadが同時に来ることを想定していないのと画像処理はしないものとしています。ここは単にRailsがS3に受け取った画像をuploadして保存したS3のkeyをDBに保存するだけです。このとき、S3に保存するkeyがURLの一部になるので推測不可能なハッシュ値で保存するようにしておきます。もちろん、Railsを通すのでアプリケーション側での認証が可能です。 ちなみに、この部分もオフロードしたい場合は、S3のpresigned URLを発行し、そのURLに対してuploadしてもらうのが良さそうだと料理画像判定のためのバックエンドアーキテクチャを見て作った後に思いました。 画像取得時の処理シーケンス 画像取得時のシーケンス図 署名付きURLは、画像リストの取得時にCloudFrontが使う秘密鍵と同じ鍵でURLを署名してクライアントに返します

    AWS CloudFrontを使って動的にリサイズ可能な画像をセキュアに見れる仕組みを作った | PSYENCE:MEDIA
    rochefort
    rochefort 2018/06/08
    これはreally niceだ
  • 【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました! | DevelopersIO

    こんにちは、せーのです。今日はまさにAWSらしい、痒い所に手が届くアップデートをご紹介します。 CloudFrontのTTL CloudFrontはそんなに頻繁に更新しないような画像、JS、CSSファイル等のキャッシュに使うのであれば特段の設定なく絶大な威力を発揮しますが、威力が絶大故になかなか思い通りに動いてくれない、というお話もよく聞きます。その内の一つが「キャッシュTTL」に関する設定です。まずはこの記事を御覧ください。 CloudFrontのキャッシュ時間(TTL)はどの程度なのか 例えばS3の画像をCloudFrontで配信する場合、24時間がデフォルトでキャッシュされます。何も設定を加えなければ画像を差し替えようが削除しようが24時間は同じ画像が表示され続けます。これを15分くらいのキャッシュでどんどん更新していきたい、という場合は各画像オブジェクトに対してmeta-dataで

    【新機能】Amazon CloudFrontに「Maximum TTL / Default TTL」が設定できるようになりました! | DevelopersIO
  • AWS再入門 Amazon CloudFront編 | DevelopersIO

    はじめに 当エントリはDevelopers.IOで弊社AWSチームによる2015年アドベントカレンダー 『AWS サービス別 再入門アドベントカレンダー 2015』の3日目のエントリです。 昨日2日目のエントリは大瀧の『Amazon VPC』でした。 このアドベントカレンダーの企画は、普段AWSサービスについて 最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基的な部分を見つめ直してみよう、解説してみようという コンセプトが含まれています。 日3日目のテーマは『Amazon CloudFront』です。 目次 Amazon CloudFrontとは CloudFrontの仕組み CloudFrontの基的な使い方 ユースケース 高度な機能 あわせて読みたい公式情報 さいごに Amazon CloudFrontとは Amazon Cloud

    AWS再入門 Amazon CloudFront編 | DevelopersIO
  • AWS Black Belt Techシリーズ Amazon CloudFront

    4. Contents  Delivery  Network •  ⼤大規模なアクセスも世界中にあるエッジのキャパシティを 利利⽤用して効率率率的に配信可能なサービス –  ユーザからのアクセスを最も近いエッジサーバに誘導することでユーザへの 配信を⾼高速化 –  エッジサーバでは、コンテンツのキャッシングを⾏行行い、オリジンに負荷をかけ ず効率率率的に配信 オリジンサーバ Amazon CloudFront オリジンサーバ 台数の削減 レスポンス向上 負荷軽減 リクエスト 配信 リクエスト キャッシュから配信 キャッシュ コンテンツ取得 CDN クライアント 6. 現時点のエッジロケーション Europe Amsterdam, Netherlands(2) Dublin, Ireland Frankfurt, Germany (3) London, England (3) Madrid,

    AWS Black Belt Techシリーズ Amazon CloudFront
  • Amazon CloudFrontの監視 ~ mackerel-plugin-aws-cloudfrontを読み解く - そーだいなるらくがき帳

    この記事は Mackerel プラグインアドベントカレンダー(全部CRE) の21日目です。 qiita.com soudai.hatenablog.com それでは21日目は mackerel-plugin-aws-cloudfront です。 ※2018/12/21 追記 MackerelAWSインテグレーションにCloudFrontも追加されています。 mackerel-plugin-aws-cloudfrontはAWSが提供する Amazon CloudFront 専用プラグインです。 github.com インストールと設定手順 Amazon CloudFrontのプラグインは CloudWatch と同等の内容を可視化してくれるプラグインです。 プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 インスト

    Amazon CloudFrontの監視 ~ mackerel-plugin-aws-cloudfrontを読み解く - そーだいなるらくがき帳
  • できた!S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法 | DevelopersIO

    CloudFrontをS3 オリジンで利用するとき、「CloudFrontをバイパスしたアクセスを制限」「インデックスドキュメントを返す」という要望は少なくないのではないでしょうか?出来そうで出来なかった共存を Lambda@Edge で解決! ちょっと伝わりにくいタイトルですが、やりたいことは以下の2つです。 CloudFront の S3 オリジンには直接アクセスさせない(CloudFront をバイパスした S3 へのアクセスをブロック) オブジェクト指定のないアクセス(末尾"/"の URL アクセス)にはインデックスドキュメントを返す(サブディレクトリも含む) 画にするとこういうことです↓ 「CloudFront をバイパスさせない」という点でまず考えるのは、オリジンアクセスアイデンティティでかと思います。そして、「オブジェクト指定のないアクセスにインデックスドキュメントを返す」と

    できた!S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法 | DevelopersIO
  • 1