こんにちは。XI2部の山科です。
Amazon Quick Automate を使ってブラウザ操作の自動化を試していると、「送信元 IP が毎回変わる」という問題に気付きました。社内システムや IP 制限をかけた Web サイトを自動操作したい場合、送信元 IP が固定されていないと困ります。
今回は VPC Connection を使って Quick Automate の通信を自社の VPC 経由にルーティングし、NAT Gateway の固定 Elastic IP（EIP）から社内サイトにアクセスできるかを検証しました。
Amazon Quick AutomateのVPC Connectionとは
Amazon Quick Automate の UI Agent（ブラウザ自動化エージェント）は、デフォルトでは AWS が管理するインフラ上でブラウザを動かします。この場合、送信元 IP は都度変わるため、IP アドレスで制限されたサイトには到達できません。
VPC Connection を設定すると、ブラウザのアウトバウンド通信がすべて 指定した VPC 内の ENI（Elastic Network Interface）経由になります。VPC 内の NAT Gateway を経由させれば、送信元 IP を固定 EIP に統一できます。
UI Agent（マネージドブラウザ） ↓ VPC Connection（ENI作成） プライベートサブネット ↓ NAT Gateway（固定EIP） ↓ インターネット → ターゲットサイト
検証構成
今回は 2 アカウント構成で検証しました。
【Account A: Quick Automate アカウント（us-east-1）】
Amazon Quick Automate
│ VPC Connection（プライベートサブネットに ENI 作成）
VPC (10.0.0.0/16)
├── PublicSubnet (10.0.1.0/24) - NAT GW
├── PrivateSubnet1 (10.0.2.0/24) - Quick Automate ENI 用
└── PrivateSubnet2 (10.0.3.0/24) - Quick Automate ENI 用
│
▼ NAT GW（EIP: x.x.x.x）→ インターネット
│
【Account B: EC2 アカウント（ap-northeast-1）】
EC2（パブリックIP: y.y.y.y）
Nginx: x.x.x.x のみ HTTP 許可、それ以外は 403
テストサイト: ログイン → ダッシュボード → 承認ボタン操作
Account B は「特定 IP からしかアクセスできない社内 Web サイト」の代替として用意しました。Account A の NAT Gateway EIP（x.x.x.x）からのアクセスだけを Nginx で許可し、それ以外の IP には 403 を返す構成です。
Step 1: インフラの準備
VPC・サブネット・NAT Gateway・EC2 は CloudFormation で作成しました。
Account A（Quick Automate アカウント、us-east-1）
| リソース | 内容 |
|---|---|
| VPC | 10.0.0.0/16 |
| パブリックサブネット | 10.0.1.0/24（NAT GW 配置） |
| プライベートサブネット1 | 10.0.2.0/24（us-east-1a、Quick Automate ENI 用） |
| プライベートサブネット2 | 10.0.3.0/24（us-east-1b、Quick Automate ENI 用） |
| NAT Gateway | 固定 EIP（x.x.x.x）付き |
| セキュリティグループ | インバウンド: なし / アウトバウンド: TCP 80（HTTP）許可 |
Account B（EC2 アカウント、ap-northeast-1）
| リソース | 内容 |
|---|---|
| EC2 | パブリック IP: y.y.y.y |
| Nginx | Account A の NAT Gateway EIP（x.x.x.x）のみ HTTP 許可、それ以外は 403 |
| テストサイト | ログイン → ダッシュボード → 承認ボタン操作 |
IP制限の動作確認
デプロイ後、自 PC から curl でアクセスして IP 制限が効いているか確認します。
curl -I http://y.y.y.y # → HTTP/1.1 403 Forbidden
自 PC からは 403 が返り、制限が正しく機能していることが確認できました。
Step 2: IAM ロールの作成
Quick Automate が VPC 内に ENI を作成するために、quicksight.amazonaws.com を信頼した IAM ロールが必要です。
Account A の CloudShell で作成します。
cat > trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "quicksight.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}
EOF
aws iam create-role \
--role-name QuickAutomateVpcConnectionRole \
--assume-role-policy-document file://trust-policy.json
aws iam put-role-policy \
--role-name QuickAutomateVpcConnectionRole \
--policy-name QuickAutomateVpcConnectionPolicy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeNetworkInterfaces",
"ec2:ModifyNetworkInterfaceAttribute",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}]
}'
Step 3: VPC Connectionの作成
Amazon Quick のアカウント管理画面から VPC Connection を作成します。
「Quick を管理」→「VPC 接続の管理」→「VPC 接続を追加」 の順に進みます。
| 項目 | 設定値 |
|---|---|
| VPC 接続名 | quick-automate-test-vpc-conn |
| VPC ID | vpc-xxxxxxxxxxxxxxxxx |
| サブネット（us-east-1a） | subnet-xxxxxxxxxxxxxxxxx |
| サブネット（us-east-1b） | subnet-xxxxxxxxxxxxxxxxx |
| セキュリティグループ | sg-xxxxxxxxxxxxxxxxx |
| 実行ロール | QuickAutomateVpcConnectionRole |
「追加」を押すと ENI の作成が始まり、数分でステータスが AVAILABLE になります。
Step 4: Automation GroupへのVPC Connection紐付け
VPC Connection を作成しただけでは、オートメーションはまだ VPC 経由で動きません。Automation Group に紐付ける必要があります。
ここが今回の検証でもっとも分かりにくかった部分です。
Automations → Groups タブ → グループを選択 → Details の「VPC Connection」右の鉛筆アイコンから設定できます。
VPC Connection は アカウント全体ではなくグループ単位で設定します。同じグループ内のすべてのオートメーションが指定した VPC Connection を使うようになります。
なお、オートメーション作成時に表示される「Group: ...」ドロップダウンでグループとの紐付けが決まります。デフォルトでは自動作成されたグループ（[ユーザー名]'s group）が選択されるようです。
Step 5: オートメーションの作成と実行
UI Agent の設定
Visual Designer で UI Agent をキャンバスに配置し、Instruction に実行内容を記述します。
Instruction フィールドは式モード（Python）で動作するため、テキストを直接入力すると「Invalid expression」エラーになります。トリプルクォートで囲むことで解決しました。
"""http://y.y.y.y/index.html にアクセスし、usernameにadmin、passwordにpassword123を入力してログインする。ダッシュボードに遷移したら、1002行の承認ボタンをクリックし、結果メッセージに承認しましたが表示されることを確認する。"""
実行結果
Debug で実行すると、UI Streaming でブラウザの動きがリアルタイムに確認できます。
実行ログには以下が記録されていました。
Navigating to http://y.y.y.y/index.html → ログインページへのアクセス: 200 OK → admin / password123 でログイン成功 → ダッシュボードへ遷移 → 注文 #1002 の承認ボタンをクリック → 結果メッセージ「注文 #1002 を承認しました。」を確認
検証結果：Nginxアクセスログでの確認
最終確認として、EC2 の Nginx アクセスログを確認しました。
z.z.z.z - ... "GET / HTTP/1.1" 403 ← その他のIP（拒否） z.z.z.z - ... "GET / HTTP/1.1" 403 ← その他のIP（拒否） x.x.x.x - ... "GET /index.html HTTP/1.1" 200 ← NAT Gateway EIP（許可）✓ x.x.x.x - ... "GET /dashboard.html HTTP/1.1" 200 ← NAT Gateway EIP（許可）✓
Account A の NAT Gateway EIP（x.x.x.x）からのアクセスが 200 OK で記録されており、他の IP はすべて 403 のままでした。VPC Connection 経由でのみアクセスが通っていることが確認できました。
検証ポイントまとめ
| 確認項目 | 結果 |
|---|---|
| 自 PC → テストサイト | 403 Forbidden ✓ |
| Quick Automate → テストサイト | 200 OK ✓ |
| Nginx ログの Source IP | NAT Gateway EIP（x.x.x.x）と一致 ✓ |
| ログイン → ダッシュボード遷移 | 正常完了 ✓ |
| ダッシュボードのボタン操作 | 「注文 #1002 を承認しました。」表示 ✓ |
まとめ
- Amazon Quick Automate の UI Agent は、デフォルトでは送信元 IP が固定されない
- VPC Connection を設定することで、すべてのアウトバウンド通信を VPC 経由にルーティングできる
- NAT Gateway と組み合わせることで送信元 IP を固定 EIP に統一できる
- VPC Connection は Automation Group 単位で紐付ける（アカウント全体への一括適用ではない）
- Instruction フィールドは式モードで動作するため、プレーンテキストを入力する際はトリプルクォートで囲む必要がある
IP 制限がかかっている社内システムや SaaS を Quick Automate で自動化したい場合は、この VPC Connection の設定が必須になります。
