「検証で使った環境は EC2 を止めておいたのに、翌月の請求が思ったより高く来ました」
「部門ごとに AWS アカウントを作っていったら、CloudTrail や GuardDuty の設定がアカウントごとにばらばらで、どこで何が有効なのか分からなくなりました」
第11回では、CloudWatch・CloudTrail・Config・Systems Manager で、監視し、操作と設定を記録し、サーバーを管理する方法を見ました。オンプレでは、機器を買う時点で費用がほぼ決まり、資産台帳で棚卸しをしてきました。AWS では 使った分だけ、止めたつもりのものにも費用がかかり、アカウントやリソースは誰でもすぐに増やせます。費用を見える化し、全体を統制する仕組みが欠かせません。
後編の第12回では、タグ運用、データ転送料金、コスト管理のツールとつまずき、マルチアカウントの統制（Control Tower）、IaC、運用のつまずき、Azure との対応を扱います。料金は東京リージョンの例で、2026年9月時点の目安です。
タグ運用とリソースの棚卸し
タグは各リソースに付けるキーと値のペア（1つのリソースに最大 50個）で、単なるメモではなく、コスト配分・アクセス制御・自動化の単位 として働きます。コスト配分タグとして有効にすれば Cost Explorer で「部門別」「システム別」に費用を切り分けられ、IAM ポリシーの Condition（aws:ResourceTag/Environment）で「自分のプロジェクトのタグが付いたインスタンスしか止められない」という ABAC（属性ベースのアクセス制御）が書け、AWS Backup や Patch Manager はタグで対象を選びます。
したがって、タグの命名規則（Name、Environment、System、Owner、CostCenter、Backup など）を 最初に決め、Organizations のタグポリシーと Config ルール required-tags で強制 するのが定石です。後から付けようとしても「誰が何のために作ったか」が分からないリソースが残り、消すに消せない状態になります。
棚卸しには、Resource Explorer（全リージョンの横断検索）、Config のインベントリ、Cost Explorer の「タグなし」の費用を定期的に確かめる運用を組み合わせます。IaC（後の節「Infrastructure as Code（IaC）」）で作れば、テンプレートに書いたタグが自動で付くので、手作業でタグを付ける状況そのものを減らせます。
- タグは コスト配分・ABAC・自動化の対象選択 の単位
- 命名規則を最初に決め、タグポリシー＋Config で強制
- IaC で作れば自動で付く。「タグなし」の費用を定期的に確認
データ転送料金の構造
AWS の費用で見落とされやすいのが、データ転送の料金です。経路ごとに料金が違います（東京リージョンの例、2026年9月時点の目安）。
| 経路 | 料金（東京、目安） | 備考 |
|---|---|---|
| インターネット → AWS（イン） | 無料 | ― |
| AWS → インターネット（アウト） | 最初の 100 GB/月は無料（全リージョン合計）、以降 0.114 USD/GB（〜10 TB）、段階的に安くなる | 最も見落とされる費用。動画配信・大量のダウンロード |
| CloudFront → インターネット | 1 TB/月は無料、以降はリージョンからより安い | 配信は CloudFront 経由にすると安い |
| 同じ AZ の中（プライベート IP） | 無料 | パブリック IP・EIP 経由だと課金 |
| AZ 間 | 0.01 USD/GB（送信・受信のそれぞれ） | マルチ AZ の DB のレプリケーション、Kafka のレプリカなどで積み上がる |
| リージョン間 | 0.09 USD/GB 程度 | クロスリージョンレプリケーション |
| NAT ゲートウェイの処理 | 0.062 USD/GB＋時間 | S3 へは VPC エンドポイントで回避 |
| VPC エンドポイント（インターフェイス型） | 0.01 USD/GB＋時間 | ゲートウェイ型（S3・DynamoDB）は無料 |
| Direct Connect のアウト | 0.041 USD/GB 程度 | インターネットより安い |
| VPN | 接続時間＋通常のアウトの料金 | ― |
「クラウドは入れるのはタダ、出すと高い」と言われます。データを AWS から出す設計（オンプレの DWH に日次で全量を転送する、ほかのクラウドと往復する）では、コストの試算で必ず転送量を出しましょう。なお AWS は 2024年に、ほかの事業者へ移行するときのデータ転送料を、申請により無償 にしました。
コスト管理のツール
費用を見える化し、使いすぎを止めるためのツールです。
- Billing and Cost Management コンソール：請求書、サービス別の内訳、無料枠の消費状況を確かめられる
- Cost Explorer：サービス・アカウント・タグ・リージョン・購入オプション別に時系列で可視化できる。時間単位・リソース単位 の粒度も有効にできる（有料）。RI・Savings Plans の 推奨 と使用率・カバー率も出る
- AWS Budgets：予算（金額・使用量・RI の使用率）を設定し、実績または 予測 がしきい値を超えたら SNS で通知する。予算アクション で IAM ポリシーの適用や EC2 の停止も自動化できる。アカウントを作った直後にまず設定する
- Cost Anomaly Detection：機械学習で通常のパターンからの逸脱を検知する（消し忘れ、設定ミス、不正利用の早期発見）。無料
- Cost and Usage Report（CUR／Data Exports）：行単位の全明細を S3 へ出力できる。Athena で分析する
- Pricing Calculator：見積もりの作成に使う。Compute Optimizer：実測のメトリクスから、インスタンス・EBS・Lambda の適正なサイズを推奨する
- Trusted Advisor：コスト（アイドルな ELB・EBS・EIP、使用率の低い EC2）、セキュリティ、耐障害性、サービスの上限をチェックできる。サポートプラン Business Support+ 以上でフル機能
- AWS Billing Conductor：組織の中の部門・顧客ごとに独自の料率で請求を組み直せる（SIer が顧客へ再請求するときに使う）
コストのよくあるつまずき
請求が想定を超える原因は、たいてい次のどれかです。
- 検証で作った EC2・RDS・NAT ゲートウェイ・ELB の 消し忘れ（時間課金は止まらない）
- EC2 は止めたが、EBS・EIP・スナップショット が残っている
- CloudWatch Logs の 保持期間が無期限 で取り込み量も多く、監視の費用が本体を超える
- NAT ゲートウェイ経由の S3 への転送、AZ をまたぐ DB のレプリケーション、インターネット向けのアウト の見落とし
- 「とりあえず大きめ」のインスタンス。Compute Optimizer の推奨を無視
- RI・Savings Plans を買わずに、オンデマンドで3年運用
- タグなし のリソースが増え、誰の費用か分からず削れない
- 無料枠の期間・条件を誤解して請求が来る（2025年7月より前の無料枠は t2.micro（無いリージョンでは t3.micro）に限るなどの条件付き、それ以降に作ったアカウントはクレジット制の無料プラン。第2回で扱います）
- 予算のアラートを設定していない：まず Budgets、次に Anomaly Detection の順で設定する
冒頭の1つ目の相談がこれです。EC2 を止めても、EBS のボリューム、関連付けていない EIP（パブリック IPv4 は使っていても課金）、スナップショット、NAT ゲートウェイ、ELB は課金が続きます。検証が終わったら「止める」ではなく「消す」、そして Budgets で予算を超える前に気づけるようにしておきます。
マルチアカウントの統制：Control Tower
アカウントを部門・システム・環境ごとに分けると（第2回・第8回）、今度は「全アカウントに共通の設定（CloudTrail、Config、GuardDuty、SSO、ネットワーク）をどう漏れなく適用するか」が課題になります。この共通の基盤を AWS では ランディングゾーン と呼び、それを自動で構築・維持するのが AWS Control Tower です。
Control Tower を有効にすると、Organizations、ログ集約用のアカウント（Log Archive）、監査用のアカウント（Audit）、IAM Identity Center が自動で構成され、OU ごとに コントロール（旧ガードレール） が適用されます。コントロールには、SCP による 予防的（「CloudTrail を無効にさせない」）、Config ルールによる 検出的（「暗号化されていない EBS を検出」）、2023年からの プロアクティブ（CloudFormation のデプロイ前に検査）の3種類があります。Account Factory から新しいアカウントを払い出すと、最初からこれらが適用された状態になります。
すでに多数のアカウントがある場合は「既存の OU の登録」で後から適用することもできますが、ネットワーク（Transit Gateway、共有 VPC）や IAM の設計は Control Tower の範囲外なので、AWS の「Landing Zone Accelerator」やパートナーのテンプレートで補います。「まず1アカウントで始めて後から統制する」より、最初から Control Tower で3〜5アカウントの構成にする ほうが、結果的に手戻りが少なくなります。
冒頭の2つ目の相談がこれです。アカウントごとに手作業で設定していると、漏れやばらつきは必ず出ます。Control Tower を有効にして既存のアカウントを OU ごとに登録すれば、CloudTrail・Config などの共通の設定とコントロールがそろい、どれが守られていないかも1か所で分かるようになります。これから作るアカウントは、Account Factory から払い出します。
- ランディングゾーンは 全アカウントに共通の基盤。Control Tower が自動で構築
- コントロールは 予防的（SCP）・検出的（Config）・プロアクティブ の3種類
- Account Factory で統制済みのアカウントを払い出す。最初から入れておく
Infrastructure as Code（IaC）
インフラをコードで書き、作成・変更・削除をコードで行う道具です。
| ツール | 記述 | 特徴 |
|---|---|---|
| AWS CloudFormation | YAML・JSON | AWS 純正・無料。「スタック」の単位で作成・更新・削除。変更セット で差分を事前に確認、ドリフト検出 で手作業の変更を発見。ロールバックは自動 |
| AWS CDK | TypeScript・Python など → CloudFormation | プログラミング言語でループ・条件・抽象化。生成物は CloudFormation のテンプレート |
| Terraform（HashiCorp） | HCL | マルチクラウド（AWS・Azure・オンプレ）。状態ファイル（tfstate）を S3 に置いてロック。2023年にライセンスを変更し、OSS のフォーク OpenTofu が登場 |
| AWS SAM | YAML（CloudFormation の拡張） | サーバーレス（Lambda・API Gateway）向けの短縮記法 |
| Pulumi | 汎用の言語 | Terraform と CDK の中間 |
手順は「テンプレートを Git で管理 → プルリクエストでレビュー → CI で plan・変更セット → 承認 → apply」という流れです。本番環境を手作業で変更しないようにしましょう（変更するとドリフトが起き、次の apply で消えてしまいます）。Well-Architected の運用上の優秀性（第13回）は、以前の版では第一の設計原則に「運用をコードとして実行する」を掲げていました（今の版では「可能な限り安全に自動化する」に含まれる）。IaC はその基盤です。CloudFormation の例です。
Resources:
WebSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: web tier
VpcId: !Ref VPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
SourceSecurityGroupId: !Ref AlbSGWeb 層のセキュリティグループで、443番への通信を ALB のセキュリティグループからだけ許可しています（SG を参照で書く方法は第6回で扱います）。
運用のよくあるつまずき
運用で起こりがちな失敗です。
- CloudWatch にメモリ使用率が無いことを知らず（前編の「CloudWatch：メトリクス」の節）、エージェントを入れないまま「監視できている」と思ってしまう
- Logs の保持期間が無期限、CloudTrail のデータイベントが未設定、GuardDuty が未有効のまま放置する（いずれも有効にするだけで効果がある3点）
- アラームの通知先のメールを 確認（Confirm）しておらず届かない
- Session Manager の前提（エージェント・ロール・エンドポイント）が揃わず、結局 22番を開けてしまう
- コンソールから手作業で変更してドリフトが起き、次の IaC の適用で消える・失敗する
- AWS Health のイベントを見ておらず、EC2 の「予定されたメンテナンス（再起動）」に気づかない
- サービスの上限（Service Quotas）に当たって起動できない（EC2 の vCPU の上限、EIP 5個、VPC 5個。いずれもリージョンごとの既定値）。事前に Quotas を確かめて引き上げを申請する
- サポートプランが Basic のままで、障害時に技術の問い合わせができない。本番は Business Support+ 以上にする（Developer・Business は2025年12月に新規の申し込みを終え、2027年1月1日に終了）
Azure との対応表（運用・監視・コスト）
前編（第11回）と後編で扱ったサービスを、Azure で何と呼ぶかの対応です。
| AWS | Azure | 補足 |
|---|---|---|
| CloudWatch（メトリクス） | Azure Monitor（メトリクス） | ― |
| CloudWatch Logs／Logs Insights | Log Analytics ワークスペース／KQL（Kusto） | KQL は Logs Insights より高機能 |
| CloudWatch エージェント | Azure Monitor エージェント（AMA） | ― |
| CloudWatch アラーム／SNS | Azure Monitor アラート／アクショングループ | ― |
| EventBridge | Event Grid | ― |
| CloudTrail | Activity Log（管理操作）／Entra ID の監査ログ | データプレーンの操作は診断設定で別に取る |
| AWS Config | Azure Policy（監査・拒否・修復）／Resource Graph（履歴） | Azure Policy は SCP のような拒否も担う |
| Systems Manager | Azure Automation／Update Manager／Run Command／Azure Arc（ハイブリッド） | ― |
| Session Manager | Azure Bastion／Serial Console | ― |
| Cost Explorer／Budgets／Anomaly Detection | Microsoft Cost Management（分析／予算／異常検出） | ― |
| Compute Optimizer／Trusted Advisor | Azure Advisor | ― |
| Control Tower | Azure Landing Zone（CAF のリファレンス実装、Bicep・Terraform） | Azure は製品ではなく「参照アーキテクチャ＋アクセラレーター」 |
| CloudFormation／CDK | ARM テンプレート／Bicep | Terraform は共通 |
| Service Quotas | サブスクリプションのクォータ | ― |
| AWS Health | Azure Service Health／Resource Health | ― |
考えてみよう
- 手元の AWS アカウント（または検証用のアカウント）で、Budgets の予算と Cost Anomaly Detection は設定されていますか。止めた EC2 の EBS、関連付けていない EIP、古いスナップショットは残っていませんか
- オンプレの DWH へ毎日 500 GB を AWS から転送すると、月にどれくらいのアウトの料金になりますか（東京リージョン、2026年9月時点の単価で概算してください）
- 3つの部門が1つの AWS の組織を使い始めます。部門ごとに費用を分け、ほかの部門のインスタンスを止められないようにし、タグの付け忘れを防ぐには、何を最初に決め、どの仕組みで強制しますか
ヒント：1は「コスト管理のツール」「コストのよくあるつまずき」、2は「データ転送料金の構造」、3は「タグ運用とリソースの棚卸し」の節を見直してください。
まとめ
- タグは コスト配分・ABAC・自動化の単位。命名規則を最初に決めて強制する
- 出すと高い データ転送料金。NAT ゲートウェイ・AZ 間・インターネット向けのアウトを試算に入れる
- コスト管理は Budgets → Anomaly Detection の順に設定し、Cost Explorer・Compute Optimizer で見直す
- EC2 を止めても EBS・EIP・スナップショット・NAT・ELB の課金は続く。検証が終わったら「消す」
- マルチアカウントは Control Tower で最初から統制し、本番は IaC で変更する
- 運用のつまずきは、まず Logs の保持日数・CloudTrail の証跡・GuardDuty の3点から
次回は、AWS の設計原則 Well-Architected フレームワークと、6つの柱・トレードオフ・レビューの進め方を扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）（この記事）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント