Amazon S3 オリジンへのアクセスを制限する - Amazon CloudFront
CloudFront には、認証済みリクエストを Amazon S3 オリジンに送信するために、オリジンアクセスコントロール (OAC) とオリジンアクセスアイデンティティ (OAI) という 2 つの方法が用意されています。OAC は、Amazon S3 などのオリジンを保護するのに役立ちます。 以下の機能をサポートしているため、代わりに OAC を使用することをお勧めします。 すべての AWS リージョンのすべての Amazon S3 バケット (2022 年 12 月以降に開始されたオプトインリージョンを含む) AWS KMS による Amazon S3 サーバー側の暗号化 (SSE-KMS) Amazon S3 に対する動的なリクエスト (PUT と DELETE)
エンジニアHub > 記事一覧 > AWSに関するありがちミスとその対策～EC2、S3、RDS、Lambda、CloudFrontの場合 AWSに関するありがちミスとその対策～EC2、S3、RDS、Lambda、CloudFrontの場合 AWS入門者が基本として知っておくべき知識を、AWS導入＆運用サポートのプロである、アイレットのエンジニア3名に聞きました。多くのAWSユーザーに支持されるAmazon EC2、Amazon S3、Amazon RDS、AWS Lambda、Amazon CloudFrontそれぞれの勘所やオススメの設定を、余すところなく紹介してもらいます！ なぜ、AWSを選ぶのか？ Amazon EC2～インスタンス起動後はプライベートIPを設定できないので注意 Amazon S3～S3はディスクではない。マウント非推奨の理由 RDS～自動スナップショットの保持期間を
事の発端 社内から静的コンテンツをホストしてHTTPS使える環境が欲しいんだよねー。と要望を受けた。 私はAWSが得意なので考えた。 「静的コンテンツならs3か」 「s3でHTTPSならs3の前段にCloudFrontでSSL証明書入れるか（ちょっと面倒だな）」 「CloudFrontにSSL入れるなら無料のACMだな」 「ACM使うならメール認証だしSES要るな（面倒くせぇ）」 「SESでメール受信するならs3・・・・・・・・・・」 ガシャーン！（ちゃぶ台の音） 「俺がしたいのはこれじゃない感」 ということで 何か上の環境を一発で作れるツールあるかなぁ。と調べているとNetlifyというサービスが引っかかった。 Netlifyってなに？ どうも静的コンテンツをホストしてくれて、SSLが使えるとな。Githubと連携して？ ふむふむ。使ってみよう。 ということでGithubにリポジトリを作
背景 社Webを今まではレンタルサーバでHostしていたのですが、フォーム以外は極めてStaticな内容なので今流行りのサーバーレスな環境に移行してナレッジを貯め込みながらもコスト削減したいというところです。なお、すでに過去の偉人たちが残してくださっているドキュメントが多数ございますので、本記事では具体的にハマりそうなポイントを中心に書いていきたいと思います。 Before 自分が契約しているさくらインターネットさんに置いていました。フォーム部はphpで社内のSlackに飛ばすというものになっておりました。 After 大枠で下記な感じで対応しました。1 Hostはs3 SSL証明書はAmazon Certificate Manager && cloudfront フォームはStacktodoで相変わらずSlackに飛ばす Route53からCNAMEをcloudfrontに向ける s3で
Github, CircleCI, S3, CloudFront, Middlemanを活用して、https対応のサーバレスで自動deployなWEBサイト構築AWSS3middlemanCircleCICloudFront この記事は リクルートライフスタイル Advent Calendar 2016 の15日目の記事です。 @MomokoAsai です。社内ではFirebaseの推進を行っております。 それではさっそく本題に。 実現すること 「Github, CircleCI, S3, CloudFront, Middlemanを活用して、https対応のサーバレスで自動deployなWEBサイト構築」です。 コーポレイトサイトなどの動的要素がないサイトは、簡単実装＆低コスト運用が出来るような構成にしてしまいましょう。 そして、https対応をしていると、SEO的な優遇があり、将来的に
How To: Hosting on Amazon S3 with CloudFront
A few weeks ago my DNS provider Zerigo sent an email stating that due to recent infrastructure upgrades they would need to raise their prices. For my meager DNS needs that ended up being a huge price hike: from $39 per year to $25 per month1. Prices were set to take effect a month later. I decided to put my current dev work — designing and building new photoblog functionality to showcase my Japan
CloudFront でプライベートコンテンツを配信 CloudFront でプライベートコンテンツを配信するには、署名付き URL を使う方法が以前からありました。それに加え、今年3月に署名付き Cookie が使用できるようになりました。 Amazon Web Services ブログ: Amazon CloudFront 署名付きクッキーによるプライベートコンテンツ配信 ということで、今回は CloudFront の署名付き Cookie を使ったプライベートコンテンツの配信を試してみたいと思います。 オリジンアクセスアイデンティティの設定と CloudFront キーペアの作成 署名付き Cookie を使ったプライベートコンテンツの配信を行うには、まず以下の作業が必要です。 オリジンアクセスアイデンティティの設定 CloudFrontキーペアの作成 これらについては以下の記事と全
怖話を作っていてインフラを含めた設計で迷っている箇所がいくつか溜まってきたのですが、もしいい方法があったら教えて欲しいという点をブログに書いていきたいと思います。 前提 エンジニアは僕一人だけなので極力手間を減らしたい怖話は広告モデルなのでアクセス辺りの収益が低い。なるべく安く（できれば無料に）したいデザイナーやインターンの人も開発するので複雑にしたくない（例えば怖話をローカルで開発する環境を作るのにredisとかfluentdとかいろんなサーバープロセスを立てないと画面が確認できないとか） 画像の置き場所に困る怖話はアクセス負荷的にappサーバーの2台目が必要かな？ぐらいの状態にあります。 appサーバーが複数台になると画像などのアップロードされるファイルの置き場を共通にする必要が出る。 一度はappサーバー2台でS3 + CloudFrontにしましたが、転送料が高いからappサーバー
2014-12-08 06:18:22 UTC 2014-12-08T06:18:22.723Z 6alf80tr75guxrdo lambda2cw Started 2014-12-08 06:18:24 UTC START RequestId: 18e0b9ed-7ea2-11e4-bae6-95e15fd35a15 2014-12-08 06:18:24 UTC 2014-12-08T06:18:24.262Z 18e0b9ed-7ea2-11e4-bae6-95e15fd35a15 processing s3://lambda2cw/logs/2014-12-08-06-18-18-EF79DF76713F7118 2014-12-08 06:18:25 UTC 2014-12-08T06:18:25.563Z 18e0b9ed-7ea2-11e4-bae6-95e15fd35a1
準備 AWSのアカウント 動画ファイル S3のバケット バケットの作成 今回は、"c2-video-test"というバケットを新規に作成。Tokyoリージョンとした。 Static Website Hostingの設定 Enable website hosting に変更 Index Document の設定が必要だったので、"index.html"と入力 Endpointは以下のとおり Endpoint: c2-video-test.s3-website-ap-northeast-1.amazonaws.com Permissionの設定 Add bucket Policyをクリックし、 ファイルのアップロード index.html と mp4ファイルをアップロード CloudFrontの設定 Create Distribution AWSの管理画面から、Create Distribut
確かに Dropbox にファイルを保存して public url だとちょっと遅い。自分は Gyazo で撮ったスクリーンショットを dropbox に放り込んで blog に貼る、というのを一時やってたけど GET が遅いので結局やめてしまった。 Gyazo x Dropboxで簡単スクリーンショット共有 - プログラミングノート ここにやり方がある。相当に便利なんですけどね。 さて、「遅いのがリージョンのせいなら速いリージョンにして更にCDNを挟めばいいじゃない」ということでちょこっと Quick Hack してみるとしましょう。Gyazo の画像保存先を Amazon S3 にして、S3 に保存された画像を CloudFront (AWS の CDN) で配信するように変更してみます。あらやだ便利･･･！ でも従量課金 ＼(＾o＾)／ ちなみにわざわざ CloudFront を使わ
こんにちは、せーのです。今日はS3の画像をCloudfrontで配信する際のコツを自動化してしまおう、という試みです。 Cloudfrontキャッシュコントロールおさらい Cloudfrontは静的、動的関わらずキャッシュしてくれるとても便利なCDNサービスですが、Cloudfrontにてキャッシュしてくれる時間（TTL）は基本Cache-Control max-ageヘッダやExpiresにて制御します。更にCloudfront自体の設定にも[minimum TTL]というものがあり、これはヘッダで設定されたキャッシュ時間を強制的に上書きするためのものです。 ここで理解しておきたいのが「ヘッダとminimum TTLのキャッシュ時間の関係」です。詳しくはこちらの記事に書いてありますが、基本的には「キャッシュコントロールはヘッダありき。ヘッダの設定より長く強制的に上書きしたい時にminim
ども、大瀧です。 ソフトウェア配布の手段として、Amazon CloudFrontは非常に強力です。CDNとして世界各地からのアクセスに対して良好なパフォーマンスが期待できますし、多数の同時アクセス負荷を分散させる効果も期待できます。さらにCloudFrontのオリジン(配信元)としてAmazon S3を利用すると、仮想マシンを実行することなくリーズナブルで可用性の高いソフトウェア配信基盤が構成できます。 ただ、S3はWebサーバーとしての機能は一般的なWebサーバーと比べて少ないため、用意されているオプションを理解しうまく活用することが重要です。そこで今回は、S3 Static Website Hostingのリダイレクトルールを利用してYumリポジトリの少し込み入った構成をご紹介します。 構成の概要 まずは、CloudFrontとS3の構成です。Linuxのソフトウェア配布方法としてよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CloudFrontのCustom Error Responseを利用して、S3上にあるSorryページを表示する | DevelopersIO