署名付きURLを使用したS3へのファイルのアップロードとダウンロード
はじめに お客様に、動画マニュアルの社内共有サービスを作れないかと相談されたので、会員向けの動画配信サービスの構築方法を検討することになりました。 前回の記事で、MediaConvertを使って、S3にアップロードされた画像をコンバートする処理の技術検討は終わったので、 次は、 限られたユーザー（ログイン済み）のみ動画をアップロードできる 限られたユーザー（ログイン済み）のみ動画を視聴できる 仕組みの検討を行います。 過去に、画像の共有サービスを構築した際は、AmplifyのStorage機能をAmplify SDKから使って、Cognitoで認証されたユーザーのみアップロード、ダウンロード（署名付きURLで）できる方法を構築したことがありますが、今回は認証にAuth0を利用してみたいと考えているため、 Auth0でログイン済みのユーザーのみ、動画をアップロードできる Auth0でログイン
CloudFront+S3 で署名付き URL を用いたコンテンツアクセスをしてみた 2023 | DevelopersIO
API アクセスが TLS1.2 未満は非対応となる対応として、S3 へアクセスする際に CloudFront を通して署名付き URL を用いる方法を紹介します。 はじめに 猫とアポロチョコと Systems Manager が好きな m.hayakawa です。 TLS 1.2 未満での AWS API エンドポイントへの接続が2023年6月28日以降、不可能になります。 TLS 1.2 がすべての AWS API エンドポイントへの接続に必要な最小バージョンになります | Amazon Web Services ブログ 今後 Transport Layer Security (TLS) の技術の進化と規制基準に対応するため、すべての AWS サービス API エンドポイントの TLS 構成において、最小バージョンを TLS 1.2 に更新する予定です。この更新は、2023 年 6 月
PresignedURLを使用してデバイスにファイルを配信する | DevelopersIO
AWS SDK for JavaScript v3を使用して、PUT用およびGET用のPresigned URLを発行する方法について書きました。 こんにちは。CX事業本部Delivery部サーバーサイドチームの木村です。 概要 システムの管理者等がデバイスへ向けて、設定ファイルやファームウェアなどを送りたい場合があると思います。 MQTTベースのファイル配信 API Gatewayなどを経由した方法 デバイスにAWSクレデンシャルを渡して、SDK経由でアクセス などさまざまな方法が考えられます。 今回はPresigned URLを使用した方法について書かせていただきます。 AWS SDK for JavaScript v3を使用します。 Presigned URLについて ドキュメントによると、 署名付き URL を使用して、オプションでオブジェクトを共有したり、顧客/ユーザーが AWS
Amazon DynamoDBテーブルをエクスポートしてAmazon Athenaでクエリしてみた | DevelopersIO
このようなテーブルがあったとき、「指定した期間の注文一覧を取得する」というユースケースを考えるとスキャンが必要になります。 やってみた それではSampleOrderTableテーブルのデータをAthenaでクエリまでやっていきましょう。 まずはエクスポート用のS3バケットを作成します。今回はsample-order-table-exportバケットを作成しました。 次に、作成したバケットにテーブルのエクスポートをしていきます。テーブルページのアクションから「S3へのエクスポート」を選択します。 「送信先S3バケット」に事前に作成したsample-order-table-exportバケットを指定。 「エクスポートされたファイル形式」にはAmazon Ionを選択します。指定したら「エクスポート」ボタンをクリックしましょう。 約6分ほどでエクスポートされました。dataフォルダーにgz形式
Amazon S3 ファイルゲートウェイが DOS 属性をサポート
Amazon S3 ファイルゲートウェイは、ファイルメタデータに記載されている DOS 属性のキャプチャ、保持、適用に対応しました。これまで、ゲートウェイにコピーされたファイルは、コピー時にこの共通メタデータ (Archive、Hidden、Read Only、System) を含んでいませんでした。DOS 属性への対応は、ファイルまたはフォルダを非表示にする、ファイルまたはフォルダレベルで読み取り専用アクセスを適用する、Amazon S3 に移動したファイルをアーカイブ済みとしてマークするといったことを実施するためのものです。 データをアーカイブする Amazon S3 ファイルゲートウェイユーザーは多くの場合、一貫性およびコンプライアンスの確保のために、データおよびそれに関連するメタデータをそのまま残しておく必要があります。また、他のゲートウェイユーザーは、ゲートウェイ上でファイルを表
Amazon S3バケットを同期する際の検討ポイントをまとめてみた | DevelopersIO
S3 Replication S3 Replication機能はS3 マネージドのライブ・レプリケーション機能です。 設定後に更新されたオブジェクトが同期対象であり、既存オブジェクトは同期対象外です。 レプリケート先は アカウント(同一・別) リージョン(同一・別) ストレージクラス(同一・別) など柔軟に設定可能です。 複雑な要件のために、複数の同期先や双方向の同期にも対応しています。 レプリカは作成日時を含む全てのメタデータが引き継がれます。 どういう状態のオブジェクトが同期されるのか、ドキュメントを熟読しましょう。 バージョニングやライフサイクルが絡むため、ややこしいです。 大部分のオブジェクトは15分以内にレプリケートされますが、数時間かかることもあります。 S3 Replication Time Control (S3 RTC)機能を併用すると、99.99%のオブジェクトを15分
Amazon S3 バケットに複数のライフサイクルルールを設定したときの挙動を確認してみた | DevelopersIO
いわさです。 Amazon S3 ではライフサイクルルールを構成することでオブジェクトのストレージクラスの移行や古いオブジェクトの削除などを自動化することが出来ます。 上記記事でも言及されていますが、このライフサイクルルールは複数設定することが可能です。 さらに、その複数のルールは単一ルールではエラーとなるような競合したルールを組み合わせることも出来たりします。 公式ドキュメントには重複・競合したルールは以下のように「最も安価なパスが選択される」とされています。 重複するプレフィックスまたはアクションを指定する S3 ライフサイクル設定を指定する場合があります。 一般的に、S3 ライフサイクルはコストに合わせて最適化されます。たとえば、2 つの有効期限ポリシーが重複している場合は、短い有効期限ポリシーが適用されるため、データが予想よりも長く保存されることはありません。同様に、2 つの移行ポ
S3へのアクセスをEC2のプライベートIPアドレスで制御してみた | DevelopersIO
S3バケットポリシーを使用してEC2の持つグローバルIPで制御したことはあったのですが、VPC内のプライベートIPの場合はどうすればよいのだろうと思ったのでやってみました。 今回はGateway型のVPCエンドポイントをS3へアクセスするEC2のプライベートIPアドレスで、S3のアクセスを制限する検証を行いました。 グローバルIPアドレスで制御する場合 グローバルIPアドレスで制御する場合は以下のようにaws:SourceIpを使用して制御できます。 以下のバケットポリシーは特定のグローバルIPアドレス以外からのPutObject、GetObject、ListBucketを禁止するものになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": [ "s3:P
AWS BackupでS3のバックアップを取る方法とそのメリット | DevelopersIO
どうも、CX事業本部Delivery部の嶋村です。 こちらは、「Build a disaster recovery solution with AWS storage services」のセッションで紹介されていたAWS BackupでS3のバックアップを取る方法です。あと、そのメリットについて解説します。 S3のバージョニング機能があるのになぜ必要なのか？ S3のバックアップと聞いて、バージョニング機能と何が違うんだとなった人がいると思います。 AWS Backupを使う理由は、2つあります。 1. バケット自体を消してしまった時 AWS Backupを使うと、バケット自体を消してしまった時でも戻すことができます。 この記事で実際にバケット自体を消して復元できるのかを検証しています。 2. ある地点に戻したい時 バージョニング機能はオブジェクトのバージョニングをしているので、オブジェクト
GuardDutyログをS3クロスアカウントレプリケーションしてみた | DevelopersIO
こんにちは。ネクストモードの倉地です。 業務アプリケーションなどの用途で使用するシステムアカウントのGuardDutyログを、ログ集約アカウントのS3バケットへクロスアカウントレプリケーション設定を実施したのですが、権限周りの理解が難しく実装に苦労しました。今回はこちらを整理しながら技術検証しましたので、内容を共有できればと思います。 やりたいこと GuardDutyからS3バケットへログを出力する (KMS暗号化が必要) システムアカウント側S3バケットからログ集約アカウント側S3バケットへクロスアカウントレプリケーションをする ログ集約アカウント側S3バケットに保存されたGuardDutyログが確認できれば成功 システムアカウント側 GuardDutyのログ出力設定 S3バケット作成 まずシステムアカウント側でGuardDutyログの出力先バケットを作成します。検証のため設定は基本的に
S3 Access Points をソースにデータ転送をやってみた | DevelopersIO
こんにちは、森田です。 Amazon S3 のアクセスポイントをソースにデータ転送をやりたかったのですが、DataSyncを試してみたところ上手くいきませんでした。 いきなり結論 現在（2022/09/30）時点では、AWS DataSyncのソースに S3 のアクセスポイントを指定することはできません。 DataSync APIを確認したところ、以下のように S3 のアクセスポイントのフォーマットにはマッチしないようになっていました。 https://docs.aws.amazon.com/datasync/latest/userguide/API_CreateLocationS3.html なので、S3 アクセスポイントを利用する場合は、別の方法で実現する必要があります。 AWS DataSync を利用しない方法 AWS CodeBuild 上で AWS CLI S3 Sync を利
CloudFrontのアクセスログ保存用S3バケットにはACL有効化が必要なので注意しよう | DevelopersIO
はじめに 清水です。先日、Amazon S3のACL無効化が推奨されたことで、S3のサーバアクセスログ記録保存用のS3バケットの権限設定においてもACLではなくバケットポリシーを使用するようになっていた、というブログを書きました。 ACL無効化が推奨されたことでS3のサーバアクセスログ記録のためのアクセス許可はどうなったのか!?確認してみた | DevelopersIO re:Invent 2021期間中に発表されたS3のACL無効化機能に伴う変更です。（【アップデート】S3でACLを無効化できるようになりました #reinvent | DevelopersIO）上記エントリではS3のサーバアクセスログ記録保存用となるS3バケットについて確認しましたが、CloudFrontのアクセスログ記録用となるS3バケットについて、ACL無効化の影響（ACLを無効にしたS3バケットをCloudFron
Basic認証付きのCloudFront + S3環境をCloudFormationで構築する
PoCや個人開発において以下のような構成を取りたいケースが多かったので、CloudFormationでサッと作れるようにしたので備忘メモ✍ デプロイすると、 https://xxxxx.cloudfront.net/ のドメインでBasic認証付きのWebページができあがります また、今回は未着手ですが、バックエンドがほしければServerless Frameworkを追加するなど、色々応用もできるものと思います！ （Terraformの例でアレですがこのような方法で可能です） 方法 サンプルとして、今回はこのようなディレクトリ構成を仮定します👪 infra.yml がスタック定義、 dist/ 配下に配信したいWebアプリケーション一式、 bin/deploy がデプロイ用スクリプトのイメージです スクリプト内で環境変数を用いるので、必要に応じて direnv などで注入できるようにし
Amazon S3 オリジンへのアクセスの制限 - Amazon CloudFront
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Amazon S3 オリジンへのアクセスの制限 CloudFront では、認証されたリクエストを Amazon S3 オリジンに送信する 2 つの方法として、オリジンアクセスコントロール (OAC) とオリジンアクセスアイデンティティ (OAI) があります。OAC は以下をサポートしているため、OAC の使用をお勧めします。 すべての AWS リージョンのすべての Amazon S3 バケット (2022 年 12 月以降に開始されたオプトインリージョンを含む) AWS KMS による Amazon S3 サーバー側の暗号化 (SSE-KMS) Amazon S3 に対する動的なリクエスト (PUT と DELETE) オリジンアクセスアイデンティティ (OAI
S3のコストを大幅に削減した話 - Gunosy Tech Blog
広告技術部のUTです。 最近はカービィディスカバリーをゆっくりやってます 概要 過去の失敗 どうやったか 仕組み 結果 まとめ 概要 昨今ではデータドリブンな意思決定を重視する企業がどんどん増えており、データを活用することにより事業成長へのインパクトを出そうとしています。 データを事業へと活用するためには、蓄積されるデータを分析するために保管しておく必要があります。 弊社も創業時からデータを蓄積し事業に活用することに力を入れてきた企業の一つであり、日々大量のログが収集されています。 またAWSアカウントを複数運用していますが、一番データ量の多い広告アカウントのS3にはペタバイトレベルのデータが保管されています。 普段何気なく使っているデータレイクとしてのS3ですが、少量であれば無視できるくらい小さいので、コストを気にせず使っておられる方も多いのではないでしょうか？ そのようなS3でも巨大な
EC2のユーザーデータでS3に配置したシェルスクリプトを実行してみた | DevelopersIO
はじめに EC2のユーザーデータを使って起動時に色々とインストールするのはよくあることだと思います。 今回はそのユーザーデータを任意に変更できるよう、S3に配置したシェルスクリプトをユーザーデータに読み込んで実行できるかを試してみました。 シェルスクリプトの準備 ユーザーデータとして読み込ませるシェルを準備し、S3に配置します。今回は以下のような「jq」をインストールするシェルスクリプトを準備しました。 ec2-template.sh #!/bin/bash sudo yum update -y sudo yum -y install jq 上記のシェルスクリプトを、今回は「dev-honda-ec2-test」バケットに保存しました。 CloudFormationテンプレート EC2を起動するためのCloudFormationテンプレートを準備します。以下のようになりました。 AWSTe
S3バケットポリシーにIPアドレス制限を加えると AWS Backup の S3 バケットのバックアップに失敗する事象の対処法 | DevelopersIO
困っていた内容 awsbackup-test-001 のバケットを AWS Backup でバックアップを取っています。 セキュリティ対策として、S3バケットポリシーに下記の通り、IP アドレス制限を加えました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "SourceIPRestriction001", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::awsbackup-test-001", "arn:aws:s3:::awsbackup-test-001/*" ], "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.
S3 過去のオブジェクトバージョンをコピーしてロールバックしました - ヤマムギ
バージョニングを有効にしているS3バケットで、オブジェクトを以前のバージョンに戻すときに、最新バージョンを削除する方法があります。 この場合、DeleteObjectVersionの権限が必要です。 バージョニングを有効にしているバケットでバージョンを指定した削除を簡単に実行できるのは操作ミスなども考慮すると避けたいです。 ということで過去のオブジェクトバージョンからコピーを作成して最新バージョンにする手順を確認しておきました。
Cloud One File Storage Securityを使ってS3にアップされたマルウェア、異常ファイルをチェックしてみた (処理編) | DevelopersIO
こんにちは、コンサル部＠大阪オフィスのTodaです。 Trend Micro社が提供するCloud Oneには7点のサービスが存在します。 今回はクラウドストレージのファイルチェックが出来るFile Storage Securityを操作してみました。 前回、File Storage Security(以降C1FSS)の導入をおこない実際のオブジェクトスキャンを実行してみました。 C1FSSはスキャンを完了した際に、バケットのタグにスキャン結果が記録される仕組みになるため異常ファイルのパブリック公開の停止やバケットの移動は別で準備する必要があります。 今回は2点を検証してみます。 事前の準備 チェックで利用するS3は事前にパブリックアクセスを許可しています。 異常ファイルのパブリック公開停止 オブジェクトスキャンにて異常ファイルの判定を受けた場合、オブジェクトタグ:fss-scan-res
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Restricting access to an Amazon Simple Storage Service origin - Amazon CloudFront