AWS vs Azure vs GCP スキルテスト：どのクラウドプラットフォームテストを使用すべきか
クラウドプラットフォーム採用の問題
シニア DevOps エンジニアが必要です。素晴らしい候補者が 5 人います。2 人は AWS に精通し、1 人は Azure に強く、1 人は GCP を使用し、1 人はクラウド非依存ですが、運用の深さが浅い。
誰を採用しますか？それは状況によります。しかし、ほとんどのチームはこれを間違えています。特定のプラットフォームに採用してロックイン リスクを作成するか、汎用のプラットフォームを採用して、プラットフォームの知識ギャップが予想より深いことを発見します。
正しい答えは両方を評価することです。プラットフォーム固有の運用知識と、転送可能なシステム思考の両方です。
プラットフォーム固有のスキルをテストする場合
以下の場合、AWS/Azure/GCP の深さをテストします。
- 既存のスタックがそのプラットフォームにロックされている
- 採用のニーズが、そのクラウドの専門知識を深めることである
- 契約または法令遵守要件で特定のクラウドが必要である
以下の場合、クラウド非依存の基礎をテストします。
- マルチクラウドであるか、移行する可能性がある
- ツール習得よりもシステム思考を採用している
- 候補者が複数のプラットフォーム間で働く
ほとんどのチームは両方をテストすべきです。「AWS をうまく運用できるか？」と「プラットフォーム非依存のアーキテクチャについて推論できるか？」の両方です。
AWS 評価フレームワーク
テストするスキル
-
IAM とセキュリティ モデリング
- マイクロサービス アーキテクチャに対して最小権限アクセスを設計できるか？
- SCP と インライン ポリシー と マネージド ポリシーの違いを理解しているか？
- ルート認証情報を使用すべきでない理由を説明できるか？
-
ネットワークと接続性
- VPC 設計：サブネット、ルーティング、NACL、セキュリティ グループ
- Direct Connect と VPN と Internet Gateway をいつ使用するか
- クロスアカウント または クロスリージョン ネットワークのトレードオフ
-
ストレージとデータベース
- EBS 最適化：gp3 対 io2、プロビジョニングされたスループット
- RDS フェイルオーバーとバックアップ戦略
- S3 ライフサイクル ポリシーとデータ保持のためのバージョン管理
-
コンピュート スケーリング
- EC2 Auto Scaling Groups 対 Spot インスタンス
- ECS 対 EKS のトレードオフ
- Lambda コールド スタートが本番環境のワークロードに与える影響
評価質問の例
テイクホーム シナリオ：
「100 個の EC2 インスタンスから 1 日あたり 10GB のログを取り込み、それらを耐久的に保存し、サブ秒のレイテンシーでクエリするシステムを設計してください。予算は 1 ヶ月 $2,000 です。AWS のみです。選択肢を説明してください。」
良い回答は以下を考慮します。
- CloudWatch ログの収集（マネージド）対 Firehose + S3 + Athena（コスト最適化）
- コストを管理するログ保持ポリシー
- インデックス戦略（Athena パーティショニング、または Elasticsearch）
- クエリ パターン、およびサブ秒のレイテンシーが実際か仮定かどうか
弱い回答は、それが必要かどうかを疑わずに Elasticsearch に飛び込みます。
ライブ トラブルシューティング：
「RDS インスタンスが 80% CPU に達し、オートスケーリング ECS タスクが 1 時間ごとに 2 分間データベースに接続できません。常に同じ時間です。これをデバッグする方法を説明してください。」
候補者は以下を考慮すべきです。
- ECS 接続スパイクと RDS ロードの相関付け
- Enhanced Monitoring でスロー クエリを確認
- 接続リークを探す（アプリが接続を閉じていない）
- その時間に何か他が実行されているかどうかを考慮（バックアップ、レポート）
Azure 評価フレームワーク
テストするスキル
-
ID とアクセス（Azure AD / Entra）
- マネージド ID 対 サービス プリンシパル
- カスタム ロールを使用したロールベースのアクセス制御（RBAC）
- セキュリティのための条件付きアクセス ポリシー
-
ネットワークとセキュリティ
- NSG、UDR、ピアリング
- Azure Firewall 対 NVA
- プライベート エンドポイントとサービス エンドポイント
-
ストレージとコンピュート
- マネージド ディスク、Premium SSD、エフェメラル OS ディスク
- App Service 対 Container Instances 対 AKS
- Azure SQL フェイルオーバー グループ 対 読み取りレプリカ
-
可視性
- Application Insights 対 Azure Monitor
- ログ分析クエリ（KQL）
- 診断設定と保持
評価質問の例
テイクホーム シナリオ：
「オンプレミス アプリケーションを Azure に移行しています。アプリは固定 IP が必要で、厳密なコンプライアンス要件があり、他のテナントから分離される必要があります。ネットワークと ID アーキテクチャを設計してください。」
良い回答には以下が含まれます。
- NSG ルール を持つ専用サブネット
- データベース用のプライベート エンドポイント
- アプリ認証のためのマネージド ID
- トラフィック制御のためのネットワーク ポリシー
ライブ会話：
「Azure Web アプリが遅い、しかし Azure Monitor は CPU が正常を示しています。新しいコードをデプロイした後、レイテンシーが増加しました。最初に何をチェックしますか？」
候補者は以下を考えるべきです。
- Application Insights のトレースと依存関係
- App Service プラン CPU 対 アプリレベルのボトルネック
- コードレベルの変更（新しいクエリ、ブロッキング呼び出し）
- データベース接続プーリング
- サードパーティの依存関係のレイテンシー
GCP 評価フレームワーク
テストするスキル
-
IAM と組織階層
- サービス アカウントとキー管理
- カスタム ロールと最小権限
- 組織ポリシーと制約
-
コンピュートとオーケストレーション
- Compute Engine ゾーンとリージョン
- GKE クラスター設計とオートスケーリング
- サーバーレス ワークロード用の Cloud Run
-
データとストレージ
- Cloud Storage バケット、バージョン管理、ライフサイクル
- データウェアハウス用の BigQuery
- Cloud SQL と Cloud Spanner フェイルオーバー
-
可視性（Google Cloud Operations）
- Cloud Logging とログ ルーティング
- Cloud Trace とプロファイリング
- Cloud Monitoring とカスタム メトリクス
評価質問の例
テイクホーム シナリオ：
「Compute Engine で毎日実行されるバッチ処理ジョブがあり、1TB のデータを処理し、2 時間かかります。SLA を維持しながらコストを削減したいです。ソリューションを設計してください。」
良い回答は以下を考慮する可能性があります。
- Preemptible VM（コスト効率的で、バッチに許容可能）
- クエリのための BigQuery（Compute Engine 処理より高速）
- 並列化可能な場合は Cloud Run
- フォールトトレランス ワークロード用の Spot VM
ライブ デバッグ：
「Cloud Run サービスが一部のリクエストでタイムアウトしています。ログはクリーンです。P99 レイテンシーがデプロイ後、50ms から 2s に上がりました。これを追跡してください。」
候補者は以下を考えるべきです。
- どの操作が遅いかを確認するにはトレースをチェック
- 新しい依存関係を調査（データベース、外部 API）
- データベース接続制限をチェック
- メモリ割り当てを確認（Cloud Run にはさらに必要か？）
- コール スタート パターンを探す
クロスプラットフォーム評価（プラットフォーム非依存）
複数のクラウドを使用している候補者について、転送可能なスキルをテストします。
質問：
「AWS と Azure でシステムをアーキテクチャしました。それらの間で転送されるデザイン パターンは何ですか？本質的に何が異なるか？」
良い回答は以下を認めています。
- コア概念（VPC、IAM、マネージド データベース）は似ている
- 実装の詳細は大きく異なる
- コスト モデルは異なる（予約インスタンス対 コミットメント）
- 最初のプラットフォームを理解すれば、各プラットフォームの学習曲線は浅い
これは、彼らが独断的ではなく、クラウド間を移動できることを示しています。
クラウド採用の評価構造
- 30 分のテイクホーム（制約を含むプラットフォーム固有のシナリオ）
- 30 分のライブ トラブルシューティング（専門知識を持つプラットフォームを使用）
- 15 分のアーキテクチャ 会話（プラットフォーム トレードオフを理解しているかテスト）
マルチクラウド 対 プラットフォーム専門家を採用する場合
マルチクラウド汎用者を採用する場合：
- プラットフォーム間で移行している
- ベンダー条件を交渉する柔軟性が必要
- ポータブルなインフラストラクチャ を構築している
プラットフォーム専門家を採用する場合：
- プラットフォーム決定がロックインされている
- そのプラットフォームのエッジケースについての深い運用知識が必要
- 特定のクラウドのコストを最適化している
ほとんどの健全なエンジニアリング組織は両方が必要です。いくつかの深い専門家と、クラウド間で運用できるより多くの汎用者です。
プラットフォーム間で公平な評価を構築する
AWS と Azure の候補者の両方を評価する場合、質問を一貫性を保つように構造化します。各候補者に同じシステムを設計するよう求めてください。ちょうど彼らのプラットフォーム上で。その後、比較します。アーキテクチャは同等のトレードオフ思考を持っていますか？それとも 1 人の候補者が近道を取りましたか？
クラウド採用評価を構築する準備ができましたか？DevOps とクラウド エンジニアリング リソースを探索して、評価結果の解釈方法を確認してください。