メニュー
  1. トップページ
  2. エンジニア実務・仕事術
  3. 【AWS/Azure】ハイブリッドクラウドネットワーク設計書の書き方｜CIDR・専用線

【AWS/Azure】ハイブリッドクラウドネットワーク設計書の書き方｜CIDR・専用線

エンジニア実務・仕事術
【上流】現場リーダーの勘所

もっち

大手SIerに18年勤務。オンプレ・クラウド計200台規模の大規模インフラ（10システム）を統括する現役のサービスマネージャーです。

レベル別記事一覧

【入門】未経験者の第一歩 【突破】作業者からの脱却 【技術】頼れる実務のプロへ 【上流】現場リーダーの勘所

▼▼▼まずはここからチェック！

あわせて読みたい
【必読ガイド】おすすめ記事：スキル別ロードマップ 私は現在、大手SIerで18年間、インフラエンジニアおよびサービスマネージャーとして、止まることが許されない200台規模のシステムを支えています。 このブログでは、私...

「オンプレミスの社内ネットワーク設計書と同じフォーマットでAWSやAzureの基本設計書を書こうとしたら、クラウド特有の仕様が抜け落ちていてレビューで突き返された……」

「Direct Connect（専用線）を冗長化したのに、切り替えテストで非対称ルーティングが発生してFWで通信が全滅した……」

「サブネットを細かく切りすぎて、クラウド事業者の予約IP仕様でアドレスが枯渇してしまった……」

オンプレミスインフラからパブリッククラウドへの移行プロジェクトにおいて、最も設計上のトラブルや手戻りが多発するのが「ハイブリッドクラウドのネットワーク設計」です。

クラウドは物理ケーブルの結線こそありませんが、「L2ブロードキャストが存在しないSDN（Software Defined Network）の世界」「動的ルーティング（BGP）による経路制御」「厳密なクラウド側クォータ（上限値）」など、オンプレミスとは全く異なるルールで動いています。

[実務現場のヒヤリハットメモ] 18年以上の現場経験の中でも、ハイブリッド接続のカットオーバーは最も緊張する瞬間のひとつです。

過去の大規模移行プロジェクトで、オンプレミス感覚で /28 のサブネットを設計した結果、AWS側の予約IP（各サブネット先頭4個＋末尾1個＝計5個）によって利用可能IPが想定より激減し、本番サーバのスケールアウト時にIPが枯渇しかけた現場を目の当たりにしました。

クラウドの設計書は、物理の制約から解放される一方で、「クラウド固有のアーキテクチャ制約」を正確に落とし込む必要があります。

本記事では、AWS（VPC/Transit Gateway/Direct Connect）およびAzure（VNet/Virtual WAN/ExpressRoute）を対象に、オンプレミスとクラウドを安全・確実に相互接続し、手戻りなく開通させるための「ハイブリッドクラウドネットワーク設計書」の実務作成手順を徹底解説します。

この記事の想定読者

  • クラウド特有のNW設計書作成に悩むオンプレインフラエンジニア
  • 専用線接続やBGPルーティングのパラメータ設計を担う現場リーダー
  • CIDR枯渇や非対称ルーティング事故を未然に防ぎたいアーキテクト

この記事を読むことでのメリット

  • オンプレミスとクラウドリソースの正確な対応関係と設計作法が掴める
  • クラウド予約IPを考慮した破綻しない階層型CIDR設計ができる
  • BGP属性を正しく定義し専用線冗長化時の通信断事故を防止できる

ハイブリッドクラウド接続設計書は、基本設計から詳細設計へと落とし込むネットワーク設計全体の重要ドキュメントです。

構成図から各種パラメータシート、試験仕様書まで、インフラ設計書全体の目次構成や作成フローを把握したい方は、まず以下の親記事をご覧ください。

あわせて読みたい
【完全体系図】ネットワーク設計書の書き方と必須項目一覧｜目次サンプル付 「案件でネットワーク設計書を書くことになったが、何から手をつければいいかわからない」「前任者が残したドキュメントがバラバラで、標準的なフォーマットや作成項目…
目次

【結論】ハイブリッドネットワーク設計書で押さえるべき4大鉄則

オンプレミスとクラウドを跨ぐネットワークを設計する際、現場で絶対に外してはならない大原則は以下の4点です。

  • ① オンプレと絶対に重複させない「広域階層型CIDR設計」
    第2・第3オクテットで拠点・クラウド・環境（本番/検証）を厳密に分離し、将来のマルチアカウント・マルチリージョン拡張に耐えうるアドレスプールを事前確保する。
  • ② クラウド事業者の「予約IP（AWS:5個 / Azure:5個）」を前提に計算する
    オンプレの感覚（ネットワークアドレスとブロードキャストアドレスの2個引き）を捨て、サブネットサイズは最小でも /27 または /26 を基本とする。
  • ③ Transit Gateway / Virtual WANを中心とした「ハブ＆スポーク型ルーティング分離」
    全VPCをメッシュ接続するのではなく、集約ルータ（TGW/vWAN）を介して本番環境・検証環境・共有サービス間のルートテーブルを論理的に完全分離する。
  • ④ 専用線冗長化時の「インバウンド／アウトバウンド非対称ルーティング」を防止する
    行き（オンプレ ➔ クラウド）はLocal Preference、戻り（クラウド ➔ オンプレ）はAS-Path PrependingやMEDを用いて優先度を一致させ、オンプレ側FWでのパケット破棄を完全に防ぐ。

なぜハイブリッド接続設計は破綻するのか？オンプレとクラウドの4大ギャップ

クラウド移行のネットワーク設計で手戻りが発生する最大の理由は、「オンプレミスの常識がクラウドでは通用しない」ことにあります。

設計書を起こす前に、必ず押さえておくべき4大ギャップを整理します。

物理L2（ブロードキャストドメイン）が存在しない世界

オンプレミスのネットワーク設計では、スイッチ上でVLANを切り、同一VLAN内であればARPブロードキャストやGARP、VRRP/HSRPによる冗長化が当たり前に機能していました。

しかし、AWS VPCやAzure VNetの内部は、物理ネットワークの上に仮想化オーバーレイ（SDN）が敷かれています。

ブロードキャスト通信やマルチキャスト通信は原則として破棄され、ARPスプーフィングやVIP（仮想IP）のGratuitous ARPによるフェイルオーバーは動作しません。

設計書に「同一セグメントでのL2延伸」や「VRRPによるVIP切り替え」を安易に盛り込むと、実装フェーズで100%破綻します。

クラウドアグリゲーションにおいては、ロードバランサー（ALB/NLB等）やルートテーブル切り替えAPIを用いた「L3ベースの設計」へ思考を完全にシフトさせる必要があります。

クラウド特有の「予約IP」によるアドレス枯渇

オンプレミスでは、サブネット内の使用不可IPは「ネットワークアドレス（先頭）」と「ブロードキャストアドレス（末尾）」の2個だけでした。

一方、主要パブリッククラウドでは、管理用・基盤サービス用に各サブネットあたり先頭・末尾から計5個のIPが予約されています。

IPアドレスの位置AWS VPCの予約用途Azure VNetの予約用途
先頭（.0）ネットワークアドレスネットワークアドレス
2番目（.1）VPCルータ用デフォルトゲートウェイ用
3番目（.2）AWS DNS用Azure DNS用
4番目（.3）将来の利用のために予約将来の利用のために予約
末尾（.255等）ブロードキャストアドレス（予約）ブロードキャストアドレス

たとえば、少数のサーバ用に /28（合計16個）のサブネットを切ると、利用可能なホストIPは 16−5=11 個しか残りません。冗長化構成や将来のオートスケーリング、マネージドサービス（Private Endpoint等）を配置した瞬間にIPが枯渇します。

設計書のアドレッシング規約には、「サブネットの最小サイズは /27（利用可能27個）または /26（利用可能59個）とする」といった安全係数を組み込むことが鉄則です。

クラウド側の上限値とBGP経路数制限

クラウドには、基盤の安定性を担保するための「サービス上限値」が存在します。特に専用線接続におけるBGP経路数の上限は見落としがちです。

  • AWS Direct Connect (Transit VIF)
    アタッチされたDirect Connect GatewayからアドバタイズできるBGPルート数の上限は最大100プレフィックス。
  • AWS ルートテーブル
    1つのVPCルートテーブルに登録できるルート数はデフォルトで50ルート（緩和申請で最大100ルート）。
  • Azure ExpressRoute Gateway
    ゲートウェイSKUごとに学習可能な最大ルート数が厳密に制限（標準ゲートウェイで最大4,000ルート、ルート数超過時はBGPセッションが切断）。

オンプレミス側のL3スイッチが社内LANの細かなサブネット（/24など）をそのままクラウドへ広報してしまうと、上限を超過した瞬間にBGPセッションが切断されるか、一部の経路が受信拒否されます。

設計書には「オンプレミス側エッジルータで必ず広報ルートを集約する」要件を明記しなければなりません。

オンプレミス設計書とクラウドリソースの対比マッピング

オンプレミス専門のエンジニアや社内SEとクラウドアーキテクトが設計レビューを行う際、用語の認識齟齬がトラブルの火種になります。

まずは、オンプレミスの構成要素がクラウド上でどのリソースに対応するのかを正確に対比させます。

オンプレミス概念 ➔ AWS / Azureリソース対照表

オンプレミス構成要素物理・論理の役割AWSリソースAzureリソース設計書での記載ポイント
データセンター / 拠点物理的な立地・境界リージョン / VPCリージョン / VNet地理的冗長性、遅延要件
フロア / サーバルーム物理的な電源・空調の独立区画Availability Zone (AZ)Availability Zone (AZ)マルチAZ設計による可用性担保
VLAN / セグメントL2ブロードキャスト境界Subnet (AZ固有)Subnet (VNet全体)AWSはSubnetがAZに閉じる点に注意
コアルータ / VRFL3ルーティング・論理分離Transit Gateway (TGW)Virtual WAN / Virtual Network Gatewayハブ＆スポーク経路集約
スイッチポート / NIC物理インターフェースENI (Elastic Network Interface)仮想ネットワークインターフェース (NIC)プライベートIPの固定化要否
ルータのルーティングテーブルパケットの転送先定義Route TableRoute Table (UDR: ユーザー定義ルート)デフォルトルート (0.0.0.0/0) の向き先
ステートレスACL (L3スイッチ)パケットフィルタリングネットワークACL (NACL)該当なし (NSGでステートフル制御)サブネット単位の通信制御境界
ファイアウォール (FW)アプリ・ポート単位の制御セキュリティグループ (SG)ネットワークセキュリティグループ (NSG)ENI/NIC単位のステートフル制御
専用線 / WAN引込キャリア閉域網接続AWS Direct Connect (DX)Azure ExpressRoute (ER)物理帯域、BGPピアリング

ハイブリッド構成における責任共有境界のドキュメント化

ハイブリッドクラウドの設計書では、「どこからどこまでが通信キャリアの責任で、どこからが自社の運用責任か」の責任分界点を明確に図示する必要があります。

設計書の「基本方針」セクションには、上記の物理終端位置、VLANタグの付与位置、BGPピアのアドレス割り当て位置を明記した「責任分界点マップ」を必ず掲載します。

破綻しない「ハイブリッドCIDR・サブネット設計書」の書き方

ハイブリッドクラウド環境において、後から最も変更が効かないのがIPアドレス空間（CIDR）の設計です。

VPCやVNetのアドレス範囲を一度作成すると、後から変更するには大規模なリソース再構築とサービス停止が必要になります。

オンプレミスと連携する全体IPアドレッシング規則

プライベートIPアドレス空間（RFC 1918：10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）の中から、オンプレミスとクラウドで完全に重複しないアドレスブロックを切り出します。

推奨されるのは、「第2オクテットで拠点・環境を分け、第3オクテットで役割を分ける」階層化設計です。

このように大枠のブロックをあらかじめ予約しておくことで、ルータやFWのルーティングテーブルに 10.100.0.0/16 の1行を追加するだけで、クラウド上の全本番VPCへの通信を集約（サマライズ）できるようになります。

サブネットの役割別3層分離設計

1つのVPC/VNet内では、セキュリティ要件とインターネット到達性に応じてサブネットを3層に分離します。

  1. Public Subnet（外向け境界）
    • インターネットゲートウェイ（IGW）への直接ルートを持つ。
    • 配置リソース：NAT Gateway、インターネット向けALB。
    • ※直接EC2や仮想マシンを配置することはセキュリティ上原則禁止。
  2. Private Subnet（業務システム層）
    • インターネットへの直接のインバウンド／アウトバウンドルートを持たない。
    • 外への通信はPublic SubnetのNAT Gatewayを経由する。
    • 配置リソース：Web/Appサーバ、コンテナクラスタ（ECS/EKS/AKS）、RDS/データベース。
  3. Isolated / Attachment Subnet（接続専用層）
    • NAT GatewayやIGWへのルートを一切持たず、VPC内またはTGW経由の閉域通信のみを許可する。
    • 配置リソース：Transit Gatewayアタッチメント用ENI、専用ファイアウォールエンドポイント、DB専用サブネット。

【実務サンプル】VPC・サブネットパラメータシート

設計書にそのまま貼り付けて使用できるパラメータ定義表の形式です。

ネットワーク名CIDRAZサブネット名役割・用途利用可能IP関連ルートテーブル
vpc-prod-tokyo10.100.0.0/20––本番業務VPC––
└ Subnet-Pub-1a10.100.0.0/24ap-northeast-1asnet-prod-pub-1aNAT-GW / ALB251rtb-prod-public
└ Subnet-Pub-1c10.100.1.0/24ap-northeast-1csnet-prod-pub-1cNAT-GW / ALB251rtb-prod-public
└ Subnet-Pri-1a10.100.2.0/23ap-northeast-1asnet-prod-app-1aApp / Container507rtb-prod-private-1a
└ Subnet-Pri-1c10.100.4.0/23ap-northeast-1csnet-prod-app-1cApp / Container507rtb-prod-private-1c
└ Subnet-DB-1a10.100.6.0/24ap-northeast-1asnet-prod-db-1aRDS Aurora251rtb-prod-isolated
└ Subnet-DB-1c10.100.7.0/24ap-northeast-1csnet-prod-db-1cRDS Aurora251rtb-prod-isolated
└ Subnet-TGW-1a10.100.15.0/28ap-northeast-1asnet-prod-tgw-1aTGWアタッチメント11rtb-prod-isolated
└ Subnet-TGW-1c10.100.15.16/28ap-northeast-1csnet-prod-tgw-1cTGWアタッチメント11rtb-prod-isolated

💡 ポイント: TGWアタッチメント用サブネットはENIが1つ配置されるだけなので、/28（利用可能11個）で十分です。貴重なアドレスを無駄遣いしないようメリハリをつけます。

Transit Gateway（TGW）設計とルートテーブル定義書の書き方

オンプレミスと複数のVPC/VNetを相互接続する場合、AWSではAWS Transit Gateway（TGW）、AzureではAzure Virtual WAN（vWAN）を中央ハブとする「ハブ＆スポーク型」を採用するのが業界標準です。

ハブ＆スポーク構造におけるルートテーブル分離設計

すべての通信を1つの巨大なルートテーブルに放り込むと、「検証環境から本番環境のDBへ意図せずパケットが届いてしまう」といった重大な事故が起きます。

TGW内では、用途ごとにルートテーブルを分離して定義します。

ルート伝播と静的ルートの使い分け

TGWのルーティング定義書では、経路の学習方式を明確に区別して記載します。

  • 関連付け（Association）
    そのアタッチメント（VPCや専用線）からTGWに入ってきたパケットが、「どのルートテーブルを参照してルーティングされるか」を決定する（1つのアタッチメントにつき1つのルートテーブルのみ関連付け可能）。
  • 伝播（Propagation）
    そのアタッチメントが持つCIDR情報を、「どのTGWルートテーブルに自動登録（動的学習）させるか」を決定する（複数のルートテーブルへ伝播可能）。
  • 静的ルート（Static Route）
    デフォルトルート（0.0.0.0/0）を集約ファイアウォールVPCに向けたい場合や、特定のBlackhole（破棄）ルートを設定したい場合に明示的に手動登録する。

【実務サンプル】TGWアタッチメント定義書

アタッチメント名接続リソースリソースID関連付けルートテーブル (Association)伝播先ルートテーブル (Propagation)備考
tgw-att-prod-vpcVPC (本番)vpc-0a1b2c3dtgw-rtb-prodtgw-rtb-shared, tgw-rtb-edge本番環境VPCアタッチメント
tgw-att-dev-vpcVPC (検証)vpc-0e4f5a6btgw-rtb-devtgw-rtb-shared, tgw-rtb-edge検証環境VPCアタッチメント
tgw-att-shared-vpcVPC (共通)vpc-09876543tgw-rtb-sharedtgw-rtb-prod, tgw-rtb-devAD・監視サーバ共有VPC
tgw-att-dxgwDirect Connect GWdxgw-11223344tgw-rtb-edgetgw-rtb-prod, tgw-rtb-dev, tgw-rtb-sharedオンプレミス閉域網接続

Direct Connect / ExpressRoute設計書：BGP冗長化と非対称ルーティング対策

ハイブリッドクラウドの根幹となるのが、物理専用線とBGP（Border Gateway Protocol）による動的ルーティングです。

ここを曖昧に記述すると、通信キャリアやNW構築ベンダーとの間で手戻りが無限に発生します。

専用線接続の物理・論理パラメータ（AWS DX vs Azure ER）

設計書の「回線接続仕様」には、以下の項目を一覧化します。

項目名設定値例（AWS Direct Connect）設定値例（Azure ExpressRoute）説明
接続ロケーションEquinix TY2 (東京)Equinix TY2 (東京)物理クロスコネクトを接続する接続拠点
物理ポート帯域1 Gbps Dedicated (占有)1 Gbps / Direct物理インターフェースの帯域
インターフェース1000BASE-LX (シングルモード光)1000BASE-LX光ファイバーのコネクタ・波長仕様
VLAN IDVLAN 100VLAN 100802.1QタグVLAN番号
MTUサイズ9001 (Jumbo Frames)1500 (Standard固定)AWSはJumbo対応、Azureは1500固定

■ Azure ExpressRouteを設計する際の必須注意点

AWS Direct Connectと異なり、Azure ExpressRouteのプライベートピアリングでは以下の固有仕様を設計書に明記する必要があります。

  • MTUサイズは「1500固定」（Jumbo Frame非対応のためオンプレ側ルータもMTU 1500に設定）
  • BGP ASN：オンプレミス側はプライベートASNを使用するが、「65515〜65521」はAzure内部予約のため使用不可。Microsoft側ASNは「12076」に固定される
  • ルータ冗長化：ExpressRouteは1回線契約で2本の物理接続（Primary/Secondary）が提供されるため、設計書上で両系統のBGPピア設定を必須化する

BGPパラメータシートの必須項目

BGPピアリングを確立するための設計シートです。

パラメータ名オンプレミス側ルータクラウド側 (AWS DXGW / Azure ER)備考
BGP自ASN65010 (Private ASN)64512 (AWS) / 12076 (Azure)自社ASNは予約番号を避けて選定
BGPピアIP169.254.100.1/30169.254.100.2/30/30のポイントツーポイント接続
BGP認証キー (MD5)Secr3t_Bgp_Key!2026Secr3t_Bgp_Key!2026平文での設計書記載厳禁（別紙管理）
Hold Time / Keepalive90秒 / 30秒90秒 / 30秒デフォルト値で一致させる
広報プレフィックス10.10.0.0/16 (集約ルート)10.100.0.0/16, 10.101.0.0/16細かいサブネットではなく集約ルートを広報

アクティブ／スタンバイの経路制御設計（非対称ルーティング防止）

回線冗長化において、「メイン回線障害時のみバックアップ回線に迂回させる」アクティブ／スタンバイ設計を行う場合、以下のBGP属性を設計書に明記します。

① オンプレミス ➔ クラウド（送信トラフィックの制御）

  • 使用する属性: Local Preference（ローカルプレファレンス）
  • 設計内容: オンプレミス側ルータのBGPインバウンドポリシーにて設定。
    • メイン回線から受信したクラウド経路：Local Preference = 200
    • バックアップ回線から受信したクラウド経路：Local Preference = 100
    • ➔ 数値が大きい「メイン回線」が優先的にアウトバウンド経路として選択される。

② クラウド ➔ オンプレミス（受信トラフィックの制御）

  • 使用する属性: AS-Path Prepending（ASパスプレペンド）
  • 設計内容: オンプレミス側ルータからクラウドへ経路をアドバタイズする際、バックアップ回線側に自ASNを複数個付加して広報する。
    • メイン回線から広報するオンプレ経路：AS-Path: 65010
    • バックアップ回線から広報するオンプレ経路：AS-Path: 65010 65010 65010（自ASNを2つ重ねて長大に見せる）
    • ➔ クラウド側ルータは「AS-Path長が短いメイン回線」を優先してパケットを返送する。

この両方の制御を設計書に盛り込むことで、行きの通信と戻りの通信が同じ回線を通り、オンプレ側FWでの通信断を完全に回避できます。

BFD（Bidirectional Forwarding Detection）による高速フェイルオーバー

BGPの標準キープアライブタイマー（30秒間隔、Hold Time 90秒）に依存していると、物理回線の途中障害やサイレント障害が発生した際、経路の切り替えに最長90秒〜3分程度のパケットロスが発生します。

業務システムでこのダウンタイムが許容できない場合、BFD（Bidirectional Forwarding Detection）の有効化を設計書に記載します。

  • 送信間隔（Transmit Interval）: 300 ms
  • 受信間隔（Receive Interval）: 300 ms
  • 検出倍数（Detect Multiplier）: 3
  • ➔ 障害発生から 約900ミリ秒（1秒未満） で障害を検知し、瞬時にバックアップ回線へルーティングを切り替えます。

【実務テンプレート】ハイブリッド接続パラメータシートの構成

実務でハイブリッドクラウドのネットワーク設計書をExcelやスプレッドシートで納品する場合、以下の5シート構成で作成するとレビュー・運用保守が極めてスムーズになります。

IaC（Terraform / CloudFormation）連携を見据えた命名規則

現代のクラウドインフラ設計書は、パラメータシートからそのままTerraform（tfvars）やCloudFormationのパラメータに変数として展開できることが求められます。

設計書のパラメータシートに以下の命名規則ルールを適用しておくと、構築自動化の工数を劇的に削減できます。

  • リソース命名フォーマット:[PJ名]-[環境]-[リージョン]-[リソース種別]-[識別子]
    • 例: prj-prod-tyo-vpc-app（本番業務VPC）
    • 例: prj-prod-tyo-snet-pub-1a（パブリックサブネット）
    • 例: prj-prod-tyo-tgw-rtb-prod（本番用TGWルートテーブル）
  • 必須タグ設計:すべてのネットワークリソースに Environment（Prod/Stg/Dev）、Project、Owner、ManagedBy（Terraform）のタグ定義を設計書上で必須化します。

まとめと次のステップ（設計書シリーズへの展開）

ハイブリッドクラウドのネットワーク設計は、オンプレミスの堅牢なIP管理・物理要件と、クラウドの柔軟で動的なSDNアーキテクチャを結びつける、インフラアーキテクトの腕が最も試される領域です。

7-1. ハイブリッドクラウドネットワーク設計 納品前セルフチェックシート

設計レビューの前に、以下の必須項目が設計書に網羅されているか最終確認を行ってください。

カテゴリチェック項目確認
アドレッシングオンプレミスとクラウド（AWS/Azure）でCIDRの重複が絶対に存在しないか□
アドレッシング各サブネットでクラウド特有の「予約IP（5個）」を差し引いてIP数が計算されているか□
アドレッシングサブネットサイズが極小（/28など）になっておらず、拡張余力（/26や/24）があるか□
ルーティングTGW/vWANのルートテーブルを環境別（本番・検証・共通）に分離定義しているか□
クォータオンプレミス側エッジルータで広報ルートを集約し、DX/ERの経路数上限を超えないか□
専用線接続回線全体のMTUポリシー（Jumbo Frame vs 1500）が全機器で整合しているか□
BGP冗長化Local PreferenceとAS-Path Prependingで、行きと戻りの優先回線が完全一致しているか□
障害切替BGPタイマー遅延を回避するためのBFDパラメータ（300ms×3等）が定義されているか□

最後に：クラウドの柔軟性とオンプレミスの堅牢性を繋ぐ架け橋

「クラウドになれば、ネットワークの設計は簡単になる」と言われることがあります。

しかし、実際の現場は全く逆です。物理の結線が見えなくなったからこそ、パケットがどのゲートウェイを経由し、どのルートテーブルで転送され、どのBGP属性で制御されているのかを、設計書の上で正確に可視化する能力がこれまで以上に強く求められています。

オンプレミスの物理インフラを知り尽くし、かつクラウドのSDNの癖を正しく理解したエンジニアが書く設計書は、プロジェクトをトラブルから救う唯一の道標になります。

本記事で解説した鉄則とパラメータシートをベースに、障害に強く拡張性の高いハイブリッドクラウドインフラを自信を持って設計してください！

🎁【無料】実務で役立つテンプレート・まとめシートを配布中！

記事内で紹介した実務で即使える設計書テンプレートのサンプルや、便利なまとめシートなどを専用ページにて配布しています。

X（@infra_mocchi）の固定ポストから認証キー（合言葉）を入手し、特典ファイルを無料でダウンロードできます。

📥️【無料】実務テンプレート・まとめシート配布ページ

※認証キーは、X（@infra_mocchi）の固定ポストにて公開中！

エンジニア実務・仕事術
【上流】現場リーダーの勘所

この記事が気に入ったら
フォローしてね！

よかったらシェアしてね！
  • URLをコピーしました！

レベル別記事一覧

【入門】未経験者の第一歩 【突破】作業者からの脱却 【技術】頼れる実務のプロへ 【上流】現場リーダーの勘所

▼▼▼まずはここからチェック！

あわせて読みたい
【必読ガイド】おすすめ記事：スキル別ロードマップ 私は現在、大手SIerで18年間、インフラエンジニアおよびサービスマネージャーとして、止まることが許されない200台規模のシステムを支えています。 このブログでは、私...

関連記事

目次