[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ | DevelopersIO
[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ CloudFrontからS3へのアクセス制限として従来のOAIに加えて、新たにOACが利用可能になりました。セキュリティが強化されSSE-KMSなどのサポートが行われています。OAIも引き続き利用可能ですが、今後はOACを使用しましょう。 はじめに 清水です。今朝（日本時間2022/08/26、現地時間2022/08/25）のアップデートでAWSのCDNサービスであるAmazon CloudFrontにOrigin Access Control (OAC)という機能が追加されました。CloudFrontからオブジェクトストレージサービスAmazon S3へのアクセス制限を行う新たな方法となります。これまでもOrigin Access Identi
![[NEW] CloudFrontからS3への新たなアクセス制御方法としてOrigin Access Control (OAC)が発表されました！ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/17d6fdb640a27970efada177996eba4546025db8/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2022%2F08%2Famazon-cloudfront.png)
L@EとCF2が不要に？！CloudFront単体でレスポンスヘッダーが設定できるようになりました | DevelopersIO
CX事業本部@大阪の岩田です。CloudFrontに待望のアップデートがあり、CloudFront単体でもレスポンスヘッダーが設定できるようになりました！ これまではCloudFront単体でレスポンスヘッダーを設定することができませんでした。S3 & CloudFrontの構成でSPAを配信するのは非常に一般的な構成ですが、この構成でそのまま脆弱性診断を受けると、セキュリティ関連のヘッダが設定されていないと指摘されるのも「あるある」でした。Lambda@Edge(L@E)やCloudFront Function(CF2)を介入させればオリジンレスポンスやビュワーレスポンスが加工できるので、これまではL@EやCF2でレスポンスヘッダを追加付与するという対応がよく採用されていました。 が、静的なレスポンスヘッダ付与のためにいちいちコードの実行が必要になるというのは、どうも無駄が多いように感じ
CloudFront FunctionsはLambda@Edgeより安い。それ本当？！ | DevelopersIO
CX事業本部@大阪の岩田です。先月GAされたCloudFront Functions(以後CF2とします)ですが、従来から利用できたLambda@Edge(以後L@Eとします)と比較して、高速かつ低コストというのがウリの1つになっています。最大実行時間や最大メモリといった制約はありますが、レスポンスヘッダを固定付与するようなライトな処理はCF2のユースケースとしてAWSの公式ドキュメントでも紹介されています。 Customizing at the edge with CloudFront Functions では今後はレスポンスヘッダの固定付与のような処理は全てCF2で実装すべきなのでしょうか？基本的にはCF2で良いと思いますが、使い方次第ではCF2よりもL@Eの方が低コストになることも考えられるので、なぜこのようなケースが起こり得るのかをご紹介します。 CF2とL@Eの料金体系比較 まず
AWS、エッジにおけるJavaScript実行環境に本格参入。Cloudflare WorkersやDeno Deployなどと競合へ
AWS、エッジにおけるJavaScript実行環境に本格参入。Cloudflare WorkersやDeno Deployなどと競合へ Amazon Web Services（AWS）は、エッジ環境で軽量なJavaScriptによる処理を実行可能な新サービス「Amazon CloudFront Functions」を発表しました。 AWSではすでにエッジで処理を行う「Lambda@Edge」を提供しており、そこでNode.jsとPythonによるコードを実行可能です。 しかしLambda@Edgeは13カ所のリージョナルエッジキャッシュにおいて処理が行われるのに対し、CloudFront Functionsは218カ所以上のCloudFront Edge Locationsにおいて処理が行われるため、よりユーザーに近い広範囲なロケーションで実行されます。 また、実行時間もLambda@Ed
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました | DevelopersIO
[アップデート] Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました キャッシュ設定をポリシー化することでBehaviorごとの設定が非常に楽になりました！また、キャッシュキーとオリジンリクエストの設定が分離されたことで、キャッシュ効率に影響を与えることなくオリジンに追加情報を渡せるようになりました。 4 連休ということもありアップデート記事が遅くなってしまいました。 先日のアップデートで、Amazon CloudFront でキャッシュキーとオリジンリクエストポリシーによる管理が可能となりました。 Amazon CloudFront announces Cache Key and Origin Request Policies 何がうれしいのか キャッシュおよびオリジンリクエスト設定の外だし これまで Behavior の設定ごと
Building a Real-Time Image Optimizer Using Lambda@Edge and Amazon CloudFront | vividbytes.io
In this tutorial, we'll build a real-time image optimizer using Lambda@Edge and CloudFront. What is a real-time image optimizer?A real-time image optimizer is a service that resizes the requested image according to specific query parameters. It then caches the image so that if the same image with the same parameters is requested again, it will be served from the cache. For example, here's a link t
Amazon CloudFront & Lambda@Edge で画像をリサイズする | Amazon Web Services
Amazon Web Services ブログ Amazon CloudFront & Lambda@Edge で画像をリサイズする 多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか？ 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか？ Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。 Lambda@Edge の準備: AWS Lambda はサーバーのプロビジョニングや管理の必要なしにコードを実行できます。 そして利用量に応じて支払いを行います 。 つまりコードが実行されていないときは無料です！ Lambda は自動スケーリングするとともに耐障害性を兼ね備えていま
CloudFrontを使用してS3静的ウェブサイトを提供する手順 | DevelopersIO
S3静的ウェブサイトを、CloudFrontを通じて提供したいと思います。今回はいくつかの前提の元、実施してみました。 DNS管理者、AWS管理者、コンテンツ管理者がそれぞれ別の部などでわかれ、AWSにて提供するウェブサイトは随時増えていく想定です。 こんにちは、坂巻です。 S3静的ウェブサイトを、CloudFrontを通じて提供したいと思います。今回はいくつかの前提の元、実施してみました。 前提／構成 DNS管理者、AWS管理者、コンテンツ管理者がそれぞれ別の部等にわかれ、AWSにて提供するウェブサイトは随時増えていく想定です。イメージは以下となります。 DNS管理者 AWS外のネームサーバでDNSレコード設定等を行います。ドメイン、SSL証明書をAWS外で調達します。調達した証明書はAWS管理者に連携します。 AWS管理者 CloudFront、S3バケットなど、AWSの構築、管理を行
CloudFront + S3 + Lambda@EdgeでBasic認証付きお手軽 静的サイト ( ランディングページ ) 環境を作った | Recruit Tech Blog
こんにちは。開発支援Gでインフラ運用をしている大島です。 Lambda@Edgeとは、CloudFrontが配信するコンテンツをカスタマイズする関数を実行できる機能のことです。本記事では、これを使ってランディングページ ( 以下LP ) のような静的サイトに対してお手軽にBasic認証を設置する話です。 また、最後におまけ程度ですが、この構成に到るまでの背景も書いていますのでもしよろしければご覧になっていってください。 LP環境をCloudFrontで作るのにBasic認証はどうしよう ? 開発中はデバッグ用の要素や社内開発環境へのリンクなども含まれていたりすることを考えると、何かしらの方法でアクセスを制限する必要があります。nginxなどのwebサーバであればBasic認証の設置も簡単ですが、今回はCloudFront + S3なのでそうそう気軽には設置できません。 そんなときに便利なの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
