「東京都クラウドインフラ」は"いつものAWS"とどう違うのか——標準仕様書ver.1.5を読み解く

本記事は「東京都クラウドインフラ標準仕様書 ver.1.5」（令和7年10月27日、東京都デジタルサービス局デジタル基盤部）の記載をもとに、一般的なパブリッククラウドとしてのAWS利用（いわゆる「素のAWS」）との相違点を筆者が整理したものです。仕様書別紙3のサービス統制情報は令和7年3月31日時点とされており、最新の可否は原文および東京都クラウドインフラ管理者への確認が必要です。文中の「※」は、仕様書に明記がなく筆者の推測・補足である箇所を示します。

はじめに

東京都は令和7年（2025年）11月4日、都の業務システム向け共通クラウド基盤「東京都クラウドインフラ」をスモールスタート（シングルクラウド構成）で開始しました。使用可能なCSPはAmazon Web Services（AWS）です。

「なんだ、AWSか。ならいつも通り作ればいい」——と思ったAWSエンジニアの方にこそ読んでいただきたいのが本記事です。標準仕様書を読み込むと、これは「AWSアカウントをもらって自由に使う」基盤ではなく、AWSの上に都の統制レイヤーを被せた"ガードレール付きAWS" であることが分かります。VPCは作れてもインターネットゲートウェイは作れない、EC2は建てられてもSession Managerでは入れない、といった具合です。

本記事では、受託者（都の各局等から業務システムの構築運用を受託する事業者）のエンジニア目線で、素のAWSとの違いを8つの観点に整理します。

全体像：AWSの上に「都の統制」を被せた基盤

東京都クラウドインフラは、次の2つで構成されます。

クラウドインフラサービス：CSP（AWS）のクラウドサービスに、都として必要な統制機能やセキュリティ設定を適用したもの
クラウドネットワークサービス：CSPまでの専用接続回線

AWS環境は、東京都クラウドインフラ管理者が AWS Solution Provider Program を使って受託者に提供します。つまりAWSとの直接契約ではなく、管理者から「CSP環境が払い出される」リセール型です。この契約形態が、後述するサービス統制や購入オプション制限（RI/SP不可）の土台になっています。

利用可能リージョンは国内のみで、東日本＝プライマリーリージョン、西日本＝セカンダリーリージョンの両方が提供されます。ただし後述のとおり、西日本側で提供されないサービスが少なくありません。

ネットワークは5系統に分離されている

素のAWSでは、VPCをどう分けるかは設計者の自由です。東京都クラウドインフラでは、最初から領域とネットワーク系統が5つに分かれており、業務システムはどこかの系統に所属します。複数の環境・系統を使う場合は、系統ごとにアカウントを申請します。

領域	ネットワーク系統	インターネット	概要
TAIMS領域	個人番号系	不可	個人番号系の閉域網と接続
TAIMS領域	LGWAN系	不可	LGWAN系の閉域網と接続
TAIMS領域	内部系	インバウンド不可・アウトバウンドはTAIMSネットワーク経由で可	内部系の閉域網と接続
汎用領域	インターネット接続なし	不可	利用者ネットワーク（各局独自網）から使う業務システム向け
汎用領域	インターネット接続あり	HTTPSで可（共通のIPS/IDS＋WAF経由）	インターネット公開が必要な業務システム向け

自治体クラウドを追っている方なら、マイナンバー利用事務系・LGWAN接続系・インターネット接続系という 自治体情報セキュリティの三層分離をクラウド上に持ち込んだ構造 だと直感されるはずです。TAIMSは都庁の内部ネットワーク（Tokyo Advanced Information Management System）で、その系統区分がそのままクラウド側の領域設計に写像されています。

重要なのは、環境・ネットワーク系統を跨いだ通信が原則禁止 であることです。例外は、同一環境のTAIMS領域（内部系）から汎用領域（インターネット接続あり）への一方向通信で、申請ベースで許可されます。この場合、接続先側にVPCエンドポイントとNLBを利用者側で構築します。本番環境と検証・試験環境もネットワーク分離されており、同一系統内での本番⇔検証通信は申請により提供されます。それ以外の跨ぎ通信は、管理者と都の情報セキュリティ課との協議事項です。

違い1：アカウントは「払い出される」——Organizationsの外には出られない

素のAWSなら自分でOrganizationsを組み、Control Towerでランディングゾーンを敷くところですが、この基盤ではそれらは管理者側の統制機能であり、利用者環境では使用不可です。利用者は申請に基づいてCSP環境と特権ユーザーの払い出しを受けます。

CSPアカウントへのログインは、申請したグローバルIPアドレスからのみ接続可能
特権ユーザーから最小権限のIAMユーザーを作成して運用し、そのIAMユーザーにも同様のグローバルIP制限をかける
多要素認証（MFA）の導入は必須
IAM Identity Centerは使用不可（利用者環境ではIAMユーザーを使用する前提のため）
CloudTrail等、管理者が収集するログの変更・削除は不可（CSPM＝クラウドセキュリティ管理として設定監査・監視・ログ保管が管理者側で常時実施される）
STSのスイッチロールも、TAIMS領域では同一環境・同一ネットワーク層のアカウント間などに制限

「アカウントの中では自由、アカウントの外は都が握る」という設計思想が徹底しています。

違い2：インターネットゲートウェイが作れない

個人的に最もインパクトが大きいのがこれです。利用者はInternet Gatewayを作成できません。インターネットとの出入口は、汎用領域（インターネット接続あり）に用意された共通アクセスネットワークに集約され、共通のセキュリティポリシーが適用されたIPS/IDSとWAFを必ず通ります。このポリシーを受託者は変更できません。

アウトバウンド通信：ドメインフィルタリング（ブラックリスト形式）で制御
インバウンド通信：5tuple（送信元IP・送信元ポート・宛先IP・宛先ポート・プロトコル）で制御
IGWが作れない以上、自前のNAT Gateway経由でアウトバウンド経路を組む構成も成立しません※
ファイアウォールの通信設定変更も、利用者が申請し管理者が実施する運用です

VPCについても、IGWのほかVPC Lattice・VPN・Verified Access・キャリアゲートウェイ・Transit Gateway・VPCピアリングの作成が制限されています。VPC間接続はTGW（管理者側が提供）前提で、ネットワーク層を跨ぐPrivateLinkの作成も不可です。

なお、汎用領域（インターネット接続あり）のSSL/TLS証明書は、外部認証機関発行分のインポート・更新を管理者が行います（証明書の取得自体は利用者責任。都の証明書機関からの取得が原則推奨）。CloudFrontが「使用可（制限付き）」なのも、IGW前提の構成が組めないことによるものです。

違い3：サーバーへの入口は踏み台サーバー——Session Managerは使えない

素のAWSでは今どきSSM Session Managerで鍵レス接続、が定石ですが、この基盤ではSession Manager・Fleet Managerが使用不可、CloudShellもVPC内起動が不可（マネジメントコンソールから仮想サーバーへ直接届いてしまうため）とされています。代わりに用意されるのが、管理者提供の踏み台サーバーです。

TAIMS領域・汎用領域（接続なし）：踏み台にRDPで接続→踏み台経由でRDP/SSH
汎用領域（接続あり）：CSP管理画面が提供するサーバー管理機能を使い、踏み台経由でアクセス
踏み台では管理者によるログイン制限と証跡記録が行われる
プリインストールはTera Term・WinSCP・Google Chrome・Microsoft Edge。導入済みソフトの変更・削除は禁止
追加ツールが必要なら、別途「運用サーバー」を構築し、踏み台→運用サーバー→業務システムという経路にする
ストレージは130GB（利用可能は約100GB弱）、同時接続は最大2（必要に応じて増設申請）

別紙7の考慮事項リストには「TAIMS領域の業務システムはインターネット経由でのアクセスが不可であるため、運用保守拠点からの遠隔保守は実施できない（TAIMSネットワークに接続された端末がある拠点まで移動する必要がある）」と明記されています。TAIMS領域案件では、駆けつけ前提の運用保守費を織り込む必要があります。

違い4：OSはテンプレート3種類・エージェントは剥がせない

任意のAMIを持ち込める素のAWSと異なり、業務システムは基盤提供のOSテンプレートから構築します（AWS Marketplaceが使用不可のため、サードパーティAMIの持ち込みもできません）。

#	仮想マシンOS	バージョン
1	Windows Server Datacenter Edition	2019 / 2022
2	Red Hat Enterprise Linux	8 / 9
3	Ubuntu Server	22.04 LTS / 24.04 LTS

テンプレートに事前設定されたOSパラメータや、プリインストールされた管理用エージェントの変更・削除は不可
テンプレート由来のVMでは、競合による誤動作防止のためMicrosoft Defenderなど他の仮想マシンセキュリティ保護機能の有効化が禁止。基盤側の仮想マシンセキュリティ保護（侵入検知・マルウェア対策・ふるまい検知・改ざん検知）は内部系と汎用領域（接続あり）に提供され、ポリシー変更は不可。個人番号系・LGWAN系・汎用（接続なし）のEPP/EDRは管理者の実装範囲外です（扱いは要確認※）
OSのパッチ・更新プログラム・パッケージは基盤提供のOSリポジトリから取得し、指定リポジトリ以外への接続は禁止。パッケージ配布対象はRHELとUbuntuのみ。個別にWSUS等の更新適用サーバーを立てる場合でも、本機能を上流参照サーバーには指定できません
OSを持ち込むBYOLの場合、パッチ適用等は全て自前になります（別紙7）

小ネタとして、別紙8の通信費積算からは管理エージェントとしてEndpoint Central（ManageEngine製の資産管理ツール※）が入っていることが読み取れます。また同積算では、OSリポジトリ通信の想定量がWindows 2.3GB/月・Ubuntu 1.2GB/月に対してRHELは16.5GB/月/台と桁違いで、TGWデータ処理料と通信費がOUT分に課金されるため、RHEL多数構成では通信費も無視できません。

違い5：使えるAWSサービスは「統制リスト」で決まる——Bedrockは使えない

別紙3には200超のAWSサービスについて、領域ごとの使用可否と統制方針が一覧化されています。分類の考え方は次のとおりです。

分類	内容	使用可否
①	提供終了（済み・予定）のサービス	使用不可
②	AWSの制約により再販できないサービス	使用不可
③	要望に応じて詳細検討するサービス	TAIMS不可／汎用可
④	インターネット接続が必須のサービス（CloudFront等）	TAIMS不可／汎用可
⑤	AWS内でのみ稼働（CloudWatch、GuardDuty等）	使用可
⑥	VPC内でのみ稼働（EC2、RDS等）	使用可
⑦	インターネットとVPCの両方と通信可能	サービス特性で個別判断
⑧	その他	サービス特性で個別判断

エンジニア目線でのハイライトを挙げます。

全領域で使用不可：AWS Organizations、Control Tower、Direct Connect、Marketplace、VPN（いずれも管理者側の統制機能）。購入オプションのSavings Plans・Reserved Instancesも会計上の理由で利用不可
Amazon Bedrockは使用不可（分類②：再販できないサービス）。この基盤上で生成AIサービスを直接使う道は現状ありません※今後の扱いは不明
TAIMS領域で使用不可の代表例：API Gateway、Athena、Glue、OpenSearch Service、QuickSight、EKS、EMR、DataSync、Storage Gateway、Transfer Family、SES、CloudFront、AppSyncなど。「インターネット経由のみの接続を制限できない」タイプのマネージドサービスが軒並み落ちます。データ分析基盤やモダンなサーバーレス構成をTAIMS領域で組むのはかなり厳しい※
使用可（制限付き）の例：
- S3：全領域でパブリックアクセス禁止
- DynamoDB／ECR：TAIMS領域ではマネジメントコンソール等インターネットからのデータ操作禁止、VPCエンドポイント経由のみ（ECRはパブリックリポジトリも禁止）
- Lambda／CodeBuild：TAIMS領域ではVPC内起動に制限
- SNS：VPCに紐付かないサービスのため通信経路に留意し、機密情報の送信には使わない
コンテナはECS／Fargateが全領域で使用可、EKSは汎用領域のみ。RDS・Aurora・ElastiCache・Redshift等のVPC内DBサービスは全領域で使用可です
サービス名に「*」が付くものは利用条件があり要事前確認。別紙3の情報は令和7年3月31日時点で、以降にリリースされたサービスは管理者への確認が必要
リージョン差にも注意：別紙3の提供有無欄では、App Runner・QuickSight・Audit Manager・Budgetsなど西日本側が「×」のサービスが目立ちます。災害対策環境をセカンダリーリージョンに置く設計では、利用予定サービスの西日本提供状況の確認が必須です

違い6：リザーブドインスタンスもSavings Plansも買えない

コスト設計は素のAWSと大きく感覚が変わります。

EC2の費用積算はオンデマンドインスタンス前提。RI・SP等の割引は利用できません（別紙3・別紙7）。一般に長期コミットで大きな割引（※AWS公表の標準値で最大7割前後になるケースもある）が得られる手段が封じられるため、常時稼働ワークロードの継続コストは相応に高くなります
一方でAWSサポートはエンタープライズサポートが基盤側から提供され、個別の費用計上は不要。IPS/IDS・WAFも「基本機能部分（基盤分）」扱いで、利用者側の費用考慮は不要です
利用者環境にはデフォルトで課金が発生するリソースが設置されます：TGWアタッチメント（730時間/月の時間課金）、EventBridge、AWS Config（記録項目665＋ルール1）、GuardDuty、Security Hub（5,000チェック/アカウント）、KMS（CMK 1個）。ガバナンス・セキュリティ上の必須設置なので、何も動かしていなくても月額費用が発生します
料金は「基本機能部分（基盤分）」「業務システム分（従量課金分）」「業務システムの開発・運用保守経費」の3階建てで、受託者が見積もるのは後2者。従量分はAWS Pricing Calculator等で算出します
利用開始日にかかわらず、利用開始月の1日から利用料の請求が発生します
Amazon RDSは基盤分のサーバー台数カウントに含まれません（従量課金は別途発生）
SLAは各CSPのSLAに準拠。SLA未達時の返金対応は管理者がCSPとの契約に従って行います

違い7：監視・セキュリティは「共通は都、業務は受託者」

素のAWSなら監視もセキュリティも全部自分の責任（Shared Responsibilityの"上半分"は全部自分）ですが、この基盤では管理者と受託者で実装範囲が分かれます。

項目	管理者（都側）	受託者
クラウドサービス／リージョンの死活監視	○	要件に応じ追加設計
エンドツーエンド監視、VMのログ／プロセス／死活監視	─	○
ファイアウォール（業務システム向け通信制御）	○（設定変更は申請ベース）	申請
IPS/IDS（インターネット通信対象）	○	─
EPP/EDR	内部系・汎用（接続あり）のみ○	左記以外の系統※
CSPM（クラウド設定の監査・監視・ログ保管）	○（ログの変更・削除不可）	─
OSパッチ	配信基盤の提供、マスターOSイメージへの適用	業務システムへの適用
データ暗号化	─	○（CSPサービス・ミドルウェア機能で実施）
セキュリティインシデント	共通部分を24時間365日監視し必要に応じ通知	業務システムのアラート監視・対応

管理者側が手厚い一方、FWの設定変更ひとつ取っても申請→管理者作業という運用です。構築スケジュールには申請リードタイムを織り込む必要があります。また名前解決は正引き（ドメイン名→IP）のみで逆引きは提供されず、インターネット経由の名前解決等は「プロトコル試験申請書」による個別申請です。TAIMS領域の内部ドメイン証明書はACM Private CA等を都が管理主体として発行し（利用者は直接発行不可）、インポート・更新やALBへのアタッチは利用者・受託者側の作業になります。

違い8：使い始めるまでのリードタイムが長い

素のAWSはクレカ登録5分でVPCが作れますが、こちらは段取りが必要です。

ポータルアカウント払い出し：約3〜5開庁日
CSP環境払い出し：約10開庁日
業務システム構築（受託者）
名前解決・VMセキュリティ保護など構築後の各種設定変更：約3〜5開庁日

さらに汎用領域（インターネット接続なし）を使う場合は、利用者拠点からクラウドネットワークサービスまでのアクセス回線を利用者側で敷設します。機密保持契約を締結した事業者のみに提供される「ネットワーク接続要件書」の確認から始まり、回線事業者との契約、データセンター現地調査（約1か月）、クラウドネットワークサービス準備（約2か月）・構内配線工事（約3週間）・回線敷設工事（約2か月）を経て利用開始です。契約事務や回線事業者にもよりますが、数か月〜半年スケールの計画になります※。

回線要件も具体的で、帯域は1Gbpsまたは10Gbps（1000BASE-LX／10GBASE-LR）、回線種別はL2専用線または広域イーサ網、拠点ルーターを冗長構成にする場合はBGP必須（シングル構成ならStaticルートも可）、ジャンボフレーム不可、クラウド側VLAN番号は利用者が採番して管理者へ連絡、と指定されています。

コラム：ガバメントクラウドとの関係

国のガバメントクラウド（デジタル庁が整備するマルチクラウドの共通基盤。自治体標準化システムの移行先）とは別枠の、都独自の基盤です。ただし設計思想には共通点が多く、アカウント払い出しモデル、閉域接続、テンプレート提供、サービス統制リストといった要素は、ガバメントクラウドのAWS環境を知っている人には既視感があるはずです。東京都版の特徴は、シングルクラウド（AWS）でのスモールスタートであること、そしてTAIMS三系統＋汎用二系統という都庁ネットワークの構造をそのままクラウド側に持ち込んだ領域設計です。

なお改訂履歴を読むと、ver.1.5（令和7年10月27日）で基本方針の節から「区市町村及び政策連携団体」の記載が削除されています。初期には都内区市町村等への展開も視野にあった可能性がありますが、当面は都（各局等）向けに絞られたと読めます※筆者解釈。

まとめ：「AWSが使える」と「いつものAWS構成が使える」は別物

最後に、受託者エンジニア目線での要点をまとめます。

設計：IGWなし・踏み台経由・跨ぎ通信原則禁止・サービス統制リストという4つのガードレールを前提に置く。使いたいサービスの可否（と西日本リージョンでの提供有無）を別紙3で最初に確認するところから設計が始まります。特にEKS・データ分析系・生成AI系はTAIMS領域では選択肢に入りません
見積り：オンデマンド縛り、デフォルト設置リソースの固定費、管理通信のTGWデータ処理料、アクセス回線費、そしてTAIMS領域の「遠隔保守不可」に伴う駆けつけ運用費。素のAWSの相場観で見積もると確実に外します
スケジュール：払い出し・FW設定・跨ぎ通信許可などが申請ベースで、回線敷設が絡めば月単位のリードタイムが乗ります

一方で見方を変えれば、都のセキュリティポリシーに適合済みのランディングゾーン、エンタープライズサポート、共通部分の24時間365日監視が「ついてくる」基盤でもあります。ゼロから都要件を満たす環境を自作することに比べれば、統制の窮屈さはガバナンスコストの前払いとも評価できます※。いずれにせよ、「AWS経験者だから大丈夫」ではなく、この基盤固有のルールブックとして標準仕様書を読み込むことが、受託の第一歩になりそうです。

出典

東京都クラウドインフラ標準仕様書 ver.1.5（令和7年10月27日、東京都デジタルサービス局デジタル基盤部）
本文および別紙2（用語の定義）、別紙3（利用可能なサービス一覧・令和7年3月31日時点）、別紙4（利用者ネットワークの接続）、別紙7（考慮事項リスト）、別紙8（デフォルト設置リソースの費用積算）

本記事は筆者個人の整理・解釈であり、正確な要件は必ず原文（標準仕様書・概要説明書・利用手続ガイド）と東京都クラウドインフラ管理者への確認をお願いします。