AWS Systems Manager から直接 AWS API をたたけるようになりました！ | DevelopersIO
AWS Systems Manager から AWS API を呼び出すことができるようになりました。CloudFront のキャッシュクリア（Invalidation）を例に、実際に試してみます。 本日（現地時間の 8/28）、AWS Systems Manager に AWS API を直接呼び出す機能が追加されました。控えめに言って 革命です。 何が出来るようになった？ YAML を書くだけで、AWS CLI から出来ること はたいていのことが AWS Systems Manager のマネジメントコンソールから実行可能になった もちろん従来通り、実行前に承認を待ったり、権限をその YAML （ドキュメント）に AssumeRole させることも可能 オペ業務的にいえば、AWS CLI を順に実行するだけのようなシェルスクリプトは ほぼ全てこれに置き換えることが可能 と言えば良いでし
コスメのクチコミアプリ、LIPSを開発しているAppBrewのエンジニア@anoworlです。 最近はアプリのディスプレイ広告の立ち上げを行ったり、メンバーの@_ha1fさんにビシバシしごかれながらiOS開発をよちよち歩きでやっていました。継続してまだ見ぬ仲間も探しています（訳: 採用活動もしています）！ この記事では「APIサーバを改修せずにAWSのCloudFront & S3 & Lambda & MediaConvertを使ってフルマネージドで動画の自動圧縮 & 配信を行う方法」を紹介したいと思います。 完成図。赤が動画アップロード時の自動圧縮の流れ。青が動画取得時の流れです。 目的: UX向上 & 費用削減 前提: 動画はS3にアップロードしている 方針: アプリ・APIサーバに一切改修を入れない 課題: 動画圧縮中のアクセスのさばき方 Tips: Elastic Transco
よく訓練されたアップル信者、都元です。 CloudFrontはContents Delivary Network、所謂CDNですが、ざっくりと言ってしまえば、要するにキャッシュ機能を持ったHTTPリバースプロキシです。CloudFrontでは、元々のコンテンツ提供をするサーバのことをオリジンと呼びます。 CloudFrontでは、オリジンから提供されるコンテンツを、エッジサーバと呼ばれる世界各地に点在するコンテンツ配信専用のサーバ上にキャッシュすることによって、高い転送速度パフォーマンスを発揮しています。しかし、キャッシュというのはオリジン上のコンテンツの更新があった時に、内容が乖離してしまうという問題があります。 通常、CloudFrontは静的コンテンツ *1の配信に利用します。しかし、静的なコンテンツではあるのですが、定期的にファイルの差替えを行う、という可能性が無いわけではありませ
はじめに S3をWebコンテンツの置き場所として使う場合、Webアプリケーション側でそのS3上のコンテンツに対するPre-signed URLを生成することで、Webアプリケーションで認証されたユーザに限りコンテンツにアクセス可能とするような仕組みを作ることは良くあります。 ただしこのS3アクセス用として生成したPre-signed URLは、CloudFrontを経由した形では使えません。 CloudFront経由で、限られたユーザのみS3からコンテンツを取得出来るようにするためには、CloudFront用の署名付きURLを発行する必要があります。 そこで今回は、CloudFront+Amazon S3を組み合わせて、署名付きURLを使った制限されたコンテンツ(プライベートコンテンツ)の配信を試してみました。 やってみる 今回試したことは、以下のAWSのドキュメントを参照しながら行ってい
AWSを活用して全国ネット番組(NHK)によるアクセス急増を乗り切った具体的手法 | Cerevo TechBlog
まつけんです。 前回のWBSでの紹介に引き続き、今回はNHK「サキどり」にCerevoを紹介いただける機会に恵まれました。というわけで、前回同様に急激なアクセス増が放送日に集中することが予想されるので、いくつかの負荷対策をして乗り切りました、という話の第二弾になります。 今回はある程度の対策する時間があったため、前回の構成よりも急場しのぎでない対策をせっかくなのでやりました。そういった表示の高速化も含めたいくつかのテクニックを紹介したいと思います。 ちなみに、結果だけを先に書きますと、この対策をしている状態であれば、m1.small x 2台(ELBの配下に居ます。)がカスタムオリジンとして存在しているだけで、まったく問題なく放映時のアクセスをCloudFrontが捌いてくれました。（CloudFrontのキャッシュ時間が適切であれば、オリジンの性能があまり関係ないのは当然ですが。） 今回
CloudFront + S3 + Lambda@EdgeでBasic認証付きお手軽 静的サイト ( ランディングページ ) 環境を作った | Recruit Tech Blog
こんにちは。開発支援Gでインフラ運用をしている大島です。 Lambda@Edgeとは、CloudFrontが配信するコンテンツをカスタマイズする関数を実行できる機能のことです。本記事では、これを使ってランディングページ ( 以下LP ) のような静的サイトに対してお手軽にBasic認証を設置する話です。 また、最後におまけ程度ですが、この構成に到るまでの背景も書いていますのでもしよろしければご覧になっていってください。 LP環境をCloudFrontで作るのにBasic認証はどうしよう ? 開発中はデバッグ用の要素や社内開発環境へのリンクなども含まれていたりすることを考えると、何かしらの方法でアクセスを制限する必要があります。nginxなどのwebサーバであればBasic認証の設置も簡単ですが、今回はCloudFront + S3なのでそうそう気軽には設置できません。 そんなときに便利なの
Amazon CloudFrontとEC2(Nginx)で作る国・地域対応Webサイト構築 | DevelopersIO
ども、大瀧です。 CloudFrontによるグローバル対応サイトの構築は、横田の以前のエントリーでRoute 53と組み合わせを紹介済みですが、Route 53のレイテンシーレコードはAWSのリージョンごとの区分けなので、「日本」向けや「台湾」向けなど特定の国や地域別にコンテンツを区別する用途には向いていません。 そこで今回は、7月にリリースされたCloudFrontのジオターゲティング機能を利用して、国・地域に対応するWebサイトを構築してみます。まずは構成図をどーんと。 CloudFrontのジオターゲティングは国・地域の地理データベースとクライアントの接続元IP照合するのですが、その結果をオリジンに転送するHTTPリクエストのヘッダに付与します。国・地域によってオリジンを振り分ける機能ではありませんので、CloudFrontのジオターゲティングによって付与されたHTTPヘッダを解釈す
Amazon S3 + Amazon CloudFrontでWebサイトを構築する際にS3静的Webサイトホスティングを採用する理由 | DevelopersIO
はじめに 静的Webサイトを構築する際にAmazon S3とAmazon CloudFrontを利用するアーキテクチャは定番ですが、これらを利用したアーキテクチャには2つの手法があります。 オリジンアクセスアイデンティティを使って、S3バケットへのアクセスをCloudFrontディストリビューションからのみに制限する方法 S3の静的ウェブサイトホスティングを有効化し、CloudFrontにカスタムドメインとして設定する方法 前者がベターに思えるかもしれませんが、後者の方が良い場合もあります。それは ランディングページなどのシンプルなHTMLベースで構築するWebサイトの場合 です。 本記事では、どういった理由でS3のウェブサイトホスティングを採用するか解説します。 リダイレクト設定がかんたん 静的Webサイトホスティングにはリダイレクトを自由にカスタマイズできるRedirection Ru
過去このブログでも取り上げてますが、AWSにおいて脆弱性診断を実施する際に、侵入テスト申請というものが必要となります。 ペネトレーションテスト（侵入テスト）- AWS セキュリティ｜AWS この侵入テスト申請について、実は2017年9月頃にアップデートがあり、申請フォームの内容が従来と変更されておりますので、こちらに変更点などをちょっとまとめておきます。 今後、侵入テストを申請される方の少しでもご参考になれば幸いです。 また、アカウントが無い方は申請フォームの中身を見ることができないので、キャプチャした現時点（2017年10月20日）の申請フォームの画像データもアップしておきます。 従来との変更点は？ 従来との大きな変更点として、今まではEC2やRDSしか診断の対象とすることができなかったのですが、以下のマネージドサービスを正式に診断の対象とすることができるようになりました！ EC2 RD
CloudFrontで素早くコンテンツを更新させたい場合にTTLを短くしInvalidationを行わないキャッシュ戦略を考える | DevelopersIO
CloudFrontで素早くコンテンツを更新させたい場合にTTLを短くしInvalidationを行わないキャッシュ戦略を考える CloudFrontで頻繁に更新されるコンテンツではないため長くキャッシュさせておきたいが、更新があった場合はすぐに反映させたい、というケースではTTLを短くしておきましょう。オリジンからのデータ本体の転送は更新の際にしか実施されません。 はじめに 清水です。AWSのCDNサービスであるAmazno CloudFrontを利用する場合に、頻繁に更新されるファイルではないため、なるべく長くCloudFrontにキャッシュさせオリジンへのアクセスやデータ転送の負荷などは極力少なくしたい。けれどオリジン側でファイルの更新があった場合は、なるべく早くCloudFront側でもキャッシュの反映を行いたい、といったことがあります。 このようなケースで1つ考えられる方法は、C
By BFLV Amazonの「CloudFront」は、大容量アプリケーション・音楽・動画・オンラインゲームなどのブロードバンドコンテンツの配信を安定かつ低コストで行うためのコンテンツ配信ネットワーク(CDN)と呼ばれるものです。 そんなCloudFrontのDNSにて障害が発生し、CloudFront経由で配信されていたさまざまな画像などのコンテンツが表示されなくなる、という恐ろしい事態が発生。 AWSのCloudFrontのDNSで障害中。いろんなところで影響でまくり。AWSのサイトもめちゃ重いｗｗｗ #AWS #cloudfront #DNS— Shogo Matsudo (@ShowRiseGo) 2014, 11月 27 Instagramなどの大手ウェブサービスにもその影響があり、サイト上に何も表示されないという非常事態に。 instagram when amazon's d
概要 AngularなどのSPAをS3+CloudFrontで表示する方法についてです。 要件 SSL/TLSを使いたい https://example.com/hoge のようなサブディレクトリのようなパスで403にならないようにしたい ↑のようなパスでもOGPがきちんと表示される リロードしても404にならない S3バケットのファイルには直接アクセスできないようにしたい 以前のケースとの比較 過去に S3 + CloudFrontにした時にハマったこと - Carpe Diem Angularで作ったサイトでリロードすると404エラー - Carpe Diem で似たようなケースに対応しました。しかしこれらは先の要件である 3. ↑のようなパスでもOGPがきちんと表示される や 5. S3バケットのファイルには直接アクセスできないようにしたい を満たせていませんでした。今回はそちらを考
執筆上の都合でAmazonのほしい物リストをRSS化するAPIを作ってみました。構成的には、次のような形です。 下記のようなURLで取得できます。wishlist_idの部分に公開のほしい物リストのIDを指定したら使えると思います。 https://wishlist-api.takuros.net/prod?wishlist_id=3G4653SB32HMZ ※効果計測の意味を兼ねて、アフィリエイトタグを付けています。 構成上のポイント ほしい物リストからNode.jsのLambdaでスクレイプして、リスト内のタイトルとURL・登録日を取得しています。また次のページがある場合は、再帰的に取得できるようにしています。出力は、RSS 2.0形式のXMLで出力しています。それをAPI Gatewayを利用してHTTPSからキックできるようにしています。CloudFrontとAWS Certifi
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を挟んだ方が安くなる(場合がある) | DevelopersIO
ども、もこ@札幌オフィスです。 AWSの通信利用料を調べる機会があり、アウトバウンド通信のコスト削減をするために試行錯誤していたのですが、「実は動的コンテンツとか静的コンテンツとか深く考えずにCloudFrontを挟んだ方が安くなるのでは」と思い、計算してみたところ良さげだったので、簡単な内容とはなりますがご紹介します。 ※本記事でのアウトバウンドとはCloudFrontを経由出来る通信の事であり、EC2からどこかへファイルをアップロードするなどの通信は対象外となりますのでご注意ください。 TL;DR EC2、ELB、S3のインターネットへのアウトバウンド通信は $0.114〜$0.084 per 1GB ※1 EC2、ELB、S3からCloudFrontへのアウトバウンド通信は無料 CloudFrontのアウトバウンド通信は $0.114〜$0.06 per 1GB ※1 クラスメソッド
AWS Lambda Function URLs（関数URL）がCloudfrontのOACに対応したので試す - Qiita
はじめに AWS LambdaのFunction URLs（関数URL）は、Lambda単体でHTTPSのURLを発行し、HTTPリクエストをトリガーにLambdaを実行出来るようになる、非常に便利な機能です。 API Gatewayと統合せずともLambdaのみでWebAPIを構築出来るようになり、プロトタイピングやマイクロサービスに有用です。 関数URLの制限 ところで、関数URLの実行の認可は、IAMを用いた方法しかありませんでした（IAMロールベースの認可か、認可なししか無かった）。 Cloudfrontをリバースプロキシ的に前段に配置し、関数URLと繋ぐことで、ドメインを当てたりキャッシュを活用したり、便利な訳ですが、その際に上記が問題となります。というのは、CloudfrontからIAMベースのリクエストを行うには、Lambda@Edgeを利用するしかありませんでした（オリジン
AWS テクニカルトレーナーと学ぶ Amazon CloudFront ~ エッジロケーションを使った通信の仕組み - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「Artiste (アルティスト)」です。 AWS を学習していて「Amazon CloudFront はコンテンツ配信の最適化や高速化をするサービスである」ということは知っているけれど、「どのような通信経路になるのか」や「なぜ近くのエッジロケーションへアクセスできるのか」は理解できていないなと感じる方はいませんか ? というのも、トレーニングを受講していただいた方から「Amazon CloudFront の概要だけは知っていたけど、具体的な動作まで理解できた !」と言っていただくことがあります。そこで他にも多くの方に Amazon CloudFront の学習や利用に役立てていただけるよう、「仕組み」に焦点を当てた解説記事を書いてみました。それでは私が自作した図を交えながら順を追って説明していきます ! ま
Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale | Amazon Web Services
AWS News Blog Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale With Amazon CloudFront, you can securely deliver data, videos, applications, and APIs to your customers globally with low latency and high transfer speeds. To offer a customized experience and the lowest possible latency, many modern applications execute some form of logic at the edge. The use
【$13,000→$5,000】AWS S3 コスト削減!! オブジェクト削減とS3 Standardから Glacier Instant Retrievalへの移行 - CARTA TECH BLOG
はじめに 新卒3年目のらぴおです。入社当初からエンジニアとして広告事業を営むZucksでアドネットワークの開発、運用に携わっています。 Zucksでは、2022年夏頃から円安の影響でサーバ費が上昇しコスト削減の温度感が高まっていました。 そこで、 僕が携わるアドネットワークにおいては、少ない作業量で大きい見直し効果が期待できそうなAWS S3のコスト最適化に取り組む ことになりました。 S3全体で月々のコストが $ 13,000 を超えており、特に広告配信関連のログデータが大部分を占めていました。 今回は、僕が実施したコスト削減調査と実施プロセス、その成果を共有します。 S3のコスト削減は、以下のアプローチで行います。 オブジェクト数を減らす 最適なストレージ階層に移行し保存する これらの取り組みにより、月々のストレージコストを $ 13,000 から $ 5,000 に削減 することがで
[アップデート] root ユーザー作業が不要に！Amazon CloudFront で署名付き URL/Cookie 向け公開鍵を IAM ユーザー権限で管理できるようになりました。 | DevelopersIO
本日のアップデートで Amazon CloudFront の署名付き URL および署名付き Cookie に対する公開鍵の管理を、IAM ユーザー権限で行えるようになりました！ Amazon CloudFront announces support for public key management through IAM user permissions for signed URLs and signed cookies IAM ユーザー権限による公開鍵管理が可能に 従来、CloudFront で署名付き URL および 署名付き Cookie を利用する場合、「CloudFront のキーペア」を作成する必要がありました。このキーペアの作成は AWS アカウントの root ユーザーしか行うことが出来ません。そのため必要になった際にアカウント管理者に連絡しキーペアを作成してもらう、
Lambda処理内容 SNSのメッセージから、処理対象となるS3のバケット、キーを取得します。 ログの時刻情報として期待するカラムのデータが日付フォーマットに一致しない場合や、カラム数が異常なレコードはエラーレコードとして除外します。 「request」カラムに含まれるURLを「urlparse」モジュールを利用してパースし、解析時に利用頻度の高い「HOST」や「PATH」を事前に抽出します。 「json」モジュールを利用してJSONエンコードを行い、Firehoseに対しバッチ転送を行います。 4: Firehose 今回、出力先はS3のみとしましたが、Amazon Elasticserach Service、Redshiftと連係も可能です。 Firehoseのバッファ時間はELB(ALB)のログ出力間隔にあわせ、300秒としました。 Firehoseの後処理をLambda関数で実装す
概要 CloudFrontとは CloudFrontはAWSのCDN(Contents Delivery Network)サービスで、Webサイトの前段に入れるだけでサイトアクセスが爆速になります。爆速になる理由は主に下記2点。 初回リクエストはCloudFrontがオリジンにコンテンツを取りに行きますが、2回目以降は超高速でCloudFrontのキャッシュから返答します。ただし、TTL(有効期間)を過ぎたキャッシュは削除されます ユーザーがアクセスするCloudFrontのエッジロケーションは全世界に54ヶ所(2016年1月現在)あり、ユーザーはネットワーク的に最も近いエッジロケーションに誘導されます。それぞれのエッジロケーションは、超広帯域なネットワークと超大容量なキャッシュ処理機構に支えられており、ユーザーがサイジングに悩む必要はありません メディア暴露によるスパイク、いわゆるxx砲
Amazon S3の画像をAWS Cloudfrontで配信するキャッシュコントロールをAWS Lambdaで自動化する | DevelopersIO
こんにちは、せーのです。今日はS3の画像をCloudfrontで配信する際のコツを自動化してしまおう、という試みです。 Cloudfrontキャッシュコントロールおさらい Cloudfrontは静的、動的関わらずキャッシュしてくれるとても便利なCDNサービスですが、Cloudfrontにてキャッシュしてくれる時間（TTL）は基本Cache-Control max-ageヘッダやExpiresにて制御します。更にCloudfront自体の設定にも[minimum TTL]というものがあり、これはヘッダで設定されたキャッシュ時間を強制的に上書きするためのものです。 ここで理解しておきたいのが「ヘッダとminimum TTLのキャッシュ時間の関係」です。詳しくはこちらの記事に書いてありますが、基本的には「キャッシュコントロールはヘッダありき。ヘッダの設定より長く強制的に上書きしたい時にminim
S3/CloudFront/Route53/ACM構成の静的サイトをTerraformで構築 & CircleCIで自動デプロイ - Giftmall Inside Blog
みなさん、はじめまして。ギフトモールの@nori0620です。 ギフトモールはギフト領域にフォーカスしたベンチャー企業で、日本とシンガポールに拠点があります。 今まであまり情報を発信できていなかったのですが、今後積極的に情報を発信していく一環として、このブロクを開始しました。 会社の詳細については、↓のサイトをご覧ください！ https://careers.lucheholdings.com ※現在はサイトリニューアルしております。 ちなみに上記のサイトはS3,CloudFrontな構成でTerraformで構築 、 CircleCIで自動デプロイといった仕組みで管理しています。 本ブログの最初の記事として、このような構成の組み方を解説する記事にしたいと思います。 最近だと単純な静的サイトであればNetlity のようなホスティングサービスを使う選択肢もあると思いますが、弊社ではTerra
こんにちは、藤本です。 先日、Amazon S3 の静的 Webホスティングにコンテンツをデプロイする方法が気になったので考えてみました。ちなみに静的ウェブホスティングだけじゃなく、S3 バケットと Git リポジトリの連携全般に利用できます。 概要 AWS 上で Webシステムを構成する際に、CloudFront のパスルーティングで、静的コンテンツは S3、動的コンテンツは EC2（前段に ELB）にアクセスすることで、低コスト、高可用性な構成を組むことができます。（静的コンテンツのみであればEC2レス） デプロイツールが発展してきて、CIツール、CIサービスを利用することでデプロイの自動化を簡単に実装することができるようになりました。AWS でも CodeDeploy を利用することで、EC2 へのデプロイが自動化できます。最近では Blue/Green デプロイ機能が追加され、既存
「Amazon CloudFront」はAmazonが提供してくれるCDNサービスの1つで、コンテンツを世界各国に分散して配置させることで、ユーザからのアクセスを集中させること無く分散させることと、ユーザは最もネットワーク距離の近いサーバからコンテンツをダウンロードすることが出来るため、ユーザにとっても非常に快適でかつ効率的なアクセスの仕組みを作ることが出来ます。 Amazon CloudFrontでは、世界14ヶ所にエッジサーバがあり、それぞれの場所でコンテンツをキャッシュして配信することが可能です。 で、そんな話を昨日のエントリ「Amazonが従量課金制のCDNサービス「Amazon CloudFront」を開始・・・したので試してみた」にて、"Amazon CloudFront"の概要や実際の速度なんかを紹介したのですが、具体的な使用方法を端折ったので、今日はここに使い方を書き残して
Backup and IT management software | MSP360 Data Protection
MSP360 is a Secure Data Protection and Endpoint Management Platform developed for MSPs and Internal IT Teams.
Next.jsアプリをLambda@Edgeで超簡単にSSRできるserverless-next.jsのご紹介 - Qiita
Next.js をSSR対応でホスティングしたいなら Vercel(旧Now) を使うのが定石だと思います。 Next.jsとVercelはどちらも Vercel社 (旧ZEIT社) が開発しているため一緒に使った際のDXは大変良いものです。 しかし、AWS内で完結できるならそうした方が嬉しい事が多いのでいい方法はないかと調べた所、 serverless-next.jsというServerless Componentのプラグインがよさそうだったのでご紹介したいと思います。 以下のドキュメントの要点をまとめつつ、掘り下げたものです。 https://github.com/danielcondemarin/serverless-next.js/ https://serverless.com/blog/serverless-nextjs/ serveless-next.js 機能と特徴 SSRをL
〜 大晦日に秒間 1 万ユーザを捌くためにやったこと (ロードバランサー編) 〜今回、ロードバランサーは全面的に AWS の Elastic Load Balancing (ELB) を使用しました。 Web API を提供するシステムにはもともと ELB を使う予定だったのですが、静的ファイルの配信などは ClouldFront + S3 という構成でいこうと思っていました。 が、最終的には静的ファイルを配信するシステムも ELB + EC2 という構成になりました。 そのへんの経緯とか、AWS を使うときのシステムのフロント周りの負荷分散にはどういう選択肢があるのかとか、軽くまとめてみようと思います。 静的ファイルの配信には CloudFront を使ったほうがいいのかCloudFront は S3 と併用することで、静的なファイルの配信のことはほとんど考えなくていい、というくらい簡単
cloudpackブログ - EC2の障害復旧パターン
EC2で運用しているサーバが起動しなくなった時の復旧パターンを下記にまとめてみました。 (cloudpackでも下記に近い形で復旧を試みています) 前提条件は、下記を想定しています。 ・ AMIはEBSベースのものを使用 ・ EBSはルートディスク用とデータディスク用の二つを利用 ・ OSはLinux(CentOS 5.x) ・ プレミアムサポートに入っていない ・ 本番運用前に初期AMIを作成 復旧パターンを図で作成しましたので、ご覧ください。 こちらの記事はなかの人（suz-lab）監修のもと掲載しています。 元記事は、こちら
CloudFront + S3 + CloudFront Functions で BASIC 認証をかける
はじめに CloudFront + S3 で静的な Web サイトをホスティングしている。 ステージング環境として同様のサイトを作ったが、超簡単なアクセス制限をかけるために BASIC 認証をかけたい。 こういったケースでは Lambda@Edge を使うのが主流のようだが、最近リリースされた CloudFront Functions を使ってやってみた。 手順 CloudFront Functions のサイドバーに Functions メニューがあるので、そこから以下の内容で Functions を登録する。 function handler(event) { var request = event.request; var headers = request.headers; // echo -n user:pass | base64 var authString = "Basic
本記事は NRIネットコム Advent Calendar 2022 17日目の記事です。 🎁 16日目 ▶▶本記事 ▶▶ 18日目 🎄 初めに 要件 フェイルオーバールーティングとは 構成 実装 CloudFrontからS3にアクセスできるようにする Route53のフェイルオーバールーティングの設定 まとめ 初めに はじめまして、今年NRIネットコムに入社した梅原と申します。アドベントカレンダー17日目の記事を担当します。アドベントカレンダーも残すところ1週間ほどとなりました。2022年4月入社で4ヶ月の研修を経て、基盤デザイン事業部に配属となりました。業務ではAWSを使用したサービスのインフラ運用を担当しています。日中だけ使用するシステムで、稼働時間外にアクセスが来た際にエラー画面ではなくSorryページを配信したいことがあり、方法を考えたのでまとめます。 要件 Sorryページ
ALBのリダイレクト機能とGlobal Acceleratorを組み合わせることで、AWSで固定IPアドレスなフルマネージドリダイレクト環境が構成できます。事情により名前解決をAレコードで行う必要がある場合にベストなリダイレクト環境かと思います。 はじめに 清水です。固定IPアドレスでアクセスできるリダイレクト環境が必要になり、AWSでの構成を考えてみました。S3+CloudFrontのリダイレクト環境だとIPアドレスが可変であるため要件にマッチしません。それならEC2上でHTTPサーバを稼働させる必要があるかな、と考えていたのですが、ALBのリダイレクト機能とGlobal Acceleratorの固定IPアドレスを利用することで実現が可能だということに気が付きました。AWSのフルマネージドなサービスのみで実現できるため、管理運用の手間もありません。ACM証明書も利用可能です。そもそもどう
WEBサービスで使用するサムネイル画像、JOBLISTでは事前に作っておくのではなく、動的に生成しています。 オリジナル画像がhttps://d2ui2iytvnht76.cloudfront.net/sample.jpgだとすると、 https://d2ui2iytvnht76.cloudfront.net/resize/100x100/sample.jpgで100px × 100pxに収まるように縮小した画像、 https://d2ui2iytvnht76.cloudfront.net/crop/100x100/sample.jpgで100px × 100pxにピッタリ収まるように縮小＆切り抜きをした画像、 が取得できます。 やろうと思えばもっと複雑なことも出来ますが、今のところこのぐらいで事足りてます。 導入のためにやったことは、既に構築済みだったCloudFrontとnginxに設
今業務で大容量のファイルを高速に配信する要件があり、CDNサービスを利用しているのですが、ちょっと高価なソリューションですよね＾＾。 そこで色々な方がレポートされていますが、「Amazon S3」+「Amazon CloudFront」を試してみましたので簡単にメモします。 「Amazon S3」+「Amazon CloudFront」の概要と設定方法 「Amazon Simple Storage Service（S3）」は、大容量のファイルや大量の画像をやりとりする時にスケール可能なインターネット上のストレージサービスで、「Amazon CloudFront」はS3上のファイルをキャッシュする事で高速にコンテンツ配信する事ができるサービスです。「S3」+「CloudFront」の組み合わせでCDNサービスを実現するというもののようです。下記イメージのようにクライアント（ブラウザ）はClo
CloudFront FunctionsをテストするOSS、cfftを公開しました - KAYAC engineers' blog
SREチームの藤原です。 今回は Amazon CloudFront Functions をテストするためのOSSとして、cfft というものを書いたので紹介します。 github.com 3行でまとめ CloudFront Functionsのテストは手元ではできなくて面倒です CloudFront Functionsをテストする cfft というOSSを書きました KeyValueStoreの操作を含め、便利な使い方がいろいろありますのでどうぞご利用下さい CloudFront Functionsをテストするのが面倒という問題 CloudFront Functions (以下CFF) は、AWSが提供するCDNであるAmazon CloudFrontのエッジノード上でリクエストやレスポンスの操作が行える、JavaScriptの実行環境です。典型的なユースケースとしては、キャッシュキーの
AWS Amplify ConsoleでNext.jsのプロジェクトをデプロイすると Serverless Next.js Component のインテグレーションによってAWS Lambda リソースが最大4つ作成される(ソースコードはエクスポートできる) Default Lambda@Edge for Next CloudFront distribution API Lambda@Edge for Next CloudFront distribution Image Lambda@Edge for Next CloudFront distribution Next.js Regeneration Lambda それぞれのAWS Lambdaが行っていることを読み解くとVercelが自社で構成しているシステムの外観が分かるのではないかと思って眺めてみた (CloudFrontのコンソール
特に問題となるのがS3の場合でした。EC2インスタンス上のWebアプリケーションであればOriginヘッダの有無に関係なくAccess-Control-Allow-Originヘッダを返すこともできますが、S3のCORS機能は仕様通りの実装であるためOriginヘッダが存在しない場合はAccess-Control-Allow-Originヘッダを返しません。具体的には、以下の様な挙動になります。まずはOriginヘッダをつけない（同一ドメイン）の場合です。curlコマンドでStatic Website Hostingを有効にしたS3バケットhoge.example.com.s3-website-ap-1.amazonaws.comに対してアクセスします。 $ curl -I hoge.example.com.s3-website-ap-1.amazonaws.com/hoge HTTP/1
[アップデート]AmplifyがNext.jsとNuxt.jsを利用したSSR（Server Side Rendering）に対応しました！ | DevelopersIO
AmplifyがNext.jsとNuxt.jsを利用したSSR（Server Side Rendering）をサポートしました！ Amplify JavaScript adds server-side rendering (SSR) support for frameworks like Next.js and Nuxt.js これまで、AmplifyはSPAで構築するのが基本でしたが、SSRな構成をとることもできるようになり、選択の幅が広がったと思います！ このSSR環境をさっそく構築してみました！ 構成図 AmplifyでNext.jsを利用してSSR環境を構築するとこんな感じの構成になります。 Serveless Frameworkを利用して、Lambda@EdgeでレンダリングするSSR可能なCloudFrontを構築することで、SSRを実現しています。 構築してみた Amplif
![[アップデート]AmplifyがNext.jsとNuxt.jsを利用したSSR（Server Side Rendering）に対応しました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/194a9cfb6a3c1c20634fa9a82024d910930e4552/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Faws-amplify.png)
AWSサーバレスアーキテクチャでSPAを実装する（1）～SSLを経由してブラウザからLambda APIへアクセスするまでの下準備
本連載では、AWSを利用したSPA（Single Page Application）の開発を通じて、サーバレスアーキテクチャの考え方を知っていただき、Webアプリケーションとして作成していく際にどのような構成を取ればよいのか、開発環境やテストなどはどのように行えばよいか、実際のコードを交えながら解説していきます。今回からは、JavaScriptのブラウザ向けフレームワークにAngularを使い、AWSのサーバレスアーキテクチャ向けに用意された各種機能を使いながら、簡単な掲示板を作ることをゴールにします。 本連載で作るSPAのゴール 開発する掲示板は以下のようなイメージです。 スレッド一覧画面 スレッドの一覧画面で、今回のアプリケーションのトップページとなります スレッドの一覧と他の画面へのリンクを持ちます サインインしていなくてもアクセスできます スレッド詳細画面 スレッドの詳細とそのスレ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【APIサーバ改修不要バージョン】AWSで動画の自動圧縮 & 配信を行う方法
CloudFrontのキャッシュ時間(TTL)はどの程度なのか | DevelopersIO
CloudFront+S3で署名付きURLでプライベートコンテンツを配信する | DevelopersIO
AWSの侵入テスト申請フォームが変更された件 - とある診断員の備忘録
AmazonのCloudFrontの障害規模はどれくらいだったのか？
SPAを S3+CloudFront で表示する方法 - Carpe Diem
Amazonのほしい物リストをRSS化するAPIを作ってみた - プログラマでありたい
ELBとCloudFrontのアクセスログをサーバレスに集約させてみた | DevelopersIO
WordPressサイトをCloudFrontで配信する - Qiita
Amazon S3 静的ウェブホスティングの継続的デリバリ | DevelopersIO
Amazonの従量課金制CDNサービス「Amazon CloudFront」を使う方法 - 元RX-7乗りの適当な日々
大規模トラフィックを捌くための CloudFront 以外の選択肢 – I'm Sei.
Route53のフェイルオーバールーティングを使用したSorryページの配信 - NRIネットコムBlog
固定IPアドレスでフルマネージドなリダイレクト環境をAWSで構成する | DevelopersIO
AWS、nginxでお手軽動的サムネイル - rista’s blog(旧)
Amazon S3 + CloudFrontを試す - CODE NAME: TUNE34
Serverless Next.js Component のISR実装を読み解く
[新機能] Amazon CloudFrontがCORSに対応しました | DevelopersIO