クラウド管理画面比較

  • このエントリーをはてなブックマークに追加

クラウドサービスの管理画面、AWS マネジメントコンソール・Azure Portal・Google Cloud Console について様々な観点から比較します。

クラウドサービスの管理画面まとめ

AWS・Azure・GCP それぞれの管理画面の名称は下記のとおりです。

  • AWS マネジメントコンソール
  • Azure Portal
  • Google Cloud Console

管理画面比較表

AWSAzureGCP
リージョンリージョンごと全体全体
全リソース一覧表示××(たぶん)
ダッシュボード×○ カスタマイズ充実
ブラウザ上でのシェル△ (Cloud9)○ (Cloud Shell)◎ (Cloud Shell)
日本語対応
コマンド表示××
メニュー (2018/1調べ)× 98個。多すぎ× 214個。多すぎ!○ 35個。適度
多要素認証 (MFA)
管理画面 IP アドレス制限×
インスタンス管理方法アカウントごとアカウント・サブスクリプション紐付けアカウント・プロジェクト紐付け
請求単位アカウントごとディレクトリごと?プロジェクトごと
他者への移管??
スマホアプリ○ iOS/Android○ iOS/Android○ iOS/Android

「リージョン」について [name region]

AWSAzureGCP
リージョンリージョンごと全体全体

AWS の場合、画面右上に 

というリージョン選択プルダウンがあり、そこで

  • 米国東部 (バージニア北部)
  • 米国東部 (オハイオ)
  • アジアパシフィック (シンガポール)
  • アジアパシフィック (東京)

などと選択するようになっています。これは逆に言うと、 さまざまなリージョンにある EC2 などのインスタンスを一覧化して見ることができない、 ということです。新機能など、東京リージョンではまだ使うことができず、 「米国東部 (バージニア北部)」を使わざるをえない場合があります。 よって、インスタンスの落とし忘れがあるかどうか いちいちリージョンを変更して確認する必要があるため大変不便です。

Azure・GCP ではリージョン選択という概念がないため、 どこのリージョンであっても使っているリソースを簡単に把握できます。 ただし、インスタンス作成の際に、例えば GCP であれば毎回 “asia-northeast1” (東京) を間違えずに選択しなければならないというのは注意が必要です。

「全リソース一覧表示」について

AWSAzureGCP
全リソース一覧表示××(たぶん)

使用しているインスタンスやリソースの一覧を表示できるのは Azure のみです。 これはかなり便利な機能です。 情報はたくさん出てきますが、種類 (VM やストレージなど) やリージョン・サブスクリプションなどで 絞り込みやソートができます。 ただ、セキュリティグループ・ネットワークインタフェース・ディスクなど、 普段あまり触らないものも出てきてしまうので若干ウザいですが。

AWS・GCP では、このような機能はありません。 落とし忘れによる課金が怖いので改善希望。

なお、GCP ではホーム画面に下記のような「リソース」表示の機能がありますが、 これは「全リソース」ではなく、「主要なリソース」のようです。例えば「GCE のディスク」は、ここには表示されません。

「ダッシュボード」について

AWSAzureGCP
ダッシュボード×○ カスタマイズ充実

ダッシュボードとは、インスタンスの状況や、各種グラフ等をひとまとめにして、 視覚的にわかりやすくしたものです。

AWS マネジメントコンソールには、ダッシュボードがないようです。

Azure にはダッシュボードがあり、かなり柔軟なカスタマイズができます。 リソースグループからたどると CPU 使用率やネットワーク転送量・リクエスト数・レスポンスタイムなど、 かなり充実したグラフを追加できます。 また、新しいダッシュボードを新規作成したり、他ユーザと共有もできます。

GCP にはダッシュボードはありますが、カスタマイズはあまりできないようです。

「ブラウザ上でのシェル」について

AWSAzureGCP
ブラウザ上でのシェル△ (Cloud9)○ (Cloud Shell)◎ (Cloud Shell)

まず GCP から。GCP には「Cloud Shell」という機能があります。 これはブラウザ上でシェルが実行可能なものです。 より正確に言うと、「作業用の Google Compute Engine インスタンス + ブラウザ上で動く端末エミュレータ」です。 これは大変素晴らしいもなので、ぜひ一度使ってみてください。特徴は下記です。

  • ブラウザ上で動作するのでインストール不要
  • OS は Debian
  • ホームディレクトリ以下 5GB は永続ディスク
  • Python・Java・Go・Node.js・Docker・Git・Emacs・vi 等々、いろいろインストール済
  • gcloud 等の管理用コマンドもすぐに使える
  • sudo で root 権限獲得可能なのでパッケージ追加インストールも可能
  • 外部ネットワークつながるので、外部への http も ssh も通る。
  • インスタンスもディスクも無料!
  • 残念ながら cron は使えない (2015年頃の利用者のブログを見ると初期は使えた模様だが、2018/1 現在では cron デーモンがいない)

GCP Cloud Console にログインした後、右上にあるアイコンの「>_」とある部分をクリックで起動します。 

初回起動時はしばらく時間がかかりますが、少し待つと下記のようにシェルが実行可能になります。 

例えば gcloud compute instances list とタイプすれば、GCE のインスタンス一覧を取得できます。 Cloud Shell 起動時に認証済なので、すぐに GCP の各種情報にアクセス可能です。

$ gcloud compute instances list
NAME        ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP     STATUS
instance-1  us-east1-b  n1-standard-1               10.142.0.2   35.196.125.125  RUNNING

ブラウザ上での動作なので、Ctrl-n で新規ウィンドウが開いたり、Ctrl-w でタブが閉じたり、 といった点はイライラします。その場合、Chrome の拡張機能 SSH for Google Cloud Platform をインストールすることで解消します。 それでも Ctrl-V などがコピペに食われてしまうのですが、Cloud Shell の設定で Shift-Ctrl-C でコピー・Shift-Ctrl-V でペーストとすることができます。

簡単な調査やインスタンス設定変更・MySQL など DB からのデータ取得等であれば、 Cloud Shell で作業し、Perl なり Ruby なり aws なりで加工し、 ファイルを手元の PC にダウンロードします。

これは一度体験してほしいです。おすすめです。 GCP の Cloud Shell の説明おわり。

Azure の場合、Cloud Shell という機能があります。 GCP と名前が思い切りかぶっていますが、たまたまです (多分)。 以下、Google Cloud Shell との違いを書きます。

  • OS は Ubuntu (2018/1 確認では 16.04.3 LTS)
  • root になれない
  • VM インスタンス分は無料だが、ディスクは有料 (Azure Storage)
  • タブ機能がないので、実質 1つ分のシェルしか使えない
  • bash だけではなく、PowerShell もある (2018/1 現在プレビュー)
  • Ctrl-n で新タブが開くのはいいとして、Ctrl-w で Azure Portal ごと即閉じてしまうのはかなり厳しい

AWS の場合、2017/12 に Cloud9 がリリースされ、Cloud Shell 相当の機能があるようですが、 インスタンスもストレージも有償なんですよねぇ。

「日本語対応」について

AWSAzureGCP
日本語対応

AWS・Azure・GCP とも、管理画面は日本語対応されています。 新機能などは若干対応が遅れることはありますが、主要機能にいてはおおむね問題ないでしょう。

余談ですが、AWS マネジメントコンソールは 2014/8 に日本語化されたものの、 問題があったのかすぐに切り戻しとなり、2015/4 に再度日本語化されました。 中の人はさぞかし苦労されたことでしょう。

「コマンド表示」について

AWSAzureGCP
コマンド表示××

GCP の場合、一部の操作、例えば VM インスタンス作成を管理画面で行おうとすると、 実行の直前に「同等の REST またはコマンドライン」というリンクが出てきます。 「REST」をクリックすると、

POST https://clients6.google.com/compute/v1/projects/my-gcp-test-190315/zones/us-east1-b/instances
{
  "name": "instance-2",
  "zone": "projects/my-gcp-test-190399/zones/us-east1-b",
  "minCpuPlatform": "Automatic",
  (略)
}

と REST のリクエスト内容が表示されます。

「コマンドライン」をクリックすると、下記のようにコマンド行が表示されます。

gcloud beta compute --project "my-gcp-test-190399" instances create "instance-2"  (略) --boot-disk-device-name "instance-2"

ただ、2018/1 現在では Compute Engine などでは REST・コマンドライン表示はあるものの、 例えば Pub/Sub にはそれがなく、まだ道半ばのように感じます。

「メニュー」について

AWSAzureGCP
メニュー (2018/1調べ)× 98個。多すぎ× 214個。多すぎ!○ 35個。適度

AWS マネジメントコンソール左上のサービスをクリックすると、 右画像のようにメニューが展開されます。右側のスクロールバーを見ると、 ここで表示されている分でおおむね 60% くらいでしょうか。 2018/1 調査で 98個でした。

Azure のメニューはこれ (右画像) です。 左側の列に主要なメニューが表示されているのですが、 一番下にある「その他のサービス」を選択すると、右側に全メニューが展開されます。 スクロールバーの長さを見ると絶望を感じますね。 2018/1 調査でまさかの 214個でした。

フォームから検索できるのですが、これが使いづらい。 「storage」と入力しても何も出てこない! 「ストレージ」と入力すると「ストレージアカウント」だけが出て来る。 ここに Blob Storage や Queue Storage が出ればわかりやすいと思うんですが、出ない (これはサービス階層の設計の問題かもしれませんが、Blob Storage を探している人に一旦ストレージアカウントをクリックさせるのはいまいちです)。 また、「MySQL」と入力すると「MySQL databases」「MySQL database Clusters」 「MySQL サーバー向けの Azure データベース」が出てくるが、最初の 2つは Marketplace のもの。

GCP のメニューはこれ (右画像)。スクロールバーの短さには涙がでます。 メニューの数は 2018/1 調査で 35個でした。

たかがメニューではあるのですが、 突き詰めて考えるとメニューの数はサービスラインナップの理解度と反比例すると思います。 例えば低頻度アクセスのストレージを発表する際、S3 の機能追加とするか、Glacier という新サービス名を与えるか。 新サービスとした方が利用者への受けはいいんでしょうが、 どんどんサービスを増やすと後から学習し始める人は本当に大変です。

「多要素認証 (MFA)」について

AWSAzureGCP
多要素認証 (MFA)

多要素認証 (MFA: Multi-Factor Authentication) とは、ID/Passowrd だけではなく、 スマホアプリやハードウェアのパスワード生成機を使ったワンタイムパスワードを入力させ、 それが合致すると認証 OK とすることを指します。

スマホアプリであれば GoogleAuthenticator などの無料アプリ。 ハードウェアのパスワード生成機であれば例えば 三井住友銀行サイト にあるようなキーホルダー型の機械。

あるいは、入力されたメールアドレスや電話番号宛にメールや SMS で数字を送信し、 それを入力させる方法もあります。あるいは電話番号に自動的に電話をかけ、 システムが読み上げた番号を入力させることもあります。 なお、多要素認証は、二要素認証や二段階認証と呼ぶこともあります。

AWS では、AWS アカウントに対して MFA を有効化することができます。 キーホルダー型の機械や、クレジットカードのような機械も購入できるようですが、 簡単なのはスマホに Google Authenticator アプリをインストールすることでしょう。

Azure では、パスワード変更の画面に遷移する際、 「スマホに Microsoft Authenticator を入れませんか?」と言われたので、 そこで指示に従っておけば MFA が有効になったのではないかと思われます。 また、Azure AD 管理している場合は、管理者にて MFA を有効化できた気がします。

GCP では、G Suite アカウントや Google アカウントにて MFA が有効化できます。 Google アカウントであれば各ユーザそれぞれが MFA を有効化する必要がりますが、 G Suite であれば管理者にて一括して MFA 必須とできるのではないかと思います。

「管理画面 IP アドレス制限」について

AWSAzureGCP
管理画面 IP アドレス制限×

AWS の場合、AWS マネジメントコンソールのログイン自体はコントロールできませんが、 ログイン後の権限について特定 IP アドレス以外は全操作を禁止するような IAM 設定を行うことで、 AWS マネジメントコンソールでの情報表示すらできなくなります。 ただ、一部サービス (CloudFormation だけ?) もこの制限に引っかかるそうです。 [AWS]マネージメントコンソールにIP制限をしつつ、一部利用できない機能も利用できるようにする という工夫もあるようですが、もっと簡単にできるようにしてよ感はありますね。

Azure の場合、Azure Active Directory Premium 契約をしていればできる? ようです。Azure Active Directory Premium は月あたり、612円/ユーザー とのこと。

GCP の場合、現時点ではできない、とどこかで聞きました。

「管理方法」について

AWSAzureGCP
インスタンス管理方法アカウントごとアカウント・サブスクリプション紐付けアカウント・プロジェクト紐付け

AWS の場合、最初に作るアカウントを「AWS アカウント」と呼びます。 そしてその下に仮想マシンなどのインスタンスを作成します。 シンプルでいいんですが、本番と開発環境をアカウントで分けたり、 SIer として複数プロジェクトに関わっている場合、ログインしなおしの必要が出てきます (と思うんだけどあってるだろうか)。

Azure と GCP の場合、もう一段レイヤがあります。 Azure は「ディレクトリ」、GCP は「プロジェクト」です。 Azure では、仮想マシンなどのインスタンスは「ディレクトリ」の下にぶらさがります。 GCP では、仮想マシンなどのインスタンスは「プロジェクト」の下にぶらさがります。 あるアカウントが複数のディレクトリやプロジェクトに参加することができますので、 ログインしなおす必要はありません。

AWS の場合、最初に作った AWS アカウントは何でもできます。 この AWS アカウントの ID/Password を複数人で利用すれば、一応は共同管理が実現できます。

Azure の場合、さらに「サブスクリプション」という概念があり、 請求はサブスクリプション単位で行われます。 また、共同管理者の設定もサブスクリプション単位です。 (と思っているが、間違っているかもしれない)

「請求」について

AWSAzureGCP
請求単位アカウントごとディレクトリごと?プロジェクトごと

AWS の場合、AWS アカウント単位での請求となります。 AWS アカウントの一部を別請求とすることはできません。 しかし、AWS Organizations の機能で複数 AWS アカウントの請求をひとつにまとめることはできます。

Azure は複雑すぎてよくわからない…。

GCP の場合、請求はプロジェクト単位で行われます。 共同管理者の設定もプロジェクト単位です。

  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

Leave a Reply

*

CAPTCHA