2024年9月アーカイブ

  1. Gartner社による生成AIのレポート
  2. 生成AI導入の進め方
  3. まとめ


Gartner社による生成AIのレポート

Gartner社は、データ品質の低さ、リスク管理の不十分さ、コストの増大、ビジネス価値の不明確さなどの理由で、2025年末までに生成AIプロジェクトの30%がPoC以降に中止されるだろうと発表しました。

2024/07/29に発表されたGartner社によるレポート


2024/7/29にシドニーで開催されたGartner Data & Analytics Summit

Gartner Data & Analytics Summitで講演した、Gartner社のRita Sallam氏は、「今までされてきた誇大宣伝の後、各社の経営者は生成AIに実施した投資回収を待ちきれず、生成AIの価値を表明することに苦労しています。生成AIプロジェクトの範囲が広がるにつれて、システム開発・利用に必要な金銭的負担がますます大きくなっています。」と話しました。

Gartner社によると、生成AIは生産性向上・業務効率化のために使用されることが多いですが、会社の利益に結びつけることが難しく、投資判断をしにくい背景があると述べられています。


生成AI導入にかかる費用例

下記はGartner社が発表した生成AI導入にかかる費用例です。プロジェクトの規模に応じてかかる費用は大幅に変動するため、参考値としてお受け取りいただきたいですが、投資に見合うためのシステム導入をするためには、新たなビジネスチャンス(コスト削減ではなく、売上増加)を目指して生成AIを導入する必要がありそうです。

生成AI導入にかかる費用例

「残念ながら、生成AIには万能なソリューションはなく、コストは今までのシステム開発や導入に比べて不確実性が大きいです。」とRita Sallam氏は言います。「コストは、支出額、投資するユースケース、採用する導入アプローチによって決まります。市場を大きく変えるために生成AIをあらゆるところに導入したいと考えている場合や、生産性向上や既存プロセスの拡張に重点を置く堅実な場合など、費用、リスク、変動性、戦略的影響のレベルはそれぞれ異なります。」

生成AI導入に後ろ向きなことを書いてしまいましたが、導入の効果・成功例は多分にあります。Gartner社のレポートWhat Mature Organizations Do Differently for AI Successでは、ユース ケース、職種、従業員のスキル レベルに応じて異なるさまざまなビジネス改善を報告しています。最近の822名を対象とした調査では、回答者の平均では15.8%の収益増加、15.2%のコスト削減、22.6%の生産性向上が報告されており、使い所を適切に見極めることで、効果を得られることが分かっています。

次の章から生成AIプロジェクトの進め方を紹介します。


生成AI導入の進め方

生成AI導入の進め方


1. 生成AIの得意不得意を知る

まず生成AIがどのようにビジネスに貢献できるかを理解することが大切です。生成AIとは、テキスト、画像、音声など、様々な形式のコンテンツを自動的に生成する技術です。下記に代表的な得意分野を記載します。

代表的な活用分野

  • カスタマーサポートの自動化
  • 商品説明やコンテンツの自動生成
  • デザインや広告素材の生成
  • 自動テキスト要約やレポート作成


2. プロジェクトの目的と目標を決める

まずビジネス課題を明確にするところから始まります。どのような問題を解決したいのか、あるいはどのプロセスを効率化したいのかを具体的に定義します。

  • 目的の設定: 生成AIを導入することで達成したいゴールは何か?
  • KPIの設定: 生成AIの効果を測るための指標(例:生成されたコンテンツの量、品質、時間の短縮など)を設定します。


3. データの収集と準備

自社のナレッジを学習させるためには、大量のデータが必要です。データの品質が精度に大きく影響します。以下のステップを踏んで、データの質を確保します。

  • データの収集: 自社のデータや公開されているデータセットを活用します。
  • データの前処理: データのクリーニングや正規化を行い、ノイズを除去します。
  • データのアノテーション: 必要に応じて、データにラベル付けを行い、モデルが効果的に学習できるようにします。


4. モデル選定とカスタマイズ

生成AIモデルには、既存のオープンソースモデルやクラウドサービスで提供されているモデルを利用する方法があります。たとえば、OpenAIのGPTシリーズやDALL-Eなどの大規模言語モデルが有名です。

  • 既存モデルの活用: 既存の生成AIモデルを使用すれば、導入がスムーズで費用対効果が高いです。
  • カスタムモデルの構築: 自社のビジネスニーズに合わせてモデルをカスタマイズする場合、ファインチューニングが必要です。


5. インフラの選定と構築

生成AIは計算リソースを大量に使用するため、適切なインフラが必要です。クラウドサービス(AWS、GCP、Azureなど)を活用すると、スケーラビリティやコスト面で柔軟に対応できます。

  • クラウドインフラの構築: 生成AIモデルのトレーニングや推論に最適化されたインフラを用意します。
  • コストの最適化: 必要に応じてオンデマンドリソースを活用し、コストを管理します。


6. テストとパイロット運用

AIモデルの導入前には、十分なテストとパイロット運用を行う必要があります。生成AIの出力品質を確認し、ビジネス要件に合致しているかどうかを評価します。

  • 生成結果の検証: 出力されたコンテンツが期待通りか、ユーザーが満足できる品質かを確認します。
  • パイロット運用: 小規模なプロジェクトでまず運用を開始し、実際の運用に耐えられるかテストします。


7. 生成AIの運用と改善

生成AIは、導入した後も継続的な改善が可能です。運用中に得られたフィードバックをもとに、微調整を行います。

  • パフォーマンスモニタリング: モデルの出力やパフォーマンスを監視し、問題があれば対応します。
  • 継続的な改善: 新しいデータや技術を取り入れて、AIモデルを進化させ続けます。

  • まとめ

    生成AIが「既存のデータを活用し、新たなコンテンツ(文章・画像・音声など)などまだ得られていないものを作る技術」であるため、その技術を作ることも正解のないプロジェクトです。

    正解のない、つまり生成AIプロジェクトは場当たり的になってしまうのか?とご質問いただくことが多いのですが、それは違います。ここは他のシステム開発プロジェクトと同じで、適切な準備と計画が成功の鍵を握ります。目標を明確にし、データを整備し、生成AIを段階的に導入することで、途中で頓挫してしまう・システム構築したけれど使えない・想定より費用がかかる、などの失敗へのリスクを低減します。

    当社では、生成AIの活用にむけて無料相談会を実施しています。みなさんが考えていることを具体化させる、次のタスク・ステップを明確にする、生成AIでできるか回答する、などのようなご相談も大歓迎です。ぜひお気軽にお問い合わせください。




    X(旧Twitter)・Facebookで定期的に情報発信しています!

目次

  1. 背景
  2. コスト削減のための分析
  3. 解決策
  4. 結果

 

背景

Amazon RDS(Relational Database Service)は、多くの企業で利用されるマネージド型データベースサービスです。高可用性や自動バックアップなどの機能を備えており、運用管理の負担を軽減しますが、使い方によってはコストが膨らみ、企業のIT予算を圧迫する原因となります。
当社でもRDSのコスト最適化に取り組み、その結果、利用コストを最大で50%削減することに成功しました。


RDSコスト削減のために改善できるポイントは以下の通りです。
1. 使用していないリソースが長期間稼働している。
2. データベースインスタンスのサイズが適切でないため、リソースが過剰に割り当てられている。
3. ストレージやバックアップが最適化されていない。
4. オンデマンド料金が高く、コストが予測しづらい。
今回は、これらの問題に対処するために行った原因調査と解決策について具体的に解説し、どのようにコスト削減を実現したかを紹介します。


コスト削減のための分析

まずは、AWS Cost Explorerを使用してRDSのコストを詳細に分析しました。


RDSのコスト構成要素

1.インスタンスの稼働料金:データベースインスタンスのサイズに応じて、時間ごとに発生。
2.ストレージ料金:データベースのストレージ容量に基づいて発生。
3.バックアップ料金:自動バックアップやスナップショットに対するストレージ料金。
4.データ転送料金:データベースから外部に出るデータの転送料。


不必要なコストの原因

1.過剰なインスタンスサイズ:使用しているインスタンスサイズが過大であり、実際のトラフィックに比べてリソースが過剰に割り当てられていた。
2.ストレージの最適化不足:必要以上に高パフォーマンスなストレージタイプを使用していた。
3.リザーブドインスタンスの未活用:オンデマンドインスタンスを利用しており、リザーブドインスタンスのディスカウントを活用していなかった。


解決策

それぞれの問題を解決するため、以下の施策を実行しました。


1. インスタンスサイズの適正化

アプローチ

RDSインスタンスのサイズを、実際のトラフィックやパフォーマンス要件に基づいて見直しました。
例えば、CPU使用率やメモリ使用量がインスタンスのスペックに比べて著しく低い場合、インスタンスを小さいものに変更することで、コストを削減できます。
以下の表のように、m5.largeからt3.mediumに変更すると、月額200USD以上のコスト削減が期待できます。

RDSインスタンスサイズによる価格表"

ポイント

オンデマンドインスタンスは、利用時間に応じて料金が発生するため、インスタンスの稼働状況に応じたリサイズを行うことで、効率的にコストを削減できます。


2. ストレージタイプの最適化

アプローチ

RDSはストレージの種類として、汎用SSD(gp2)、プロビジョンドIOPS(io1)、マグネティックなどがあります。高パフォーマンスなio1を利用していたものの、実際にはそこまでの性能が必要なかったため、汎用SSD(gp2)に変更することでストレージコストを削減しました。

500GB使う場合のそれぞれのストレージタイプでのコストは以下のため、月額252USDの削減が期待できます。

ストレージタイプによるコスト比較

ポイント

ストレージタイプを最適化することで、コストを大幅に削減できます。特に、I/O性能が必要ない場合は、汎用SSD(gp2)を利用するとよいです。


3. リザーブドインスタンスの活用

アプローチ

オンデマンド料金が高く、長期的にRDSを使用することが分かっている場合、リザーブドインスタンスを購入することで、コストを大幅に削減できます。
リザーブドインスタンスは1年または3年のコミットメントを前提に割引が適用されるため、オンデマンドインスタンスに比べて最大で40%のコスト削減が期待できます。

db.t3.mediumの場合、リザーブドインスタンスの活用有無でのコストは以下です。リザードインスタンス1年利用だけでも、月額34USD程度のコスト削減が期待できます。

リザードインスタンス活用有無による価格表

ポイント

長期的な利用が予想されるRDSインスタンスに対しては、リザーブドインスタンスを活用することで、コストの削減が可能です。
オンデマンド料金と比較して、割引率が高いため、特に3年契約を検討する価値があります。


4. 自動バックアップとスナップショットの最適化

アプローチ

自動バックアップやスナップショットは、定期的に実行されますが、不要なバックアップやスナップショットを削除することで、ストレージコストを削減しました。
バックアップの保持期間を短縮することや、不要なスナップショットを定期的に削除する運用を導入しました

コスト計算

バックアップストレージ: 0.095USD/GB/月
50GBの不要なスナップショットを削除する場合: 50GB × 0.095USD = 月額4.75USDの削減


結果

これらの最適化アプローチにより、RDSのコストを全体で約50%削減することができました。
特に、インスタンスサイズの見直しとストレージタイプの最適化が大きな影響を与え、リザーブドインスタンスの活用で長期的なコスト削減効果をさらに高めました。


総合的なコスト削減効果(月額)

  • インスタンスサイズの適正化による削減: 200USD

  • ストレージタイプの最適化による削減: 252USD

  • リザーブドインスタンスの活用による削減: 34USD

  • バックアップとスナップショットの最適化による削減: 4.75USD

  • 合計削減額: 490.75USD


Amazon RDSのコスト削減は、インスタンスの見直しやストレージの最適化、長期的な利用を考慮したリザーブドインスタンスの活用など、いくつかの簡単な手順で達成可能です。




X(旧Twitter)・Facebookで定期的に情報発信しています!

目次

  1. はじめに
  2. SaaS活用に至る変遷
  3. 連携基盤構築のアプローチ
  4. 事例

 

はじめに

デジタル化が進んだことでSaaSの活用が増えています。

SaaSはクラウドサービスの一部で、総務省の「令和4年通信利用動向調査」によると、クラウドサービスを一部でも利用している企業の割合は、2022年には72.2%に達しています※ 総務省 令和4年通信利用動向調査
そのうち、クラウドサービスの効果について、「非常に効果があった」または「ある程度効果があった」と回答した企業の割合は87.1%と、多くの企業が導入効果を感じており、今後もSaaS利用は加速していくでしょう。

SaaSは便利ですが、その急速な普及に伴い、システム企画部門にとって新たな課題が生じています。
各部署で独自に導入されたSaaSのデータ連携や、異なるSaaS間での業務効率の低下などが代表的な課題です。

本ブログでは、複数のSaaSの組み合わせ・データ連携に頭を悩ませている方向けに、当社がおすすめしている解決策を紹介いたします。


SaaS活用に至る変遷

以前は、スクラッチ開発で自社業務にマッチしたシステムや、SaaS追加開発し、ひとつのシステムで関連業務をすべてまかなうシステムが多く構築されていました。
その方法では、導入までに時間がかかること、SaaSのバージョンアップで追加開発箇所に不具合が生じることなど、導入前後に大きな課題を引き起こしました。

これを解消するために、近年ではSaaSは追加開発せず、複数SaaSを組み合わせて利用することが増えました。

そのため、「どの組み合わせが最適か」「複数のSaaSが業務に合わせてデータが繋がらず、データを2重管理している」など、新たな課題が出現しています。

SaaSを連携させるためのデータ連携基盤を構築し、APIで連携させるアーキテクチャを提案しています。
SaaS同士のデータ連携はもちろん、連携すべきシステムを追加する際も、連携基盤へ連携するため将来的なメンテナンス性も高まります。

複数のSaaSシステムがそれぞれ連携するイメージと、今回提案している、SaaSを連携させるためのデータ連携基盤を構築するイメージを図で表現します。


複数のSaaSシステムがそれぞれ連携する

複数のSaaSシステムがそれぞれ連携


それぞれのSaaSシステム同士が直接繋がっており、連携の数が増えるに従って接続の複雑さが増していくことがわかります。 このような接続方法では、各システムごとに個別の連携開発が必要となり、効率が悪くなる傾向があります。






提案:データ連携基盤を介して複数システムが連携する

データ連携基盤をハブにして各システムを連携


各SaaSシステムはデータ連携基盤に接続されており、システム同士が直接繋がるのではなく、連携基盤を通じてデータがやり取りされます。
これにより、各システム同士の個別の接続開発が不要となり、連携の複雑さが大幅に削減されます。 このようなアーキテクチャは、拡張性とメンテナンスのしやすさを向上させる効果があります。



連携基盤構築のアプローチ

連携基盤を構築し各SaaSを連携させていくためのステップを紹介します。

(1) 現状分析と要件定義
- 連携する各SaaSシステムの現状を把握し、どのデータがどのシステムで必要かを明確にする。
- 各システム間のデータの流れや連携頻度、形式を定義する。

(2) アーキテクチャ設計
- 連携基盤の基本アーキテクチャを設計。APIゲートウェイ、メッセージキュー、ETL(Extract/Transform/Load)ツール、データ変換機能などの必要なコンポーネントを検討する。
- セキュリティやデータの可視性・統制を含め、どのようにデータを管理するか設計する。

(3) APIおよびデータフォーマットの標準化
- すべてのシステムが統一されたAPIを介して接続できるようにする。
- 連携データのフォーマット(JSON、XML、CSVなど)やバージョニングの標準化を行う。

(4) データ変換・マッピング
- 各SaaSシステムが異なるデータ形式やフィールドを使用している場合、データのマッピング・変換処理を設計する。ETLツールを活用してデータの抽出、変換、ロードを実行する。

(5) リアルタイム連携とバッチ処理の設計
- リアルタイムでデータ連携が必要なケースと、バッチ処理で定期的に連携するケースを分け、システムに負荷がかからないよう設計する。
- それぞれに適したメッセージングツールやスケジューリングツールを導入する。

(6) セキュリティとアクセス管理
- APIアクセスの認証・認可を設置し、データの暗号化やログ管理を実施する。
- 連携するシステムごとにアクセス権を細かく設定し、データの安全性を確保する。

(7) モニタリングとエラーハンドリング
- 連携基盤に対する監視を導入し、リアルタイムでエラーやパフォーマンス問題を検知できるようにする(例:ログ管理ツールやアラートシステム)。
- エラーが発生した場合のリトライやエラーハンドリングの設計も重要。

(8) テストと検証
- 各SaaSシステム間のデータのやり取りを詳細にテストし、データが正しく連携されることを確認する。
- スケーラビリティやパフォーマンスのテストも実施し、将来的な負荷に耐えられるか検証する。

(9) 運用と保守
- データ連携基盤を運用に移行し、定期的なメンテナンスやシステム更新、データフォーマットの変更に対応できる体制を整備する。
- 新しいSaaSシステムが追加された際に、スムーズに統合できるように柔軟性を持たせる。

これらのアプローチを順次実行することで、安定したデータ連携基盤を構築できます。構築後は、継続的な監視と改善が重要です。

事例

 

ここでは2つの事例を紹介します。

Salesforceをデータ連携基盤に使用した事例

複数店舗を持たれている to C向けの事業を実施している会社様です。
店舗やコールセンターで得られたお客様からの声を、適切に本社に連携し、分析用にデータを蓄積する必要があります。
もともとはSalesforceが導入されていましたが、店舗やコールセンターでは機能が過剰であること、データ分析はもっと高性能な機能が必要であることから当社に相談いただきました。

アプローチ

  • 店舗・コールセンターのデータ入力用の画面を構築し、データはSalesforceにAPI連携。
  • データ分析は、BI専用ツール(Amazon QuickSight)を導入し、Salesforceと簡単に連携。

システム構成イメージ

スクリーンショット 2024-09-09 6.37.03.png

メリット:既存システムを活かし、業務の効率化とデータ分析の強化

  • 既存のSalesforceおよび蓄積されたデータを活かすことができたこと
  • 店舗・コールセンター業務に特化したシステム導入により、現場のキャッチアップ期間を最低限にできたこと
  • BIツールは、AWSマネージドサービスを活用し、構築費用・期間を最低限にできたこと


SaaSとスクラッチ開発を組み合わせた事例

百貨店などに出店されている to C向けの商品の販売・製造を実施している会社様です。
百貨店内の店舗から注文され、在庫を確認し、出荷する一連の流れを、電話やExcel管理・目視チェックなど、ややアナログな環境で運用されていました。
今後の事業拡大(=注文数・生産数増加)を見越して、業務効率を上げるためにシステム化を検討され、当社に相談いただきました。

アプローチ

  • 標準化しやすいい業務はSaaSに置き換え
  • 標準化しにくく、お客様独自の業務がスクラッチで開発
  • 各システムを連携するハブを構築し、APIでデータ連携

システム構成イメージ

スクリーンショット 2024-09-09 6.37.11.png

メリット:システムの柔軟性は維持したまま、業務の標準化

  • SaaSとスクラッチ開発を組み合わせることで、構築費用・期間を最低限にできたこと
  • 各システムを疎結合にし、システムリプレイス・システム追加構築をしやすい構成にしていること


業務と密接に関わっているSaaSの連携は「これだけやればいい」といった正解がありません。
お客様ごとの業務をヒアリングし、適切な構成を提案いたします。ぜひお気軽にご相談ください。


X(旧Twitter)・Facebookで定期的に情報発信しています!

はじめに

AWSのアカウント管理を実施するにあたり「Well-Architected Framework」への考慮は必要不可欠です! 私たちAWSユーザは、AWS Organizationsを利用したマルチアカウント戦略の実践を、AWSからベストプラクティスとして推奨されています。 今回は、AWS Organizationsを利用したマルチアカウント戦略の実践により、AWSアカウント管理でよくある課題を解決する方法をいくつかご紹介いたします。


目次

  • AWSアカウント管理でよくある課題
  • AWS Organizationsによるマルチアカウント戦略
    • AWS Organizationsのみで実現
    • AWS Organizations + AWSマネージドサービスの組み合わせで実現
  • まとめ


AWSアカウント管理でよくある課題

まずはじめに、


  • アカウント管理
  • セキュリティ
  • コスト


の3つの観点から、AWSアカウントを利用する上でお客様からよく伺う課題を見ていきます。


観点 現状 課題
アカウント管理 ・複数のシステム管理に伴いAWSアカウント数が(開発/検証/本番を含めると)20〜30個ある
・AWSアカウントは社内担当者もしくは社外ベンダーが管理している
・開発会社は複数に渡り、運用もベンダーに一任している
・AWSアカウント数が多く管理できていない
・アクセス権が細かく適切に付与できていない
・設定内容がセキュリティ要件を満たしているのかをチェックする機能が無い
・チェックする機能はあるがコストがかかっている
セキュリティ ・導入必須なミドルウェアやツールの指定がある
・システム毎に個別の要件やルールがある
・ミドルウェアやツールの導入率が低い
・上記未導入時の検知 → 改善・運用が構築されていない
・個別の要件やルールの適用確認が困難である
・不正アクセス等の検知ができていない
コスト ・AWSアカウント毎に請求が個別である
・AWSのコストは月1度の請求で確認している
・個々の請求処理が手間である
・AWSの急激なコスト上昇を把握できていない
・不要なリソースの放置による微細なコスト上昇に気付いていない
・AWSの予算オーバーを請求段階でしか検知できていない


これらの課題の多くは、AWSアカウントの 個別管理 に起因しています。 では、上記課題の解決策を、AWS Organizationsを利用したマルチアカウント戦略の観点から確認したいと思います。


AWS Organizationsによるマルチアカウント戦略

まずは、AWS Organizationsの機能について確認します。


AWS Organizationsとは、AWSアカウントを統合・管理・制御するためのAWSサービスであり、追加料金は不要です。1つのAWSアカウントを管理アカウントとして指定することで組織を作成します。その組織へのAWSアカウントの作成または追加により、階層構造を実現します。この階層構造により、システムやプロジェクト毎にAWSアカウントを分けて管理することが可能です。これが、AWS Organizationsを利用したマルチアカウント戦略です。さらには、AWS OrganizationsとAWSマネージドサービスを組み合わせることにより、一層ハイレベルなAWSアカウントの管理を実現します。


pasted-2024.08.08-14.22.30.png


以下では、AWS Organizationsを利用した具体的な課題の解決方法を見ていきます。


AWS Organizationsのみで実現


観点 課題 解決方法
アカウント管理 ・AWSアカウント数が多く管理できていない
・アクセス権が細かく適切に付与できていない
・OU(Organization Unit)単位でAWSアカウントをグループ化する
・AWS Organizationsに対応しているAWSサービスに対してOU単位で設定を実施する
・IAMグループごとにアクセス可能なAWSアカウントやAWSリソースへの権限の範囲を指定する
セキュリティ ※AWS Organizations + AWSマネージドサービスの組み合わせで実現
コスト ・個々の請求処理が手間である ・管理アカウントにて全てのAWSアカウントのコストを一括支払いする


AWS Organizations + AWSマネージドサービスの組み合わせで実現


観点 課題 解決方法
アカウント管理 ・設定内容がセキュリティ要件を満たしているのかをチェックする機能が無い
・チェックする機能はあるがコストがかかっている
・AWS Configを組み合わせることで複数のAWSアカウントのAWS Configデータを管理アカウントに一元的に集約し、AWSリソースの設定と関係を継続的に監査・評価する
セキュリティ ・ミドルウェアやツールの導入率が低い
・上記未導入時の検知 → 改善・運用が構築されていない
・個別の要件やルールの適用確認が困難である
・不正アクセス等の検知ができていない
・AWS Systems Managerを組み合わせることで各AWSアカウントのインスタンスに対してセキュリティパッチを一元適用する
・Amazon S3を組み合わせることで各AWSアカウントのセキュリティログを一元的に集約する
・Amazon Athenaを組み合わせることで集約されたセキュリティログに対してクエリを一括に実行し、セキュリティインシデントの兆候を漏れ無く分析する
コスト ・AWSの急激なコスト上昇を把握できていない
・不要なリソースの放置による微細なコスト上昇に気付いていない
・AWSの予算オーバーを請求段階でしか検知できていない
・AWS Cost Anomaly Detectionを組み合わせることで各AWSアカウントの急激なコスト上昇を一元的にキャッチする
・AWS Budgetsを組み合わせることで予算逸脱時に通知を受け取る


このようにAWS Organizationsにおけるマルチアカウント戦略を最大限活用することで、


  • アカウント一元管理 : 複数AWSアカウントの統合管理
  • セキュリティ強化 : 漏れのない完全なるセキュリティポリシー
  • コスト追跡 : AWS組織全体でのコスト最適化


これらを実現し、AWSアカウントを管理する上での多くの課題を網羅的に解決することができます!


まとめ

ここまで「AWS Organizationsによるマルチアカウント戦略」について見てきました。 ご自身が利用されているAWSアカウントの管理状況と比較していただき、改善点など見つかりましたでしょうか? AWS Organizationsやその他のAWSマネージドサービスとの組み合わせを採用し、AWSのベストプラクティスに沿ったAWSアカウント管理を実践しましょう!ご精読いただきありがとうございます。

このアーカイブについて

このページには、2024年9月に書かれた記事が新しい順に公開されています。

前のアーカイブは2024年8月です。

次のアーカイブは2024年10月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。