Amazon Web Services ブログ

Category: Database

Amazon DynamoDB グローバルセカンダリインデックスを設計する方法

大学時代、私はリレーショナルデータベースのシステム要件をモデル化するために、エンティティ関係図を作成しました。このプロセスでは、ソフトウェアシステムのすべてのエンティティを検索し、それらのエンティティ間の関係を定義しました。次に、データベースがどのクエリをサポートする必要があるかを判断する前に、関係とエンティティをデータベーステーブルにモデル化しました。データベーススキーマを設計するこの方法は、スケーラビリティとより一貫したパフォーマンスを利用するために非リレーショナルデータベースを使い始めるまではうまく機能しました。 非リレーショナルデータベースでは、スキーマ設計のアプローチは逆になります。データベーススキーマを設計する前に、アプリケーションが必要とするクエリを特定するために「クエリ優先」アプローチを使用するのです。そのため、データはアプリケーションが使用する必要がある方法で明示的に保存され、クエリの効率が向上します。 また、クエリに柔軟性を追加したい場合は、Amazon DynamoDB でグローバルセカンダリインデックスを使用することができます。DynamoDB テーブルでグローバルセカンダリインデックスを使用すると、非キー属性を使用して他のディメンションでデータを柔軟に照会できます。 ただし、効率的なクエリパフォーマンスを維持するには、DynamoDB テーブルのスキーマを設計したのと同じ方法で、グローバルセカンダリインデックスのスキーマを慎重に設計する必要があります。このブログ記事では、グローバルセカンダリインデックスのスキーマを設計するためのアプローチを示し、設計プロセスにおける一般的な落とし穴を回避する方法を説明し、コストを削減するためのヒントを提供します。 グローバルセカンダリインデックスのスキーマ設計プロセス 次の図は、グローバルセカンダリインデックスのスキーマを設計する方法について、この記事で説明しているアプローチをまとめたものです。 クエリパターンを特定する アプリケーション固有のクエリパターン (テーブルがサポートするクエリの種類) が、グローバルセカンダリインデックスの設計を推進します。設計を推進する中心的な質問は、「グローバルセカンダリインデックスが回答する、どのような質問が必要であるか?」ということです。 回答が必要な質問が決まったら、質問をテーブルデータのクエリにマッピングします。「より大きい」、「より小さい」、「の間」、「で始まる」などの範囲クエリに基づくデータフィルターを使用します。 アクセスしなければならないがフィルタリングやソートを必要としない他のデータについても考慮する必要があります。たとえば、オンラインショッピングのウェブサイトに商品情報を表示するには、商品の ProductId でデータをフィルター処理します。ただし、クエリでアクセスする必要があるその他のデータには、製品の説明、価格、重量、製品の色などがあります。できるだけ多くのクエリを事前に特定します。スキーマ設計でクエリを考慮に入れると、グローバルセカンダリインデックスのコストとパフォーマンスを最適化するのに役立ちます。 それでは例を見て、アプリケーション固有のクエリがテーブルクエリにどのように変換されるのかを確認しましょう。たとえば、オンラインショッピングのウェブサイトが、顧客の注文をすべて OrderId をパーティションキーとして Orders テーブルに保存しているとします。また、このテーブルには、OrderDate、CustomerId、Status など、注文に関するその他のデータも保存されています。次の表は、アプリケーション固有の一般的な質問とそれに対応するテーブルクエリの一部を示しています。 アプリケーション固有の質問 テーブルクエリ 注文日順に並べ替えられた顧客のすべての注文を検索する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate で並べ替える 特定の日付範囲内の特定の顧客の注文を取得する Orders テーブルのすべての注文を CustomerId でフィルター処理してから、OrderDate での範囲照会でフィルター処理する 顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」としてフィルター処理する 5 日以上経過している顧客の保留中の注文をすべて探す Orders テーブルのすべての注文を CustomerId でフィルター処理してから、Status を「Pending」とし、OrderDate < CurrentDate-5 の範囲照会でフィルター処理する 顧客のすべての注文の OrderId、OrderDate、Status […]

Read More

Amazon DynamoDB コンソールについて知りたかったが、質問できなかったすべてのことについての詳しいウォークスルー

2012 年にリリースされて以来、Amazon DynamoDB は、あらゆる規模で高速かつ予測可能なパフォーマンスを提供できるように設計された、完全マネージド型でマルチリージョン、マルチマスター対応のデータベースサービスとなりました。DynamoDB は、ウェブベースのコンソール、AWS コマンドラインインターフェイス (CLI)、多数のプログラミング言語用の SDK のセットという、操作を実行するための 3 つのオプションを提供する NoSQL データベースです。 このブログ記事では、DynamoDB のコアコンポーネント (テーブル、項目、属性)、グローバルテーブル、読み取り/書き込みキャパシティーモード、リザーブドキャパシティーの購入、バックアップメカニズムについて理解を深めるために、DynamoDB コンソールについて詳しく説明します。 DynamoDB コンソールについての詳細なウォークスルー DynamoDB コンソールを開始するには、以下の手順を実行します。 DynamoDB ホームページへ移動し、[Get started with Amazon DynamoDB] を選択します。(まだ AWS アカウントを設定していない場合は、[Create an AWS Account] を選択すると、アカウントを設定するプロセスが案内されます。) AWS マネジメントコンソールにサインインして、DynamoDB コンソールを開きます。 DynamoDB コンソールを初めて使用する場合は、[ようこそ] ページが表示され、DynamoDB に関する情報とその使用方法が表示されます。[ようこそ] ページには、一般的な操作を実行するための次の 3 つのオプションがあります。 テーブルの作成 項目の追加および照会 テーブルの監視および管理 DynamoDB コンソールに初めてアクセスした後は、常にコンソールの [ダッシュボード] ページから始めます。ダッシュボードには、Amazon CloudWatch アラームによってトリガーされた最近のアラート、プロビジョニングされたテーブルの合計キャパシティー、サービスヘルス、DynamoDB に関するその他の情報の詳細が表示されます。 上のスクリーンショットで番号付けされているように、ダッシュボードのセクションは以下のとおりです。 […]

Read More

PostgreSQL ユーザーとロールの管理

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上の開発作業を経て、PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。アマゾン ウェブ サービス(AWS)は、管理された 2 つの PostgreSQL オプションを提供します:PostgreSQL および Amazon Aurora PostgreSQL 用の Amazon Relational Database Service(Amazon RDS)。この記事では、PostgreSQL でユーザーとロールを管理するためのベストプラクティスについて説明しています。 PostgreSQL を使用すると、きめ細かいアクセス権限を持つユーザーとロールを作成できます。新しいユーザーまたはロールには、各データベースオブジェクトに必要な権限を選択的に付与する必要があります。これはエンドユーザーに多くの力を与えますが、それと同時に、正しい許可を持つユーザーとロールを作成するプロセスを潜在的に複雑にしています。 PostgreSQL では、データベースユーザーに直接権限を付与することができます。ただし、グッドプラクティスとして、アプリケーションとアクセスの要件に基づいて、特定の権限のセットを持つ複数のロールを作成することをおすすめします。次に、各ユーザーに適切な役割を割り当てます。ロールは、データベースオブジェクトにアクセスするための最小権限モデルを強制するために使用するべきです。Amazon RDS および Aurora PostgreSQL インスタンスの作成中に作られたマスターユーザーは、他のユーザー、ロール、およびデータベースの作成などのデータベース管理タスクにのみ使用する必要があります。マスターユーザーはアプリケーションによって使用されるべきではありません。 PostgreSQL できめ細かいアクセスコントロールを設定するための推奨アプローチは次のとおりです: マスターユーザーを使用して、readonly や readwrite などのアプリケーションまたはユースケースごとにロールを作成します。 これらのロールがさまざまなデータベースオブジェクトにアクセスできるように権限を追加します。例えば、readonly ロールは SELECT クエリのみを実行できます。 機能にとって最低限必要な権限をロールに付与します。 app_user や reporting_user のように、アプリケーションごとまたは個別の機能ごとに新しいユーザーを作成します。 適切なロールをこれらのユーザーに割り当てて、ロールと同じ権限をすばやく付与します。例えば、readwrite ロールを app_user に付与し、readonly ロールを reporting_user に付与します。 […]

Read More

新しい Amazon DocumentDB の集計、配列、インデックス作成機能

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメント データベース サービスです。今日、使用したものと同じ MongoDB アプリケーションコード、ドライバー、およびツールを使用して、Amazon DocumentDB でワークロードを実行、管理、および拡張できます。これにより、基となるインフラストラクチャの管理を気にせず、パフォーマンス、スケーラビリティ、および可用性を向上させることができます。 今日、Amazon DocumentDB は、新しい集計パイプライン演算子とステージをサポートするようになりました。これにより、ドキュメントで強力な集計を作成することができます。新しい機能には、集計文字列演算子 ($concat, $substr, $substrBytes, $substrCP, $strcasecmp)、配列集計演算子 ($size)、集計グループ アキュムレータ演算子 ($push)、および集計ステージ ($redact と$indexStats) が含まれます。さらに、Amazon DocumentDB は、配列内の要素を更新する位置配列演算子 ($[] と $[<identifier>]) およびインデックスを選択する hint() をサポートするようになりました。 このブログ記事では、一般的なユースケースを示してこれらの新機能のいくつかを紹介します。これにより、Amazon DocumentDB で大規模のアプリケーションを構築および管理する機能を使い始めることができます。 Amazon DocumentDB の使用の開始 Amazon DocumentDB を使い始めるには、Amazon DocumentDB 入門ガイド、AWS CloudFormation のクイック スタートをご覧ください。準備ができたら、現在 MongoDB で使用しているものと同じアプリケーションコード、ドライバー、およびツールを使って、Amazon DocumentDB での開発を開始できます。 新機能 Amazon DocumentDB […]

Read More

Amazon DynamoDB Auto Scaling: 規模を問わないパフォーマンスとコストの最適化

 データベース容量の拡大は、面倒でリスクが伴う作業になり得ます。データベースとアプリケーションの微妙な動きを理解しているベテランの開発者とデータベース管理者でさえも、この作業には細心の注意を払います。共有 NoSQL クラスターの今の時代にもかかわらず、容量の増加は何時間、何日、または何週間もかかりかねません。このようなタスクを行った人なら誰でも、容量拡大中におけるパフォーマンスへの影響は予測不可能であったり、ダウンタイムを伴う場合があることを証言できます。逆に、容量を縮小する値打ちがあると判断することは、まれな状況でしかあり得ないでしょう。これにも独自の複雑な検討事項がつきものだからです。データベース容量の計画と作業がこれほど難しいのはなぜでしょうか? データベースをアンダープロビジョニングすると、アプリケーションに壊滅的な影響を及ぼす可能性があり、オーバープロビジョニングすると、数万、または数十万ドルが無駄になる可能性があります。誰もそのような経験はしたくありません。 Amazon DynamoDB は、開発者とデータベース管理者たちが 10 年以上前から信頼してきた完全マネージド型のデータベースです。DynamoDB は、あらゆる規模で低レイテンシーパフォーマンスを実現し、データベース容量管理を大幅にシンプル化します。最小限の取り組みで、多種多様な SDK および AWS のサービスと簡単に統合される、完全にプロビジョニングされたテーブルを得ることができます。テーブルをプロビジョニングした後は、その容量をすぐさま変更できます。アプリケーションが一晩で大人気を集めたことがわかったとしても、簡単に容量を増加できます。その一方で、アプリケーションロジックを最適化し、データベーススループットを大幅に低減する場合は、プロビジョニングされた容量を減らすことでコスト節約を即座に実現できます。DynamoDB のアダプティブキャパシティーは、裏手で容量の増加と削減をスムーズに処理します。 2017 年 6 月、DynamoDB は効率的な容量管理を容易にする Auto Scaling をリリースしました。それ以来、Auto Scaling は DynamoDB ユーザーが予測可能なトラフィックパターンを持つワークロードのコストを削減できるように援助し続けています。Auto Scaling がリリースされる前は、テーブルのピークロードと小さなバッファに対応するために容量を静的にプロビジョニングしていました。しかし、大抵の場合、テーブルをピーク容量以上に静的にプロビジョニングすることはコスト効率性が良くありません。このブログ記事では、Auto Scaling がトラフィックの変化に対応する方法、Auto Scaling に最適なワークロード、ワークロードの最適化方法とコストベネフィットの計算方法、そして毎秒 100 万件のリクエストで DynamoDB が実現できるパフォーマンスについて説明します。 背景: DynamoDB Auto Scaling の仕組み DynamoDB テーブルを作成すると、Auto Scaling がデフォルトの容量設定となりますが、それがアクティブになっていないテーブルで Auto Scaling を有効化することもできます。以下の図で説明されているように、DynamoDB Auto Scaling は背面で アプリケーションの Auto […]

Read More

Amazon Neptune のための Gremlin クエリヒントの紹介

Amazon Neptune は、高度に連結されたデータの保存とクエリのために最適化された、高速で信頼性に優れた完全マネージド型のグラフデータベースで、データにおける連結のナビゲートと活用に依存するオンラインアプリケーションに最適です。 Amazon Neptune は、SPARQL クエリ言語を使用してクエリできる W3C RDF グラフをサポートします。また、Gremlin グラフトラバース/クエリ言語を使用してクエリできる Apache TinkerPop プロパティグラフもサポートしています。 この記事では、Gremlin ユーザーが使用できるいくつかの新しい機能について検討していきます。今回は特に、クエリがどのように実行されるかをより良く制御できる新しいクエリヒント機能に注目します。 Gremlin クエリヒント Gremlin クエリヒントは、クエリがデータをトラバースする方法をより良く制御し、クエリ順序を最適化するかどうかを指定するために設計されています。このクエリヒントは、特にデータのシェイプを熟知している場合に便利です。 クエリヒントを適用するには、以下の withSideEffect Gremlin ステップを使用します。ここにある <hint-name> は適用されるヒントの名前に置き換え、<hint-setting> は適切な値に置き換えます。新しいヒントは、すべて Neptune# プレフィックスで始まります。 g.withSideEffect(‘Neptune#<hint-name>’,'<hint-setting>’) 現在利用可能なヒントとヒント設定を、以下の表に示します。各ヒントについては、この記事で後から詳しく見ていきます。 ヒント名 ヒント設定 アクション noReordering true Neptune はクエリの実行順序の最適化を試みません。これは、データがどのように編成されているかをユーザーが理解しており、Neptune が順序を変更して制約が適用されることがないようにしたい場合に最も有効です。 noReordering false Neptune は、最初に最も厳しい制約を適用するために、クエリの実行順序の最適化を試みます。これはデフォルトの noReordering 設定です。 repeatMode BFS 幅優先の方法でグラフをトラバースします。これは Gremlin の repeat ステップの使用時における Amazon Neptune のデフォルトバースモードで、多くのユースケースにとって望ましいモードです。ただし、多数の頂点を調べなければならない場合には、かなり多くのメモリを消費する場合があります。 […]

Read More

Amazon Aurora を使用して概念実証を作成する

お客様がクラウドに移行するにつれて、アプリケーションを実行する最良のツールを探しています。リレーショナル データベースを検討するとき、Amazon Aurora はよく選択されます。Amazon Aurora が MySQL および PostgreSQL とワイヤー互換であり、どちらよりも高いスループットを提供できることを考えれば、これは驚くようなことではありません。Aurora は、標準 MySQL データベースのスループットを最大 5 倍、標準 PostgreSQL データベースのスループットを最大 3 倍提供します。 顧客は Aurora を調査しながら、Amazon Aurora がアプリケーションに適しているかどうかを確認するために、一般的に概念実証 (POC) を構築します。以下に、POC を作成する際に考慮する点をいくつか示します。 Amazon Aurora は正しいツールなのか? データとデータベースについて考えるとき、重要な要素の 1 つはデータの速度です。一方では、データベースへの読み取りと書き込みの両方で、おそらく数千の接続と数十万の同時クエリでデータが非常に速く移動します。この速度では、クエリは通常、一度に比較的少数の行に影響します。さらに、データがこの速度でアクセスされるときは、レコードのようにクエリが一度に複数の列にアクセスするのが一般的です。このアクセス タイプでは、より実用的にデータを行単位で保存および取得することができます。このワークロード タイプの一般的な例は、オンライン トランザクション処理 (OLTP) システムです。 一方では、データの速度が遅くなるにつれて、ほんの一握りの接続と並行して実行されている少数のクエリしかない可能性があります。ただし、ここでは、完全なテーブルのスキャンを含め、行の範囲が何倍も大きいことがよくあります。この速度でクエリは、おそらくテーブルの行すべてに集中するよりは、通常、より小さな列のサブセットに集中します。この方法では、より実用的にデータをカラムナ形式で保存します。さらに、遅い速度での書き込みパターンは大きく異なります。ほとんどのデータは、高速では定期的に一括で読み込まれ、より高速ではほぼ一定で個々に書き込まれます。このワークロードタイプの一般的な例は、データ ウェアハウジングまたはオンライン分析処理 (OLAP) システムです。 Amazon Aurora は、主に高速データを処理するために設計されました。ワークロードに応じて、単一 r4.16xlarge の Aurora クラスターでは、1 秒間で 600,000 を超える SELECT ステートメントを処理できます。このようなクラスターでは、1 秒間で […]

Read More

Amazon DynamoDB の大量の時系列データの設計パターン

時系列データは、経時変化のパターンを示しています。たとえば、次のグラフの例に示すように、センサーを通じて環境データを記録するモノのインターネット (IoT) デバイスがあります。このデータには、温度、気圧、湿度、その他の環境変数が含まれる場合があります。各 IoT デバイスは定期的にこれらの値を追跡するため、バックエンドは毎秒最大数百、数千、または数百万のイベントを取り込む必要があります。 このブログ記事では、大量の時系列データを扱うシナリオ用に Amazon DynamoDB を最適化する方法について説明します。これを、自動化とサーバーレスコンピューティングを活用した設計パターンを使用して行います。 DynamoDB で大量のイベントを設計する 通常、データ取り込みシステムには以下が必要です。 現在の時間に関連する新しいレコードを取り込むための高い書き込みスループット。 最近のレコード用の低いスループット。 古いレコード用の非常に低いスループット。 このようなイベントをすべて単一の DynamoDB テーブルに格納する場合、ホットパーティション (最新のレコード) とアクセス頻度の低いパーティション (古いレコード) があります。アクセス頻度の低いパーティションは、プロビジョニングされた書き込み容量を、新しいレコードを保存しておきたいホットパーティションから逸らしてしまうため、最適ではありません。さらに、分析ニーズに適した期間を設計したいことがよくあります。たとえば、過去数日間または数か月間のデータを分析するとします。これらの期間の長さを調整することで、分析パフォーマンスとコストの両方を最適化できます。 DynamoDB の一般的な設計原則では、できるだけ少ない数のテーブルを使用することが推奨されていますが、時系列データでは、その設計原則に反して、各期間に複数のテーブルを作成します。この記事では、このようなアンチパターンを DynamoDB に使用する方法を説明しますが、時系列データには最適です。 オンデマンドキャパシティーモードを選択しない限り、すべての DynamoDB アクセスパターンは、読み取り容量単位と書き込み容量単位の異なる割り当てを必要とします。この記事では、レコードの読み書き頻度に基づいて、レコードを次の 3 つの異なるグループに分類します。 毎秒書き込まれる新しいレコード よく読み取られる最近のレコード あまり読み込まれない古いレコード 新たに取り込まれたレコードの書き込みスループットを最大にするには、期間ごとに新しいテーブルを作成し、最大数の書き込み容量単位と最小数の読み取り容量単位を割り当てます。また、各期間の終了前に次の期間のテーブルを事前作成して、現在の期間が終了したときにすべてのトラフィックをそのテーブルに移動できるようにします。古いテーブルへの新しいレコードの書き込みをやめると、その書き込み容量単位を 1 に減らすことができます。短期間の読み取り要件に基づいて、適切な読み取り容量単位もプロビジョニングします。次の期間が終了したら、読み取り容量や書き込み容量をオーバープロビジョニングしたくないので、割り当てられている読み取り容量単位も減らします。 また、新しい期間に切り替える頻度を見積もる際にも、分析上のニーズを考慮する必要があります。たとえば、昨年何が起こったのか分析したいと思った場合、4 つの並列クエリでデータをより効率的に取得して 4 つの結果セットを集計できるように、四半期ごとのテーブルを使用できそうです。 他のユースケースでは、前四半期のデータだけを分析したいと思うかもしれず、また毎月のテーブルを使用しようと考えるかもしれません。これにより、3 つの並列クエリを実行して分析を実行できます (四半期の各月に 1 回ずつ)。一方、この分析で特定の洞察が日単位で必要な場合は、日次テーブルを選択することを考えるかもしれません。 この記事の残りの部分では、日次テーブルを使用した後者のシナリオに焦点を当てます。昨日のデータが分析に適していて、より古いデータは頻繁にアクセスされないとします。真夜中の直前に新しいテーブルを作成し、真夜中の直後に古いテーブルの書き込み容量単位を減らすためにスケジュールされたジョブを設定しました。 このようにして、いつも以下があるようにします。 1,000 の書き込み容量単位と 300 の読み取り容量単位 (最大の書き込み数と一部の読み取り数) を持つ今日のテーブル。 1 […]

Read More

AWS CloudFormation を使用して、推奨されるベストプラクティスによって Amazon Aurora PostgreSQL DB クラスターをデプロイする

このブログ記事では、Amazon Aurora PostgreSQL クラスターのクイックスタートリファレンスデプロイメントを構築する方法について説明します。クラスターはセキュリティと高可用性のための AWS のベストプラクティスに基づいており、AWS CloudFormation を使用して速やかに作成できます。必要に応じてカスタマイズできる CloudFormation の一連のサンプルテンプレートを見ていきます。 Amazon Aurora は、クラウド用に構築された MySQL および PostgreSQL 互換のリレーショナルデータベースです。Aurora は、ハイエンドの商用データベースのパフォーマンスと可用性、ならびにオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 PostgreSQL 互換エディションの Aurora は、同じハードウェアで動作する標準 PostgreSQL の最大 3 倍のスループットを実現します。これにより、既存の PostgreSQL アプリケーションおよびツールを変更することなく実行できます。PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組み合わせは、商用データベースの移行にとって理想的なターゲットです。 Aurora PostgreSQL で道筋を始めて、AWS Well-Architected フレームワークの推奨ベストプラクティスに基づいて AWS リソースを設定したい場合は、ここで提供されている CloudFormation テンプレートを使用できます。 アーキテクチャの概要 下の図は、アーキテクチャの図であり、これから設定しようとしているものの簡単な要約です。 サンプルの CloudFormation テンプレートは、ネットワークインフラストラクチャとアーキテクチャの図に示されているすべてのコンポーネントをプロビジョニングします。CloudFormation テンプレートを次の 3 つのスタックに分割しました。 VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NAT ゲートウェイ、S3 ゲートウェイエンドポイント、AWS Secrets Manager インターフェイスエンドポイント、およびその他のネットワークコンポーネントを設定する CloudFormation […]

Read More

Amazon RDS for Microsoft SQL Server で、クロスアカウントのネイティブバックアップおよびリストアを設定する

Amazon Relational Database Service (Amazon RDS) は、Microsoft SQL Server データベースのネイティブバックアップおよびリストアをサポートしています。複数の AWS アカウントがある場合、Amazon RDS インスタンスと Amazon Simple Storage Service (Amazon S3) バケットが同じ AWS リージョンにあれば、これらのアカウント間でネイティブバックアップおよびリストアを実行することができます。これらの手順を進める前に、この要件を理解しておくことが重要です。 この記事では、Amazon RDS for SQL Server でクロスアカウントのネイティブバックアップおよびリストアを実行するために必要なアクセス許可とポリシーを設定する方法について説明します。この手順では、これらのリソースを含む以下の AWS アカウントがあることを前提としています。 アカウント A – Amazon RDS for SQL Server インスタンス アカウント B – Amazon S3 バケット すべての設定は、S3 バケットが存在するアカウント B で行う必要があります。アカウント B で以下の作業を行います。 IAM ポリシーを作成する。 ロールを作成し、信頼ポリシーを設定する。 […]

Read More