MS_MegaCloudServices - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

メガクラウドサービス

概要

いい感じの比較資料があったので項を追加。

詳細

Azure

AWS

GCP

補足（3 クラウドの主要サービスの対応表）: 名称が違うだけで
役割は概ね対応する。移行や比較検討の際の見取り図として挙げておく。

分野 Azure AWS GCP
仮想マシン Azureの仮想マシン EC2 Compute Engine
オブジェクト ストレージ Blob Storage S3 Cloud Storage
ブロック ストレージ マネージド ディスク EBS Persistent Disk
仮想ネットワーク VNET VPC VPC
負荷分散 Load Balancer / App Gateway ELB（ALB/NLB） Cloud Load Balancing
RDBMS（PaaS） Azure SQL Database RDS / Aurora Cloud SQL
NoSQL Cosmos DB DynamoDB Firestore / Bigtable
FaaS Azure Functions Lambda Cloud Functions
Kubernetes AKS EKS GKE
ID 基盤 Microsoft Entra ID IAM Cloud IAM
監視 Azure Monitor CloudWatch Cloud Monitoring
専用線 ExpressRoute Direct Connect Cloud Interconnect

ただし、「対応する」＝「同じように使える」ではない。
後掲の「つまずきポイント」が示すとおり、
細部の仕様の違いが設計判断を変える。
特にAzureの仮想マシンで述べた
「AZ をミニリージョンとして使用しない」（AWS ではサブネットが
AZ に固定されるが Azure では固定されない）は、
同じ設計を持ち込むと破綻する典型例である。

参考

Qiita

知って安心！AWS・Azureのつまずきポイント

http://itpro.nikkeibp.co.jp/atcl/column/16/041400085/

  • なんとなく、

    • NW 系
    • 課金系
      • 従量課金の基礎知識
      • 価格やライセンス規約の改定

    が多い気がする。

  • あとは、

    • 仮想化系技術の一般的な話。
    • その他のソフトウェア個別の仕様の話。

補足（この分類が本ページで最も有用）: 「NW 系と課金系が多い」という
観察は的確で、クラウド特有のつまずきの構造を言い当てている。

なぜこの 2 つに偏るのか。

分野 偏る理由
NW 系 オンプレの常識が通用しない。SDN であり、ブロードキャストが通らない、IP は基盤が管理する、経路が暗黙に存在する
課金系 「作ったら課金される」という感覚が無い。止めても課金される、規約が改定される
仮想化系 オンプレの仮想化と同じ問題（一時ディスク、スナップショット）

つまり、技術的に難しいから躓くのではなく、
「前提が違うことに気付かない」から躓く。

以下に挙げられている個別事例も、ほぼすべてが
**「オンプレならこうだったのに」**という形をしている。
逆に言えば、前提の違いを事前に把握しておけば防げるものが多い。

なお、この連載は 2016〜2017 年のものであり、
既に解消された事例も含まれる（後述の各項で補足する）。

AWS

補足（AWS の事例のうち、Azure でも同じもの）: 列挙された事例の多くは
AWS 固有ではなく、クラウド共通の性質である。

AWS の事例 Azure での対応する話
停止/起動でデータが消える（インスタンス ストア） 一時ディスク（D:）（Azureの仮想マシン）
IP アドレスが勝手に変わる 動的 IP（Azureの仮想マシンの「IP 固定」）
VM 停止で固定 IP に課金 静的パブリック IP の保持課金（Azureの課金）
誰でも S3 へアクセス可能に ストレージのパブリック アクセス（AzureのPoC環境を契約する）
リージョン跨ぎで遅延・課金 下り転送（egress）課金（Azureの課金）
共有ディスクを作れない Azure 共有ディスク／Azure Files（Azureの高可用性設計）

本文が既に「Azure の場合」と併記している箇所が複数あるとおり、
著者もこの共通性を意識している。
1 つのクラウドで学んだ失敗は、他でも役に立つということでもある。

なお、最新化として、

事例 現在
誰でも S3 へアクセス可能に 2023 年以降、新規バケットは既定でパブリック アクセス ブロック
EBS で共有ディスクを作れない EBS マルチアタッチが提供された（io1/io2）
AMI 作成で再起動する 既定で再起動なしに変更済み

といった改善がある。

Azure

補足（Azure の事例の最新化）: 記事は 2016 年のもので、
多くは既に解消または改善されている。

事例 現在
VM が意図せず再起動される 現在も計画メンテナンスは発生するが、メモリ保持更新で再起動を伴わないものが増えた（Azureの高可用性設計）
NIC の情報が蓄積される 解消済み
VM サイズを変更できない 現在も存在する制約。割り当て解除すれば変更できる（Azureの評価環境を入手する）
NIC の枚数制限 現在も存在（VM サイズ依存）
VM を VNET に後から移せない 現在も仕様。作成時に決める
強制トンネリング 現在も同じ（Azureのアウトバウンド設計）
SQL DW Azure Synapse Analytics に発展（さらに Microsoft Fabric へ）

つまり、「解消されたもの」と「今も仕様として残るもの」が
混在している。

今も残るものは、いずれも
**「作成時に決めたら変えられない」**という性質のもので、
Azureのサブネッティングの
「VNET のアドレス空間は後から縮小できない」と同じ構造である。
設計の初期に決める項目として意識しておく必要がある。

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️