019-AWS SAP AWS 「理論・実践・一問道場」動画アプローチ to S3

type

status

date

slug

summary

理論

AWS Transfer Family は、ファイル転送プロトコル (FTP, SFTP, FTPS) を使用してデータを AWS に転送するためのマネージドサービスです。このサービスは、安全でスケーラブルな方法でデータをクラウドに取り込み、ストレージや分析ワークフローで利用できるようにします。

特徴

プロトコル対応:

SFTP (Secure File Transfer Protocol): 暗号化された安全なファイル転送を提供。

FTP (File Transfer Protocol): 基本的なファイル転送。

FTPS (File Transfer Protocol over SSL): セキュリティのために SSL/TLS を使用。

バックエンドストレージ:

Amazon S3 や Amazon EFS と連携して、ファイルを保存および管理します。

セキュリティ:

IAM ロールを使用した認証や、既存の ID プロバイダー (AD, LDAP, IAM Identity Center など) と統合可能。

データ転送中および保存中の暗号化をサポート。

スケーラビリティ:

マネージドサービスのため、インフラ管理が不要で、負荷に応じて自動でスケーリングします。

簡単な移行:

既存のオンプレミスまたはレガシーなファイル転送ワークフローを最小限の変更でクラウドに移行可能。

ユースケース

データ取り込み:

パートナーや顧客から定期的に送られるデータを AWS に安全に取り込み、S3 や分析ツールで処理。

レガシーシステムのクラウド移行:

オンプレミスのファイル転送システムをクラウドベースに置き換える。

安全なファイル共有:

外部ユーザーや部門間でのセキュアなデータ共有を実現。

ビッグデータと分析:

定期的に送信される大規模なデータセットを AWS で保存し、Athena や Redshift などで分析。

仕組み

エンドポイントの作成:

AWS Transfer Family コンソールで、使用するプロトコル (例: SFTP) のエンドポイントを作成。

ユーザー管理:

IAM または既存の ID 管理システムで、ユーザーごとのアクセス制御を設定。

データ転送:

クライアントソフトウェア (例: WinSCP, FileZilla) を使ってエンドポイントに接続し、ファイルを転送。

バックエンド処理:

ファイルは S3 または EFS に保存され、その後、他の AWS サービスと連携して処理。

利点

コスト効率: インフラの管理やメンテナンス不要。

互換性: 既存のファイル転送クライアントやスクリプトをそのまま利用可能。

セキュリティ: AWS のセキュリティサービスとの統合。

AWS Transfer Family は、従来のファイル転送をクラウドに統合したい場合に非常に有用です。

AWS Transfer Family が IAM Identity Center (AWS SSO) と統合される場合、IAM Identity Center のインスタンスの「組織インスタンス」または「アカウントインスタンス」を作成する選択肢には、それぞれ異なるユースケースと運用上の意味があります。以下に違いを説明します：

1. 組織インスタンス (Organization Instance)

概要: AWS Organizations を使用している場合、このインスタンスを選択します。

特徴:

マルチアカウント対応: 複数の AWS アカウント間で IAM Identity Center を共有し、一元的にユーザーやグループ、アクセスを管理できます。
中央管理: 管理者は、Organizations に参加している複数の AWS アカウントに対して一括でユーザーやグループの権限を割り当てられる。
最適なユースケース: 企業規模での利用を想定しており、複数の AWS アカウントやリソースを運用する組織に向いている。

2. アカウントインスタンス (Account Instance)

概要: 個別の AWS アカウント内で IAM Identity Center を使用する場合に選択します。

特徴:

シングルアカウント対応: 単一の AWS アカウント内でのみユーザーやグループを管理します。
限定的なスコープ: 他のアカウントにまたがったアクセス管理や権限設定はできません。
最適なユースケース: 小規模なプロジェクトや、単一アカウントで完結するシンプルな構成。

選択のポイント

AWS Organizations を使っているかどうか:

使っている → 組織インスタンス。
使っていない → アカウントインスタンス。

管理する範囲:

マルチアカウントや中央管理が必要 → 組織インスタンス。
単一アカウント内で十分 → アカウントインスタンス。

複雑さ:

組織インスタンスは設定や運用が複雑になることがあるが、スケーラビリティが高い。
アカウントインスタンスは簡単に構築・管理できるが、柔軟性は低い。

例:

企業全体のファイル転送システムを構築し、複数アカウントにまたがるユーザーとグループを管理したい場合 → 組織インスタンス。

小規模なチームやプロジェクト単位で AWS Transfer Family を使いたい場合 → アカウントインスタンス。

必要な要件に基づいて適切なインスタンスを選択することをお勧めします！

Access Grants

Access Grants は Amazon S3 のアクセス管理を簡単にする機能です。IAM Identity Center と統合し、以下が実現できます。

特徴

シンプルなアクセス管理:

ノーコードでユーザーやグループにアクセス権を割り当て可能。

IAM Identity Center 連携:

シングルサインオン (SSO) で認証し、アクセスを管理。

自動ポリシー生成:

S3 バケットやオブジェクトへの権限を自動的に設定。

メリット

運用が簡単: ポリシーの手動設定が不要。

セキュリティ強化: ユーザー認証とアクセス管理を一元化。

効率的な管理: ユーザー・グループ単位で柔軟にアクセス設定。

まとめ:

Access Grants は S3 のアクセス管理を効率化 し、IAM Identity Center と連携して安全かつ簡単にユーザーアクセスを制御できる機能です。

[AWS Transfer Family web apps] S3にアクセスできるWebアプリケーションをさくっと作ってみた | DevelopersIO

Announcing AWS Transfer Family web apps for fully managed Amazon S3 file transfersを見て S3のファイルを操作できるWebアプリケーションがコード不要で作成できるとあったので、構築してみました。

https://dev.classmethod.jp/articles/try-transfer-family-web-apps/

SQS キューのメッセージを Lambda で処理してみる - AWSの部屋

はじめに前回のエントリーで S3 と SQS の連携を試してみました。本エントリーはその続きで SQS キューに S3 から通知がきた後に SQS キューのメッセージを Lambda で処理してみようと思います。使用するサービス Amazon S3・・・AWS が提供するオブジェクトストレージサービス Amazon…

https://www.aws-room.com/entry/s3-sqs-lambda

【AWS】S3+Lambda+Rekognitionで画像認識してみた - Qiita

はじめにAWSの「Amazon Rekognition」を使って画像認識を試してみました。以下の人物画像から顔を検出し、性別と微笑みの有無を判別しています。なお、用いた画像は写真のフリー素材サ…

https://qiita.com/falya128/items/8954c4ba524b2bbaf874

今回実施する構成図

1.AWS Transfer Family で S3 バケットへのファイル転送設定を作成する。

はじめに

Announcing AWS Transfer Family web apps for fully managed Amazon S3 file transfersを見て

S3のファイルを操作できるWebアプリケーションがコード不要で作成できるとあったので、構築してみました。

準備

IAM Identity Center が有効になっていること

WebアプリケーションからアクセスしたいS3バケットが作成済みであること

構築手順(ざっくり)

AWS Transfer Familyからウェブアプリを作成

ウェブアプリにIdentity Centerのユーザー or グループを割り当てる

S3 Access Grantsを作成

S3 バケットを選択
アクセスしたいパス/プレフィクスを設定
Permissionsを設定（Read/Write）
プリンシパルタイプ(ユーザー or グループ)を設定

S3にCORSポリシーを設定

完了

手順としては4ステップでWebアプリケーションが作成できます。

最後におまけとしてユーザー毎にアクセスを制限する方法を紹介します。

それでは解説していきます

AWS Transfer Familyからウェブアプリを作成

AWS Transfer Familyのウェブアプリを選択します（最近発表されたため、新規と出ています）

必要な同時接続数を設定して次へを選択(2024年12月時点で1000が上限でした)

titleやロゴを設定していきます

ウェブアプリを作成を選択

アプリケーションが作成できました。次にIdentity Centerの情報を設定していきます

ウェブアプリにIdentity Centerのユーザー or グループを割り当てる

ウェブアプリIDを選択

を選択

今回は

を選択します（既にIdentity Centerにユーザーやグループが作成されている状態）

設定したいユーザーを選択→

を選択

S3 Access Grantsを作成

次にS3のAccess Grantsを作成していきます

S3のサービスページからAccess Grants→権限を作成を選択

Identity Centerが設定されていない場合は追加し、

を選択

権限作成でのポイントは

サブプレフィックス

許可の範囲を設定します。バケット全体でOKであれば

許可

Read/Writeの設定

被付与者タイプ

今回はIdentity Centerの情報から設定します

ディレクトリアイデンティティタイプ

Identity Centerのユーザーもしくはグループの単位で許可を設定できます

ここではユーザーを設定しました

CORSの設定

最後にアプリケーションからS3にアクセスするためCORSを設定します

CORS設定内容

AWS Transfer Family > ウェブアプリから確認できるウェブアプリエンドポイントを設定します

テスト用として大雑把に設定しています

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST",
            "DELETE",
            "HEAD"
        ],
        "AllowedOrigins": [
            "https://{ウェブアプリエンドポイント}",
            "https://*.{ウェブアプリエンドポイント}"
        ],
        "ExposeHeaders": [
            "Access-Control-Allow-Origin"
        ]
    }
]

ウェブアプリのアクセスエンドポイントに接続→サインインするとアクセスが許可されたパスが表示されています

パスを選択して適当な画像をアップロードします

アップロードできました

今回の権限ではダウンロードはもちろん、フォルダの作成、コピー、削除も可能です

おまけ(アクセスできるパスをユーザー毎に制限してみる)

ファイルのアクセスが確認できたため、ユーザー毎にアクセスできるパスを制限してみます

例えば、部署Aの人は部署Bのパスにアクセスできない...といったシーンに活用できます

一例としてIdentity Centerのグループを利用し、グループを部署として扱います

事前準備、確認

Identity Centerで新しいユーザーを作成し、

新しいユーザー(masaya toyoshima 2)を作成、サインインしましたがAccess Grantsが作成されていないため、何も表示されません

Identity Centerからグループを作成していきます

group-a(元のユーザー toyoshima masayaを設定)

group-b(新しいユーザー masaya toyoshima 2を設定)を作成、及び設定します(group-bのユーザーについては構築手順1, 2を参照)同様の手順でgroup bも作成しておきます

Access Grantsの作成からサブプレフィックスを指定します

今回はgroup-a用としたいのでgroup-a/*を設定

許可を設定したい権限をチェックして

被付与者タイプをアイデンティティセンターからのディレクトリID

ディレクトリアイデンティティタイプをグループにします

同様の設定でgroup-aをgroup-bに置換して作成します

group-aのユーザーでログイン後、該当のディレクトリが表示されています(group-bはアクセス権限がないため表示されていない)

group-bのユーザーではgroup-bが表示されています(group-aはアクセス権限がないため表示されていない)

S3にファイルを格納した際にSQSキューに通知し、Lambdaでそのメッセージを処理する

S3 へのファイル格納時に SQS キューに通知をしてみる S3 SQS

はじめに

AWS認定試験に必ず出題される SQS ですが、今まで触ったことがなかったので本日は S3 と連携させて SQS を試してみたいと思います。

使用するサービス

Amazon S3・・・AWS が提供するオブジェクトストレージサービス

Amazon SQS・・・フルマネージド型のメッセージキューイングサービス

アーキテクチャ

手順

S3 でバケットを作成

SQS キューを作成

S3 でイベント通知を作成

動作確認

1. S3 でバケットを作成

「20220807-sqs-test」というバケットを作成します。設定はデフォルトでOKです。

2. SQS キューを作成

「TestQueue」という SQS キューを作成します。

アクセスポリシーを以下のように設定します。

3. S3 でイベント通知を作成

イベント名とイベントタイプを設定し、作成した SQS キューを設定して「変更の保存」をクリックします。

4. 動作確認

バケットにファイルをアップロードします。

「メッセージを送受信」をクリックします。

「メッセージをポーリング」をクリックします。

メッセージが2件表示されます。

上のキューのメッセージ

アップロードしたファイルの情報などが記載されています。

下のキューのメッセージ

こちらは S3 からの通知など概要レベルの情報が記載されています。

さいごに

はじめて SQS を使用してみましたが設定は簡単にできました。何となく理解していたものが実際にサービスを使用することで理解が深まった気がします。次は SQS と Lambda の連携を試してみようと思います。

SQS キューのメッセージを Lambda で処理してみる Lambda S3 SQS

はじめに

前回のエントリーで S3 と SQS の連携を試してみました。本エントリーはその続きで SQS キューに S3 から通知がきた後に SQS キューのメッセージを Lambda で処理してみようと思います。

使用するサービス

Amazon S3・・・AWS が提供するオブジェクトストレージサービス

Amazon SQS・・・フルマネージド型のメッセージキューイングサービス

AWS Lambda・・・サーバーをプロビジョニングしたり管理しなくてもコードを実行できるコンピューティングサービス

アーキテクチャ

役割

Amazon S3・・・アップロードするファイルを格納

Amazon SQS・・・ S3 にアップロードされたファイルの情報を Lambda に送信

AWS Lambda・・・SQS から送信されたファイル情報をもとにファイルの名前を変えて S3 に同じファイルをアップロード

手順

IAMロールを作成

S3 バケットを作成

SQS キューを作成

Lambda 関数を作成

動作確認

1. IAMロールを作成

「Lambda-SQS-Execution-Role」という名前のLambda に SQS と S3 に対する実行権限を付与するロールを作成します。

2. S3 バケットを作成

前回のエントリーを参照してください。

3. SQS キューを作成

前回のエントリーを参照してください。

4. Lambda 関数を作成

SQS キューのメッセージを処理するLambda関数を作成します。

[関数名]：sqs-message-receive

[ランタイム]：Python 3.9

[実行ロール]：Lambda-SQS-Execution-Role

SQS キューをトリガーとして追加します。

ソースコード

S3 バケットにアップロードしたファイルの名前を変えて同じバケットにアップロードするプログラムです。

5. 動作確認

hane.jpg をアップロードします。

Lambdaによってhane2.jpg がバケットに作成されました。

さいごに

今回は簡単な処理だけだったので SQS を使う必要はないと思いますが、SQS と Lambda を実際にどのように連携するかを理解するためのいい勉強になりました。今度はデッドレターキューなど SQS をフルに活用できる構成を試してみたいですね。

lambdaをAmazonRekognitionに提携する

下記のコードをもっとのLambda関数に書き換えてくださいそして、Lambda関数にAmazonRekognitionReadOnlyAccessの権限を追加して、テストしましょう

一問道場

ある企業には、ユーザーが短い動画をアップロードできるウェブアプリケーションがあります。

動画は Amazon EBS ボリューム に保存され、カスタム認識ソフトウェアで分析されてカテゴリ分けされています。

現状のアーキテクチャ：

ウェブサイトには静的コンテンツがあり、特定の月にトラフィックが急増します。

ウェブアプリケーション のために Amazon EC2 インスタンス が Auto Scaling グループ で実行されています。

動画の処理は Amazon SQS キュー を使用し、EC2 インスタンス がそのキューを処理します。

企業の目標：

運用負荷を削減し、AWS の マネージドサービス を利用し、サードパーティ製ソフトウェア への依存を排除する。

既存のシステムを 再アーキテクチャ して、効率的で管理しやすいものに変更したい。

要件を満たすソリューションはどれか？

選択肢：

A. Amazon ECS コンテナをウェブアプリケーションに使用し、Auto Scaling グループで SQS キューを処理するためにスポットインスタンスを使用します。カスタムソフトウェアを Amazon Rekognition に置き換えて、動画をカテゴリ分けします。

B. アップロードされた動画を Amazon EFS に保存し、ウェブアプリケーションの EC2 インスタンスにファイルシステムをマウントします。SQS キューを AWS Lambda 関数で処理し、Amazon Rekognition API を呼び出して動画をカテゴリ分けします。

C. 静的のウェブアプリケーションを Amazon S3 にホストし、アップロードされた動画も Amazon S3 に保存します。S3 イベント通知 を使用して SQS キューにイベントを公開します。SQS キューを AWS Lambda 関数で処理し、Amazon Rekognition API を呼び出して動画をカテゴリ分けします。

D. AWS Elastic Beanstalk を使用して、ウェブアプリケーションのために Auto Scaling グループで EC2 インスタンスを起動し、SQS キューを処理するためにワーカー環境を起動します。カスタムソフトウェアを Amazon Rekognition に置き換えて、動画をカテゴリ分けします。

要点整理：

企業は運用負荷を減らし、AWS のマネージドサービスを活用したい。

動画を分類するためのカスタムソフトウェアを Amazon Rekognition に置き換えたい。

動画やデータのストレージや処理を Amazon S3 や AWS Lambda のようなマネージドサービスに移行することが求められている。

解説

この問題では、企業が運営している動画アップロードウェブアプリケーションを再アーキテクチャして、運用負荷を減らし、AWSのマネージドサービスを利用するという目的に適したソリューションを選ぶ必要があります。具体的には、動画の保存、処理、ウェブアプリケーションのホスティングを効率的に行いたいという要件があります。

以下、選択肢ごとの解説を行います。

A. Amazon ECSコンテナをウェブアプリケーションに使用し、Auto ScalingグループでSQSキューを処理するためにスポットインスタンスを使用します。カスタムソフトウェアをAmazon Rekognitionに置き換えて、動画をカテゴリ分けします。

ECSコンテナを使用する点では、運用負荷を軽減し、スケーラビリティを向上させることができます。しかし、ここで問題となるのは、動画の保存方法です。問題文には動画がEBSに保存されているとありますが、この選択肢では動画保存場所が明示されていません。

また、スポットインスタンスを使用するのは、コスト削減には効果的ですが、スポットインスタンスは時折停止される可能性があり、重要な処理に適さないことがあります。

結論として、動画の保存方法と安定性に関して不明点があり、最適ではないと言えます。

B. アップロードされた動画をAmazon EFSに保存し、ウェブアプリケーションのEC2インスタンスにファイルシステムをマウントします。SQSキューをAWS Lambda関数で処理し、Amazon Rekognition APIを呼び出して動画をカテゴリ分けします。

Amazon EFS（Elastic File System） は、複数のEC2インスタンスから同時にアクセスできるファイルシステムです。この選択肢では、EC2インスタンスでウェブアプリケーションをホストし、EFS を用いて複数インスタンス間で動画を共有する方法です。EFSは可用性が高く、ファイルの共有が可能ですが、運用の効率化という点では、EFSの管理はやや手間がかかる場合もあります。

また、Lambda を使って動画処理を行うという点は、マネージドサービスを活用した効率的な解決策ですが、動画の保存方法としてはS3の方がよりスケーラブルで低コストです。

結論として、EFSは利用可能ではありますが、S3の方がよりAWSのマネージドサービスに適しており、運用の手間を減らす意味でも効果的です。

C. ウェブアプリケーションをAmazon S3にホストし、アップロードされた動画もAmazon S3に保存します。S3イベント通知を使用してSQSキューにイベントを公開します。SQSキューをAWS Lambda関数で処理し、Amazon Rekognition APIを呼び出して動画をカテゴリ分けします。

Amazon S3 は動画の保存に最適なAWSのオブジェクトストレージサービスです。高いスケーラビリティ、低コスト、容易な管理を提供します。動画をアップロードする際にS3イベント通知を利用して、動画がアップロードされると自動的にSQSキューにイベントを送信できます。

AWS Lambda を使って動画処理を行うことで、サーバー管理の負担を減らすことができます。Amazon Rekognition を呼び出して動画を自動的にカテゴリ分けする点も効率的です。

Amazon S3 に動画を保存し、Lambda で処理を行うことで、運用の手間を最小限に抑えることができます。

結論として、この選択肢はAWSのマネージドサービスを最大限活用でき、運用負荷を削減し、コスト効率が高いため、最も適切です。

D. AWS Elastic Beanstalkを使用して、ウェブアプリケーションのためにAuto ScalingグループでEC2インスタンスを起動し、SQSキューを処理するためにワーカー環境を起動します。カスタムソフトウェアをAmazon Rekognitionに置き換えて、動画をカテゴリ分けします。

AWS Elastic Beanstalk は、アプリケーションのデプロイと管理を簡素化するマネージドサービスで、Auto Scalingやロードバランシングも自動で処理します。Elastic Beanstalkは便利ですが、既に他の選択肢で説明されているLambdaやS3と組み合わせたソリューションの方が運用の効率化には有利です。