AWS Solution Architect Professional 持ちは GCP Associate Cloud Engineer もすぐに取れます！（個人の感想です）
4329 ワード
AWS Solution Architect Professional (SAP) を持っていれば、GCP ほぼ未経験でも GCP Associate Cloud Engineer は知識の流用で何とかなると感じたので、取得までの過程をご紹介します。
もちろん保証はしないし前提もあります
- 「すぐに」≠「ノー勉で」
- Kubernetes の基礎は知っていること
- あくまで「資格を取る」だけの話です
勉強したこと
- まずは、公式ドキュメントから「AWS プロフェッショナルのための Google Cloud」を熟読しましょう
- IAM は個別にドキュメントを確認しておきましょう
- 「概要」と「ベストプラクティス」だけで十分です
- IAM は AWS を知っているがゆえに混乱する部分もあります。まっさらな気持ちで読みましょう
- AWS の Auto Scaling に相当する部分は個別にドキュメントを確認しておきましょう
- その流れでネットワークロードバランサと HTTP(S)ロードバランサは見ておきましょう
- あとは実際に触ることが重要！アカウントを作って、GCPを使えるようにしましょう
- 始め方はググればなんぼでも出てきます。十分な無償枠があります
-
同じことをコンソールでの操作とCLIの両方でやってみましょう
- CLIは、個別のサービスを網羅する必要はありませんが、文型は押さえておきましょう。あと、デフォルトリージョン/ゾーンの設定
- Cloud Shell でコンソールからお手軽にCLIが使えます
- プロジェクトを作って、VPCを作って、サブネットを作って、VMを立てて、ファイアウォールルールを作って、VMにアクセスしてみましょう
- VMへのアクセスの仕方はLinuxとWindows両方を押さえておきましょう
- サードパーティツールではなく、コンソール or CLI 経由でより安全に！
- GKE もクラスタを作って、Deployment 作って、Service 作って、外部に公開くらいのベーシックな操作はやっておきましょう
- IAM も試しに操作してみましょう。深堀りはしなくて大丈夫です。
- 最低、これくらい触っておけば、イメージはつくはず（AWSに慣れ親しんでいる人は）です
- 最後に模擬試験はMUSTでやりましょう
- これだけで何とかなります！（たぶん）
- セキュリティや可用性は AWS の常識と同じ感覚を持ち込めば、大きく外すことはないです
おまけ（個人的に印象に残った AWS との差異をピックアップ）
- ネットワーク
- VPC はグローバルリソース。CIDRは持たない
- AWS ではリージョンリソース。CIDR を付与
- サブネットはリージョンリソース。ゾーンをまたげる
- AWS では AZリソース
- ファイアウォールはVPCに割当。ネットワークアドレス／リソースに「タグ」を付与してタグベースで制御
- AWS では セキュリティグループをリソースに割当、ネットワークアドレス／セキュリティグループを指定して制御
- AWS の「タグ」に相当するのは GCP では「ラベル」
- 外向けのHTTP(S)ロードバランサはグローバルに展開可能
- AWS では、複数リージョンへの負荷分散はDNSベース
- 管理系
- プロジェクト（AWSでいうAWSアカウントに相当）の組織構造において、上位階層でつけた許可ルールは下位階層の権限と和集合で効く（上位階層で許可すると権限がガバガバになる）
- AWS では、Organizations の SCP はフィルタとして機能。AWSアカウントの IAM と積集合で効く（SCP で許可していても IAM で許可されていなければ許可されないし、逆もしかり）
- VM
- スナップショットはグローバルリソース
- AWSではリージョンリソース
- オブジェクトストレージ
- GCS は強整合性
- AWS S3 は結果整合性
- GCS は複数リージョンへの冗長化がバケットのタイプとして選べる。ユーザはどのリージョンに書き込んだか、どのリージョンから読みだしたか意識しない（できない）
- AWS では別リージョンに作った別バケットにクロスリージョンレプリケートを設定。リージョンを意識する
- まずは、公式ドキュメントから「AWS プロフェッショナルのための Google Cloud」を熟読しましょう
- IAM は個別にドキュメントを確認しておきましょう
- 「概要」と「ベストプラクティス」だけで十分です
- IAM は AWS を知っているがゆえに混乱する部分もあります。まっさらな気持ちで読みましょう
- AWS の Auto Scaling に相当する部分は個別にドキュメントを確認しておきましょう
- その流れでネットワークロードバランサと HTTP(S)ロードバランサは見ておきましょう
- あとは実際に触ることが重要！アカウントを作って、GCPを使えるようにしましょう
- 始め方はググればなんぼでも出てきます。十分な無償枠があります
-
同じことをコンソールでの操作とCLIの両方でやってみましょう
- CLIは、個別のサービスを網羅する必要はありませんが、文型は押さえておきましょう。あと、デフォルトリージョン/ゾーンの設定
- Cloud Shell でコンソールからお手軽にCLIが使えます
- プロジェクトを作って、VPCを作って、サブネットを作って、VMを立てて、ファイアウォールルールを作って、VMにアクセスしてみましょう
- VMへのアクセスの仕方はLinuxとWindows両方を押さえておきましょう
- サードパーティツールではなく、コンソール or CLI 経由でより安全に！
- GKE もクラスタを作って、Deployment 作って、Service 作って、外部に公開くらいのベーシックな操作はやっておきましょう
- IAM も試しに操作してみましょう。深堀りはしなくて大丈夫です。
- 最低、これくらい触っておけば、イメージはつくはず（AWSに慣れ親しんでいる人は）です
- 最後に模擬試験はMUSTでやりましょう
- これだけで何とかなります！（たぶん）
- セキュリティや可用性は AWS の常識と同じ感覚を持ち込めば、大きく外すことはないです
おまけ（個人的に印象に残った AWS との差異をピックアップ）
- ネットワーク
- VPC はグローバルリソース。CIDRは持たない
- AWS ではリージョンリソース。CIDR を付与
- サブネットはリージョンリソース。ゾーンをまたげる
- AWS では AZリソース
- ファイアウォールはVPCに割当。ネットワークアドレス／リソースに「タグ」を付与してタグベースで制御
- AWS では セキュリティグループをリソースに割当、ネットワークアドレス／セキュリティグループを指定して制御
- AWS の「タグ」に相当するのは GCP では「ラベル」
- 外向けのHTTP(S)ロードバランサはグローバルに展開可能
- AWS では、複数リージョンへの負荷分散はDNSベース
- 管理系
- プロジェクト（AWSでいうAWSアカウントに相当）の組織構造において、上位階層でつけた許可ルールは下位階層の権限と和集合で効く（上位階層で許可すると権限がガバガバになる）
- AWS では、Organizations の SCP はフィルタとして機能。AWSアカウントの IAM と積集合で効く（SCP で許可していても IAM で許可されていなければ許可されないし、逆もしかり）
- VM
- スナップショットはグローバルリソース
- AWSではリージョンリソース
- オブジェクトストレージ
- GCS は強整合性
- AWS S3 は結果整合性
- GCS は複数リージョンへの冗長化がバケットのタイプとして選べる。ユーザはどのリージョンに書き込んだか、どのリージョンから読みだしたか意識しない（できない）
- AWS では別リージョンに作った別バケットにクロスリージョンレプリケートを設定。リージョンを意識する
- VPC はグローバルリソース。CIDRは持たない
- AWS ではリージョンリソース。CIDR を付与
- サブネットはリージョンリソース。ゾーンをまたげる
- AWS では AZリソース
- ファイアウォールはVPCに割当。ネットワークアドレス／リソースに「タグ」を付与してタグベースで制御
- AWS では セキュリティグループをリソースに割当、ネットワークアドレス／セキュリティグループを指定して制御
- AWS の「タグ」に相当するのは GCP では「ラベル」
- 外向けのHTTP(S)ロードバランサはグローバルに展開可能
- AWS では、複数リージョンへの負荷分散はDNSベース
- プロジェクト（AWSでいうAWSアカウントに相当）の組織構造において、上位階層でつけた許可ルールは下位階層の権限と和集合で効く（上位階層で許可すると権限がガバガバになる）
- AWS では、Organizations の SCP はフィルタとして機能。AWSアカウントの IAM と積集合で効く（SCP で許可していても IAM で許可されていなければ許可されないし、逆もしかり）
- スナップショットはグローバルリソース
- AWSではリージョンリソース
- GCS は強整合性
- AWS S3 は結果整合性
- GCS は複数リージョンへの冗長化がバケットのタイプとして選べる。ユーザはどのリージョンに書き込んだか、どのリージョンから読みだしたか意識しない（できない）
- AWS では別リージョンに作った別バケットにクロスリージョンレプリケートを設定。リージョンを意識する
以上
Author And Source
この問題について(AWS Solution Architect Professional 持ちは GCP Associate Cloud Engineer もすぐに取れます！（個人の感想です）), 我々は、より多くの情報をここで見つけました https://qiita.com/imiky/items/a2ef5187c7e633c0c537著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .