AWS運用代行を契約すると、委託先の担当者は自社のAWSアカウントに入り、監視・障害対応・パッチ適用を行います。その入口になるIAMロールと外部ID、アラームの届け先、パッチの承認条件、操作ログの残し方を発注側がどう組むかで、委託中の安全性と、解約や乗り換えのしやすさが決まります。本記事で順に示すのは、運用代行の開始前に発注側が用意する受け入れ設定です。説明にはAWS公式ドキュメントの仕様とAWS CLIのコマンド例を用います。委託範囲や費用相場には触れず、技術設定に絞りました。
まとめ：AWS運用代行の受け入れで発注側が先に組む設定と委託先に渡さない権限
委託先へのアクセスは、IAMユーザーとアクセスキーの払い出しではなく、クロスアカウントのIAMロールで渡します。信頼ポリシーには委託先のAWSアカウントIDと、委託先が発行した外部IDを条件として書き、外部IDなしの呼び出しが拒否されることを契約開始前に確かめます。
通知の経路とログの配置先は、自社のアカウントです。AWS HealthとCloudWatchアラームの通知は自社所有のSNSトピックから委託先へ配り、操作の記録はCloudTrailの証跡で自社のS3に残します。委託先のロールには、証跡の停止とIAMユーザー作成を明示的に禁じるDenyを付けます。
パッチは「何を当てるか」を自社がベースラインで決め、「いつ当てるか」の実行を委託先に任せる分担が扱いやすい形です。委託先が配るCloudFormationテンプレートは、外部IDの条件があり、AdministratorAccessを付けていない場合に限ってそのまま流します。
AWS運用代行で委託先が触る範囲を、IAMロールの境界で先に線引きする設計
どの作業を委託するか、月額がいくらかは、AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準で整理しています。ここでは、決まった委託範囲をAWSアカウントの権限にどう写すかを扱います。
委託先にIAMユーザーとアクセスキーを払い出さず、ロールで渡すべき理由
AWS公式の第三者が所有するAWSアカウントへのアクセス許可の解説は、外部の監視会社を雇う例を挙げ、長期認証情報を持つIAMユーザーを渡さずにIAMロールと一時的な認証情報を使うよう明記しています。同じページには、委託先が使ったリソースの料金は自社に請求されるという注意もあります。
アクセスキーは、委託先の担当者が替わっても失効しません。PCや設定ファイルに残ったキーの回収は発注側からは確かめようがなく、解約後も使える状態が続きます。ロールなら信頼ポリシーを書き換えるか削除するだけで入口が閉じます。IAMのユーザー・ロール・ポリシーの違いはAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計を参照してください。
閲覧用と作業用の2ロールに分ける権限設計とReadOnlyAccessの落とし穴
ロールは「見るだけ」と「手を動かす」の2本に分けます。監視と一次調査は閲覧用ロール、再起動やパッチ実行は作業用ロールで行い、作業用ロールの利用は手順書に載った操作に限ります。
閲覧用に付けるAWS管理ポリシーの選び方には注意が要ります。ReadOnlyAccessはS3のs3:Get*を含むため、バケット内のオブジェクトの中身まで読めます。顧客データや個人情報を置くバケットがあるなら、リソースの一覧と設定だけを見せる職務別ポリシーViewOnlyAccessを起点にし、足りない権限を個別に足すほうが安全です。作業用ロールには、EC2の停止と起動、Systems Managerのコマンド実行、CloudWatchアラームの変更など、運用手順書に書かれた操作だけを許可します。IAM全般の権限は付けません。
委託先IAMロールの作成手順＝外部IDを条件にした信頼ポリシーとCLIでの受け入れ検証
ロールの作成に必要な情報は委託先から受け取ります。作成後は、ロールのARNを委託先に伝えます。
委託先から受け取る2つの値＝AWSアカウントIDと外部IDの正しい扱い方
受け取るのは、委託先のAWSアカウントIDと外部ID（ExternalId）の2つです。外部IDは、委託先が多数の顧客アカウントへ入る構造で起きる混乱した代理問題（confused deputy）を防ぐための値で、別の顧客が自社のロールARNを委託先に渡しても、委託先がその顧客用の外部IDで呼び出す限り拒否されます。
この仕組みが働くのは、外部IDを委託先が顧客ごとに一意に発行している場合だけです。AWSのドキュメントも、外部IDは顧客ではなく委託先が生成するものだと書いています。発注側が自分で決めた文字列を伝える運用は避けてください。外部IDは秘密情報としては扱われず、ロールを閲覧できる人には見えます。値は2〜1,224文字の英数字で、記号は+ = , . @ : / -が使えます。社名や電話番号のように推測できる値は使いません。
信頼ポリシーと権限ポリシーをAWS CLIで作るコマンド例と各値の意味
以下は、自社アカウント111122223333に、委託先アカウント444455556666用の閲覧ロールを作る例です。前半をtrust-policy.jsonとして保存し、後半のコマンドを自社アカウントの管理者で実行します。
# ---- trust-policy.json（委託先アカウントだけを、外部ID付きで信頼する）----
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::444455556666:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "vendor-issued-7f3c9a21" }
}
}
]
}
# ---- ロールを作成し、閲覧用のAWS管理ポリシーを付ける ----
aws iam create-role \
--role-name VendorOpsViewOnly \
--assume-role-policy-document file://trust-policy.json \
--max-session-duration 3600
aws iam attach-role-policy \
--role-name VendorOpsViewOnly \
--policy-arn arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
Principalのrootは委託先アカウント全体を指し、委託先の中で誰がこのロールを使えるかは委託先側のIAMで絞られます。セッションの最長時間は3600秒（1時間）にしてあり、障害対応で長時間の作業が続く場合も、1時間ごとに認証し直す形になります。
外部IDなしのAssumeRoleが拒否されることを確かめる受け入れテスト
AWSのドキュメントは委託先に対し、顧客からロールARNを受け取ったら、正しい外部IDを付けた場合と付けない場合の両方で引き受けを試し、外部IDなしで通るならそのARNを保存しないよう求めています。発注側はこの2つの結果を委託先に実行してもらい、出力を受け入れ記録として残します。
# 委託先アカウントで実行する
# 1) 外部IDを付けない呼び出し。期待結果：AccessDenied で失敗する
aws sts assume-role \
--role-arn arn:aws:iam::111122223333:role/VendorOpsViewOnly \
--role-session-name acceptance-test
# 2) 外部IDを付けた呼び出し。期待結果：一時認証情報の有効期限が返る
aws sts assume-role \
--role-arn arn:aws:iam::111122223333:role/VendorOpsViewOnly \
--role-session-name acceptance-test \
--external-id vendor-issued-7f3c9a21 \
--query "Credentials.Expiration"
1が成功してしまう場合は、信頼ポリシーのConditionが抜けている状態です。assume-roleのリファレンスにある--external-id以外の引数は省いても動きます。引き受けた後の認証情報が意図したロールになっているかは、aws sts get-caller-identityの使い方で確かめられます。
監視通知の引き渡し＝AWS HealthとCloudWatchアラームを委託先へ流す配線
通知の経路を委託先のアカウントだけに作ると、解約した日にアラームの届け先が消えます。経路は自社に置き、届け先に委託先を加えます。
AWS HealthのEventBridgeルールを東京とus-east-1に置く設定
AWS Healthのイベントは、EventBridgeスキーマ上でsourceがaws.health、detail-typeがAWS Health Eventです。eventTypeCategoryはissue・accountNotification・investigation・scheduledChangeの4種で、メンテナンス予定の通知はおおむね2週間前に届きます。
# ---- health-rule.json ----
{
"source": ["aws.health"],
"detail-type": ["AWS Health Event"],
"detail": {
"eventTypeCategory": ["issue", "scheduledChange", "accountNotification"]
}
}
# ---- 東京リージョンと us-east-1 の両方に同じルールを置き、自社のSNSトピックへ送る ----
for region in ap-northeast-1 us-east-1; do
aws events put-rule --region "$region" \
--name health-to-vendor \
--event-pattern file://health-rule.json
aws events put-targets --region "$region" \
--rule health-to-vendor \
--targets "Id=ops-sns,Arn=arn:aws:sns:${region}:111122223333:ops-alerts"
done
us-east-1にもルールを置くのは、IAMのようにリージョンに属さないグローバルイベントがus-east-1のルールでしか受け取れないためです。リージョンの選び方の説明では、各リージョンのイベントはバックアップとして米国西部（オレゴン）にも配信されます。オレゴンにもルールを置いて冗長化するなら、重複の除去に使う値はdetail.communicationIdです。SNSトピックは各リージョンに作り、トピックポリシーでEventBridgeからの発行を許可しておきます。Health Dashboardの見方とAPIでの取得はAWS Health Dashboardの使い方｜障害通知の自動化とAPI実装で扱っています。
アラーム通知のSNSトピックは自社所有にし、委託先を購読者として加える構成
CloudWatchアラームのアクションの送信先も、同じ自社のSNSトピックです。委託先の受付窓口はメールアドレスかHTTPSエンドポイントとして購読させ、自社の担当者も同じトピックを購読します。委託先のアカウントから購読を張らせる場合は、トピックポリシーで委託先アカウントにsns:Subscribeを許可します。
この構成にしておくと、委託先を替える日にやることは購読の付け替えだけです。アラームの閾値や対象メトリクスは自社のアカウントに残るため、新しい委託先は同じ設定を引き継げます。Lambdaのログからアラームを作る具体例はAWS Lambdaのログ運用ガイドにまとめています。
パッチ適用の分担＝Patch Managerのベースラインを自社で決め実行を任せる設計
パッチ適用は、委託先が最も頻繁に手を動かす作業です。承認の基準を発注側が持つかどうかで、障害が起きたときの説明責任の所在が変わります。
自社のパッチ承認条件を定義するcreate-patch-baselineの実行例
AWS Systems Manager Patch Managerのドキュメントは、パッチ準拠の基準はAWSもOSベンダーも定めず、利用者がパッチベースラインで定義するものだと書いています。AWSが用意する定義済みベースラインは例であって推奨設定ではないとし、カスタムベースラインの作成を勧めています。
# Amazon Linux 2023 向け：重大度 Critical と Important のセキュリティ更新を、公開7日後に自動承認する
aws ssm create-patch-baseline \
--name "al2023-security-7days" \
--operating-system AMAZON_LINUX_2023 \
--approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=CLASSIFICATION,Values=[Security]},{Key=SEVERITY,Values=[Critical,Important]}]},ApproveAfterDays=7}]" \
--description "Security updates approved 7 days after release"
ベースラインの作成と変更は自社の権限に残し、委託先の作業用ロールには、スキャンとインストールの実行だけを許可します。実行の仕組みは、AWSが推奨するQuick Setupのパッチポリシー、メンテナンスウィンドウ、即時実行の「Patch now」から選べます。どれを使うかは委託先に任せてかまいません。
Patch Managerがしないこと＝事前検証なし・OSメジャー更新なしの契約への反映
同じドキュメントには、AWSはPatch Managerで配るパッチを事前にテストしないこと、Windows Server 2016から2019やRHEL 7から8のようなOSのメジャーバージョン更新には対応しないことが書かれています。重大度もOSベンダーが付けた値をそのまま使い、CVSSやNVDの値からは判定しません。
つまり「Patch Managerで自動化している」という委託先の説明だけでは、検証の工程は誰も持っていない可能性があります。契約書か運用手順書に、検証環境へ先に当てる日数、本番適用の曜日と時間帯、メジャー更新は別作業として見積もること、の3点を書いておきます。
委託先の操作を監査する仕組み＝CloudTrailのイベント履歴と証跡の保存先
委託先が何をしたかを、委託先の報告書ではなく自社のログで確かめられる状態にしておきます。
委託先ロールのAssumeRoleをlookup-eventsで抽出する確認コマンド
CloudTrailのイベント履歴は、設定しなくても有効で、閲覧に料金はかかりません。対象は管理イベントの過去90日分で、検索はリージョン単位、属性の絞り込みは1つまでという制限があります。
# 委託先がいつロールを引き受けたかを、東京リージョンの履歴から一覧にする
aws cloudtrail lookup-events \
--region ap-northeast-1 \
--lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
--start-time 2026-10-01T00:00:00Z \
--query "Events[].{time:EventTime,user:Username,resources:Resources[].ResourceName}" \
--output json
引き受けた後の個々の操作は、各イベントの詳細（CloudTrailEvent）にあるuserIdentity.arnに、ロール名とセッション名を含むassumed-roleのARNとして記録されます。誰の操作かまで追うには、セッション名に担当者を識別できる値を入れるよう委託先と取り決めておくことが必要です。引数の一覧はlookup-eventsのリファレンスにあります。
90日を超える記録の保存と、委託先ロールに付ける明示的Denyの範囲
90日より前の記録や、データイベントを残すには、証跡を作って自社のS3バケットへ出力します。証跡の設計と料金はCloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成で解説しました。そのうえで作業用ロールに、記録を止める操作と、長期認証情報を作る操作を禁じるインラインポリシーを付けます。
# ---- deny-guardrails.json ----
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAuditTampering",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail",
"cloudtrail:PutEventSelectors"
],
"Resource": "*"
},
{
"Sid": "DenyLongTermCredentials",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"iam:UpdateAssumeRolePolicy"
],
"Resource": "*"
}
]
}
aws iam put-role-policy \
--role-name VendorOpsWork \
--policy-name deny-guardrails \
--policy-document file://deny-guardrails.json
明示的なDenyは、同じロールに付いた他のポリシーのAllowより優先されます。iam:UpdateAssumeRolePolicyを禁じているのは、委託先が自分のロールの信頼ポリシーを書き換えて外部IDの条件を外すことを防ぐためです。AWS Organizationsを使っているなら、同じ禁止をSCPで組織全体に掛ける方法もあり、書き方はAWS SCPの書き方と適用手順で扱っています。
受け入れ設定を自社で組むべき場面と、委託先のテンプレートに任せてよい条件
多くの運用代行会社は、ロール作成用のCloudFormationテンプレートを用意しています。これを流すかどうかは、中身で決めます。
委託先のCloudFormationテンプレートをそのまま流してよい条件と見送る条件
そのまま流してよいのは、信頼ポリシーにsts:ExternalIdの条件があり、Principalが委託先アカウントだけで、付与する権限がAdministratorAccessではなく、流した後に自社のDenyポリシーを足せる場合です。この4つが揃っていれば、自前で書き直す手間に見合う差はありません。
次のどれかに当たるテンプレートは流しません。AdministratorAccessを付けている、外部IDの条件がない、IAMユーザーやアクセスキーの作成を求めている、ログや通知の行き先が委託先のアカウントにしかない。いずれも、解約や事故の後に発注側が経緯を確かめられなくなる構成です。
反対に、EC2が数台で、委託するのが監視と一次連絡だけなら、作業用ロールは作らなくてかまいません。閲覧用ロールとSNSの購読だけを渡し、復旧作業は自社で行うほうが、権限の管理も契約も小さく済みます。委託先の選び方そのものはMSPとは？マネージドサービスプロバイダーの役割・SIerとの違いと委託判断を参照してください。
委託先の切り替えと解約で行うロール削除と外部ID更新のオフボーディング
委託先を替えるときは、旧委託先の入口を閉じてから新委託先に引き継ぎます。順番は次のとおりです。
- 新委託先からアカウントIDと外部IDを受け取り、新しいロールを作って受け入れテストを通す
- 旧委託先のロールに付いたポリシーを外し、
aws iam delete-roleでロールを削除する - SNSトピックから旧委託先の購読を削除し、新委託先の窓口を購読させる
- CloudTrailのイベント履歴で、削除した日以降に旧ロールのAssumeRoleが記録されていないことを確かめる
同じ委託先との契約を続ける場合でも、担当チームの入れ替えや外部IDの漏えいが疑われるときは、委託先に外部IDを再発行してもらい信頼ポリシーを更新します。初期構築の段階でアカウント構成から組み直したい場合はAWS導入支援の中身：初期構築の範囲と成果物をCLIで検収する手順が参照先です。受け入れ設定や監視の設計を含めて相談したい場合は、一創のインフラ構築（AWS・Google Cloud・Azure）で対応しています。
よくある質問
AWS運用代行の受け入れ設定について、発注側の担当者からよく出る質問をまとめました。
AWS運用代行の委託先に管理者権限を渡しても問題ありませんか？
渡さないでください。AdministratorAccessを持つロールは、CloudTrailの証跡を止め、IAMユーザーを作り、自分の信頼ポリシーも書き換えられます。委託先に悪意がなくても、委託先の端末や認証情報が侵害されたときの被害範囲が自社アカウント全体に広がります。閲覧用と作業用に分け、作業用ロールには手順書に載った操作だけを許可し、記録の停止と長期認証情報の作成を明示的なDenyで禁じる構成を基本にしてください。
外部IDは自社で決めて委託先に伝えてもよいですか？
勧めません。外部IDが混乱した代理問題を防げるのは、委託先が顧客ごとに一意の値を発行し、呼び出すときに必ずその値を付けるからです。発注側が決めた値では、別の顧客と同じ値になる可能性を委託先が管理できません。AWSのドキュメントも、外部IDは委託先が生成するものとしています。委託先が外部IDを提示しない場合は、多数の顧客アカウントを安全に扱う仕組みを持っているかを確認する材料にしてください。
AWSサポートへの問い合わせは委託先に任せられますか？
任せられますが、契約の形で窓口が変わります。自社でサポートプランを契約するなら、委託先のロールに付けるのはサポートケースの起票権限です。AWSサポートプランの公式説明では、2026年10月時点でBusiness Support+はアカウントあたり月29ドルからで、DeveloperとBusinessは2027年1月1日に終了します。委託先がAWSパートナーとしてPartner-Led Supportを提供している場合は、問い合わせの窓口は委託先です。プラン選びと費用は16410の記事で比較しています。
AWS Organizationsで複数アカウントを持つ場合も同じ設定でよいですか？
考え方は同じですが、設定する場所が変わります。AWS Healthは組織ビューで管理アカウントか委任管理者に集約でき、Patch ManagerのパッチポリシーはQuick Setupから組織全体やOU単位で配れます。証跡についても、組織の証跡にまとめることが可能です。委託先のアクセスは、アカウントごとにロールを作る代わりにIAM Identity Centerの権限セットで渡す方法もあります。禁止事項はSCPで組織全体に掛けると、アカウントを追加したときの付け忘れを防げます。
委託先が約束どおり作業したかを月次で確認する方法はありますか？
確認の方法は、2つの記録を突き合わせることです。1つはCloudTrailで、委託先ロールのAssumeRoleと、その後の操作が作業報告の日時と一致しているかを見ます。もう1つはPatch Managerの準拠レポートで、スキャン結果をCSVで自社のS3バケットへ定期出力することが可能です。未適用のパッチが残っているノードと、レポートの取得時刻を確認すれば、パッチ適用の実施状況を委託先の報告書に頼らずに確かめられます。どちらも委託先に削除権限を渡していないことが前提です。
関連記事
- AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準：委託する作業の範囲、費用相場、SLAの決め方。
- AWS導入支援の中身：初期構築の範囲と成果物をCLIで検収する手順・委託先の選び方：運用代行の前段にある初期構築の検収。
- AWS Health Dashboardの使い方｜障害通知の自動化とAPI実装：Health通知の受け取り方の詳細。
- CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説：委託先の操作を残す証跡の設計。
- MSPとは？マネージドサービスプロバイダーの役割・SIerとの違いと委託判断を発注者視点で解説：委託先の種類と選び方。
