®OTOKO®によるAmazon Web Services（AWS）
成功したAWSのパイロットからは、複数のアカウント、チーム、請求がすぐに生まれます。この環境が貴社とともに成長できるよう、OTOKO®はアカウント、アクセス、ネットワークを整理し、さらなるアプリケーションの移行に伴走します。技術的な判断は、本番稼働の開始後に検討するのではなく、運用工数やコストと結び付けたうえで行います。
私たちが貴社のために担うこと
OTOKO®による計画、実装、合意した運用
イメージ画像（事業者の拠点を撮影したものではありません）OTOKO®へのご依頼内容
次の発展段階では、最初の実験段階とは異なる要件が求められます。本番データには管理されたアクセスが、アプリケーションには信頼できる接続が、そしてチームには共通のデプロイ経路が必要です。アセスメントにより、貴社のAWS環境のどの部分がすでに適しているか、また拡張前にどこを手直しすべきかが明らかになります。
必要に応じて、現状評価から始めるか、範囲を明確にした実装案件から直接着手します。アカウント構造、ネットワーク接続、アプリケーションの移行は、具体的な検収基準に沿って進めます。その後の運用サービスについては、どのコンポーネントをサポートするか、また貴社の開発チームにどの責任が残るかを明記します。
サービスの詳細サービス範囲
統一された基盤があれば、拡張が容易になります。まずアカウント構造を整理するか、アプリケーションを移行するか、あるいは運用を改善するかは、既存の構成と貴社のチームの優先事項によって決まります。
新しいAWSアカウントは、責任者、コストセンター、共通のルールとともに開始すべきです。既存のアカウントを把握し、適切な組織構造に割り当てます。その後のプロビジョニング手順では、さらなるチームをどのように迎え入れるか、また、どのような規定が適用されるかを定めます。
追加のアプリケーションを取り込むための、手順が明確なオンボーディングプロセスを備えたアカウント・ガバナンス設計。
チーム、保護要件、責任分担に応じてアカウントと環境を構成します。AWS Control Towerは、マルチアカウント構成に基づくランディングゾーンを支援できます。導入前に、既存のアカウントと共通ルールの影響を確認します。
アプリケーション、管理業務、オンプレミスのデータセンターの間には、それぞれ異なるデータ経路があります。これらの接続は、必要なアクセス権とあわせて設計し、貴社の環境に設定します。例外事項の文書化と接続テストにより、後の変更やトラブルシューティングが容易になります。
検証済みの接続と文書化された境界を備えたネットワーク・権限設計。
ネットワークセグメント、ルーティング、DNS、管理アクセスをまとめて計画します。データセンターへの接続には、明確なデータ経路と役割分担を設けます。必要な例外は文書化し、誰からも見えない特殊対応として恒久的に運用することはありません。
アプリケーションごとに、サーバー、コンテナ、データサービスのどの組み合わせが適しているかを確認します。依存関係により、移行の順序が決まります。移行先の環境を構築し、データの転送を準備したうえで、各コンポーネントの連携を貴社のアプリケーションチームとともにテストします。
根拠あるワークロードの割り当てと、アプリケーショングループごとの移行計画。
アプリケーションを仮想サーバーまたはコンテナプラットフォームに割り当て、必要なデータ・ストレージコンポーネントを確認します。Amazon EKSは選択肢の一つとなるKubernetesプラットフォームであり、アプリケーションの要件と運用の手間に照らして評価します。移行は、テストを実施し、事前にすり合わせた切り戻し手段を用意したうえで行います。
コストと運用は互いに影響し合います。過剰なサイズのリソースや、常時稼働し続けるテスト環境は、工数と費用の増加を招きます。利用データと運用上の観察結果は、優先順位を付けた変更の根拠となります。その実施内容と効果は、それぞれの担当者とすり合わせます。
優先順位を付けた技術的な施策と役割分担を含む、コスト・運用レポート。
コストのタグ付けとAWS Cost Explorerにより、利用量の配分を支援します。私たちは、この情報をリソースの使用率、モニタリング、変更計画と結び付けます。削減施策と引き受けた運用業務は別途記載し、定期的に見直します。
計画と実装の詳細
本番運用されるAWS環境には、自律的に作業するチームのための共通基盤が必要です。アカウント構成、ネットワーク、プロビジョニング、コスト責任は、同じ組織構造を反映すべきです。これらのテーマを貴社のアプリケーションの具体的なオンボーディングと結び付けます。
パイロットは、多くの場合、時間的な制約の中で、限られた利用者を対象に始まります。しかし、さらにチームが加わると、個人間の取り決めだけでは十分ではなくなります。リソースの割り当て、管理者権限の確認、共通サービスの位置付けが必要になります。そのため棚卸しでは、既存のアカウントを、その背後にあるプロジェクトや担当者と合わせて確認します。これにより、どの構造が意図的に選ばれたのか、どれが暫定的なものにすぎなかったのか、そして本格的な拡張の前に実際に必要な変更は何かが明らかになります。
目標像には、新しいチームをどのように迎え入れるか、既存のアカウントにどのようなルールを適用すべきかを記載します。その際、役割分担、コストセンター、異なる環境の分離を考慮します。導入は、稼働中のアプリケーションや既存の依存関係が引き続き考慮されるよう、すり合わせた段階を踏んで進めます。最初の具体的なユースケースは、新しい手順の検証として機能します。その後、貴社のチームは、プロビジョニング、承認、ドキュメントが、当初のパイロットチーム以外でも分かりやすく機能するかどうかを評価できます。
アプリケーションの移行先環境は、多くの場合、異なる要件を持つ複数のコンポーネントで構成されています。処理性能、データの保持方法、インターフェース、管理者アクセスは、まとめて検討する必要があります。適切な構成を共に比較し、将来の運用負荷も考慮に入れます。ここでは既存のスキルも重要です。ソリューションは、担当するチームが理解し、監視し、変更できるものでなければなりません。そのため、モダナイゼーションの範囲は、安全な移行にまず必要な作業と、意図的に切り分けます。
実施にあたっては、依存関係と検証項目を記録します。アプリケーションチームが業務面での機能を確認する一方、技術的なテストでは、アクセス、接続、合意した運用構成を確認します。オンプレミスのシステムが引き続き必要な場合は、その通信経路も検収の対象に含めます。引き継ぎでは、プロジェクト終了後にどのように変更を反映するか、そのためにどのドキュメントが用意されているかも記載します。こうして、移行の最後に責任の所在を曖昧にすることなく、追加のワークロードをAWS環境に組み込むことができます。
請求額の増加には、新しいアプリケーション、利用方法の変化、過剰なリソース、必要以上に稼働し続けている環境など、様々な原因が考えられます。コストの概要を見るだけでは、どの技術的な変更が有効かは分かりません。そのため、支出を利用状況と役割分担に結び付けます。アプリケーションチームとの対話を通じて、意図的に確保されている余裕と、実際に削減できる無駄な消費がどこにあるかを明確にします。こうして施策は、アプリケーションの文脈から生まれます。
変更を行う前に、想定される影響と必要な検証をすり合わせます。実施後は、実際の利用状況と運用への影響を確認します。技術的に可能な削減がすべてのワークロードに適しているとは限りません。そのためドキュメントには、前提事項と決定内容を記録し、さらなる最適化がそれを踏まえて行えるようにします。継続的なサポートについては、報告経路、保守、役割分担もあわせて定めます。これにより、コストに関する意思決定は、システムに対する実際の責任と結び付いたままになります。
私たちの協働の進め方
貴社が技術的な作業のすべてを自ら手配する必要はありません。私たちが作業内容と決定事項を記録し、貴社のチームの知見や承認が必要な場面には、その都度参加していただきます。
棚卸しにより、アカウント、リソース、担当チームを結び付けます。これにより、共通のルールと変更の順序が定まります。
貴社の役割： プロジェクトの目標、担当者、既存アプリケーションの既知の制約事項をご提示ください。
新しい構造と接続は段階的に構築します。アプリケーションのテストにより、計画した構成が必要な業務プロセスを支えられるかを確認します。
貴社の役割： 対象となるワークロードのテストと承認に、貴社の開発チームを関与させてください。
ドキュメント、運用タスク、コストの割り当てを共に確認します。その後のサポートについては、範囲を明確に定めます。
貴社の役割： 新規アカウント、変更、継続的な支出について、それぞれの責任者を定めてください。
プロジェクトのシナリオ例
共同で進めるプロジェクトの一例です。具体的な範囲は、貴社の現状によって決まります。
最初のプロジェクトは機能していますが、アカウント構造と運用タスクは、まだほかのチームを想定した設計になっていません。
既存のアーキテクチャを検証し、アクセス、プロビジョニング、運用のための基盤を補います。
パイロット環境から、透明性のある形で運用支援されるプラットフォームへと至る、合意済みの道筋。
貴社が得られるもの
アカウント構成と文書化されたセキュリティルールを含むAWSアーキテクチャ
移行、テスト、検収を含む実施計画
役割分担とコスト概要を文書化した運用
関心から、具体的なご依頼へ
初回相談の時点では、これらの資料がすべて揃っている必要はありません。何がすでにあるか、アセスメントでどの情報を補うべきかを、共に明確にします。
サービス範囲、貴社チームの関与、必要なアクセス権、検収基準、引き渡しは、見積もりの中に記載します。事業者の利用料金、プロジェクトの作業内容、稼働中の運用は、それぞれ区別して分かりやすく示します。
アセスメントについて相談する着手前に
はい。アカウント構成、アクセス権、リソース、依存関係を評価し、必要な変更を貴社のチームと共に計画します。
貴社のアプリケーションのための、構成が明確なAWS環境。アーキテクチャ、移行、自動化を支援し、運用とコストの透明性を高めます。
はい。貴社のインターフェース、アイデンティティ、ネットワーク、可用性やデータ保管場所に関する要件をもとに、ハイブリッドアーキテクチャを計画します。
アカウント構成は、責任分担、セキュリティ境界、運用要件に応じて設計します。個別のアカウントは一つの手段ですが、あらゆるチーム構成に対する一律の答えではありません。
はい。引き受けるアカウント、サービス、業務範囲はサービスカタログで明確に定めます。その際、貴社の社内運用とのインターフェースを明示的に合意する必要があります。
OTOKO®によるAmazon Web Services（AWS）
すでに稼働しているアプリケーションと、今後追加したい内容をお聞かせください。最初のお打ち合わせで、アーキテクチャや運用に関する未解決の点を整理し、適切な進め方をご提案します。
Amazon Web Services（AWS）に関する初回相談
