🔗connecting-to-data-source
- プラグイン
- aws-data-analytics
- 引数
- [source-type|connection-name|hostname]
- ソース
- GitHub で見る ↗
説明
JDBC データベース(Oracle、SQL Server、PostgreSQL、MySQL、RDS)、Redshift、Snowflake、BigQuery への AWS Glue 接続の作成およびトラブルシューティングを行います。 ユーザーから接続に必要なヒントを収集し、既存の接続や RDS/Redshift の候補を検出します。また、Secrets Manager または IAM DB 認証による認証情報の登録、VPC の設定、および接続テストを実施します。 次のような場合に使用: - データベースへの接続 - Glue 接続のセットアップ - データソースの登録 - Snowflake / BigQuery / RDS への接続 - 接続タイムアウトの発生 - 接続テストの実行 - 接続に関するトラブルシューティング **以下の用途には使用しないでください:** - データの移動(`ingesting-into-data-lake` を使用) - テーブルの作成(`creating-data-lake-table` を使用) - クエリの実行(`querying-data-lake` を使用) - カタログの探索(`exploring-data-catalog` を使用) - SaaS サービスへの接続(Salesforce、ServiceNow、SAP、MongoDB、Kafka など)
原文を表示
Create and troubleshoot AWS Glue connections to JDBC databases (Oracle, SQL Server, PostgreSQL, MySQL, RDS), Redshift, Snowflake, and BigQuery. Gathers connection hints from user, discovers existing connections and RDS/Redshift candidates, registers credentials in Secrets Manager or IAM DB auth, configures VPC, and tests. Triggers on: connect to database, set up Glue connection, register data source, connect to Snowflake/BigQuery/RDS, connection timeout, test connection, troubleshoot connection. Do NOT use for moving data (use ingesting-into-data-lake), creating tables (use creating-data-lake-table), queries (use querying-data-lake), catalog exploration (use exploring-data-catalog), or SaaS (Salesforce, ServiceNow, SAP, MongoDB, Kafka).
ユースケース
- ✓データベースへの接続をセットアップする
- ✓Glue接続のトラブルシューティングを行う
- ✓接続タイムアウトの問題を解決する
- ✓認証情報をSecrets Managerに登録する
- ✓接続テストを実行する
本文(日本語訳)
データソースへの接続
外部データソースをAWS Glueに登録し、後続のスキル(ingesting-into-data-lake)がそこからデータを移動できるようにします。 Glue connectionは、1つのソースに対するネットワーク設定・ドライバ・認証情報の参照先を保存します。 ソースごとに一度作成すれば、複数のジョブで再利用できます。
設計思想
connectionは「名前付きパイプ」であり、「パイプライン」ではありません。 このスキルは、テスト済みで再利用可能なGlue connectionを作成します。データの移動は行いません。
共通事項
MCPサーバーに接続している場合、コマンドの実行には必ずAWS MCPサーバーのツールを使用してください。 MCPサーバーツールはバリデーション・サンドボックス実行・監査ログを提供します。 MCPが利用できない場合のみ、AWS CLIへフォールバックしてください。 各ステップを実行する前に、必ずその内容をユーザーに説明してください。
ワークフロー
1. 依存関係とコンテキストの確認
- AWS MCPツールまたはAWS CLIが利用可能かどうかを確認し、利用できない場合はユーザーに通知してください
- 対象のAWSリージョンを確認し、
aws sts get-caller-identityで認証情報を検証してください
2. ソースの分類
ユーザーに接続先のソースタイプを確認するか、ヒントから推測してください:
| ユーザーの発言 | ソースタイプ | 接続タイプ | 参照先 |
|---|---|---|---|
| "Oracle"、"SQL Server"、"Postgres"、"MySQL"、"RDS <エンジン>" | JDBCデータベース | JDBC |
jdbc-setup.md |
| "Redshift"、"クラスター"、"AWSのデータウェアハウス" | Redshift | JDBC |
jdbc-setup.md(Redshiftセクション) |
| "Snowflake" | Snowflake | SNOWFLAKE |
snowflake-setup.md |
| "BigQuery"、"Googleアナリティクスのウェアハウス" | BigQuery | BIGQUERY |
bigquery-setup.md |
ユーザーがDynamoDBまたはローカルファイルを指定した場合は、処理を中断し以下を伝えてください: DynamoDBはconnectionなしでGlueから直接読み取れます。 ローカルファイルはingesting-into-data-lakeスキルのlocal-uploadワークフローで扱います。
3. ユーザーからの接続情報の収集
ユーザーが提供できるヒントを必ず確認してください。推測で補完しないでください。
すべてのソースに共通:
- 希望するconnection名(小文字・ハイフン区切り:
oracle-prod-sales、snowflake-analytics) - 既存のSecrets Managerシークレット、または新規作成の要否
- ソースがGlue VPCから到達可能か(同一VPC・VPCピアリング・VPN・Direct Connect)
JDBC: ホスト名/エンドポイント、ポート、データベース名、RDS/Aurora/セルフマネージドの区別、IAM DB認証の有効化(Aurora/RDS MySQL/PostgreSQL)、SSL要否
Snowflake: アカウント識別子、ウェアハウス、ロール、デフォルトデータベース、認証方式(パスワード・キーペア・OAuth)
BigQuery: GCPプロジェクトID、ロケーション、サービスアカウントJSONの準備状況
4. 既存のConnectionおよびソース候補の確認
作成前に既存のリソースを確認してください。
既存のGlue connectionの確認:
aws glue get-connections --filter ConnectionType=<TYPE> --region <REGION>
適切なconnectionが既に存在する場合は、ユーザーに確認のうえステップ7へスキップしてください。
アカウント内のソース候補の確認(JDBC/Redshiftのみ):
- RDS:
aws rds describe-db-instances - Aurora:
aws rds describe-db-clusters - Redshift:
aws redshift describe-clusters
候補をユーザーに提示し、選択してもらってください。discovery.md を参照してください。
5. 認証情報の登録
平文パスワードよりもAWS Secrets Managerの使用を強く推奨してください。 サポートされている場合(Aurora/RDS MySQL・PostgreSQL、Redshift)はIAMデータベース認証を優先してください。 credential-security.md を参照してください。
- 新しいSecrets Managerシークレットを作成する前に、必ずユーザーの確認を取ってください
- 平文の認証情報をチャットやログに書き込まないでください
- IAM DB認証を使用する場合、シークレットは不要です
6. Glue Connectionの作成
ソース種別ごとの参照ドキュメントに従って接続プロパティを設定してください:
aws glue create-connection --connection-input '<JSON>' --region <REGION>
プライベートなソースには PhysicalConnectionRequirements(SubnetId、SecurityGroupIdList、AvailabilityZone)が必要です。
network-setup.md を参照してください。
7. Connectionのテスト
引き渡し前に必ずテストを実施してください。テストはAPIチェックとエンジンレベルの検証の2フェーズで行います。
フェーズA: Glue TestConnection(ネットワークと認証情報の基本チェック)
aws glue test-connection --connection-name <NAME> --region <REGION>
Glueがソースに到達し認証できることを検証します。 ただし、ユーザーが実際に使用するクエリエンジンでエンドツーエンドに動作することは保証されません。
フェーズB: エンジンレベルの検証
TestConnectionが成功したら、ユーザーが使用予定のエンジンでconnectionが機能するか、最小限のクエリを実行して確認してください:
- Glue ETL(デフォルト): connectionを通じて1行読み取るスモークテスト用Glueジョブを実行する。troubleshooting.md を参照。
- Athena: フェデレーテッドコネクタ経由でAthenaからクエリする予定の場合、Athena connectionで
SELECT 1を実行し、Lambdaベースのコネクタがソースへアクセスできることを確認する。 - Glue Crawler: ソースをクロールする予定の場合、単一テーブルでテストクロールを実行する。
フェーズBは、TestConnectionでは検出できない問題を捉えます: ジョブ実行時のドライバ互換性、カタログ設定、Sparkレベルのシリアライゼーション、エンジン固有の認証フロー (例: SnowflakeのSNOWFLAKEタイプはETLでは動作するが、JDBCクローラーでは動作しない)。
両フェーズの成功時は、ingesting-into-data-lake で使用できるconnection名をユーザーに伝えてください。
いずれかのフェーズで失敗した場合は、ステップ8へ進んでください。
8. トラブルシューティング(テスト失敗時のみ)
ネットワーク → 認証情報 → ドライバの順に診断してください。 troubleshooting.md を参照してください。
制約事項:
- 認証情報を原因と断定する前に、VPCルーティング・セキュリティグループ・S3 VPCエンドポイントを必ず確認してください
- GlueロールがSecrets Managerシークレットを読み取れることを必ず確認してください
- ユーザーの確認なしに認証情報をローテーションしないでください
引数のルーティング
- 引数なし: ステップ1〜7をインタラクティブに進める
- ソースタイプのキーワード(例:
snowflake、oracle): ソースタイプを指定済みとしてステップ2へスキップ - 既存のconnection名: ステップ7(テスト)へスキップし、失敗時はステップ8へ
- ホスト名またはRDSエンドポイント: 候補を指定済みとしてステップ4へスキップ
注意事項
- GlueのSNOWFLAKE接続タイプは、Snowflake向けに設定したJDBCとは別物です。
Spark ETLジョブには必ず
SNOWFLAKEタイプを使用し、JDBCを使用しないでください。 - Connection名は変更できません。慎重に命名してください。
PhysicalConnectionRequirements.AvailabilityZoneはサブネットのAZと一致させる必要があります。 不一致の場合、connection作成時ではなくジョブ実行時に失敗します。- IAMデータベース認証トークンは15分で失効します。 Glueジョブは接続ごとにトークンを新規発行するため、キャッシュしないでください。
- プライベートソースのconnectionが使用するVPCには、S3 VPCゲートウェイエンドポイントが必須です。 これがないと、GlueジョブはスクリプトをS3から読み込めず、結果もS3に書き込めません。
トラブルシューティング
| エラー | 想定される原因 | 対処法 |
|---|---|---|
Connect timed out |
VPCルーティング、SGルール、またはNATゲートウェイの欠如 | troubleshooting.md を参照 |
Access denied for user / ORA-01017 |
認証情報の誤り、Secrets Managerへのアクセス欠如、またはIAM DB認証の設定ミス | troubleshooting.md を参照 |
No suitable driver found |
カスタムドライバJARが未設定またはクラス名が誤り | troubleshooting.md を参照 |
SSL handshake failed |
GlueとソースでJDBC_ENFORCE_SSLの設定が不一致 | troubleshooting.md を参照 |
UnableToFindVpcEndpoint |
S3 VPCエンドポイントが未作成 | connectionのVPCにS3ゲートウェイエンドポイントを作成する |
参考ドキュメント
- jdbc-setup.md -- Oracle、SQL Server、PostgreSQL、MySQL、RDS、Redshift
- snowflake-setup.md -- GlueのSNOWFLAKEタイプ、認証モード
- bigquery-setup.md -- GlueのBIGQUERYタイプ、GCPサービスアカウント
- discovery.md -- 既存connectionおよびソース候補の検索
- credential-security.md -- Secrets ManagerとIAM DB認証
- network-setup.md -- VPC、サブネット、セキュリティグループ、エンドポイント
- troubleshooting.md -- 接続エラーと診断フロー
原文(English)を表示
Connect to Data Source
Register an external data source with AWS Glue so downstream skills (ingesting-into-data-lake) can move data from it. A Glue connection stores the network config, driver, and credential reference for one source. Create once per source, reuse across jobs.
Philosophy
A connection is a named pipe, not a pipeline. This skill produces a tested, reusable Glue connection. It does not move data.
Common Tasks
You MUST execute commands using AWS MCP server tools when connected -- they provide validation, sandboxed execution, and audit logging. Fall back to AWS CLI only if MCP is unavailable. You MUST explain each step before executing.
Workflow
1. Verify Dependencies and Context
- You MUST check whether AWS MCP tools or AWS CLI are available and inform the user if missing
- You MUST confirm target AWS region and verify credentials with
aws sts get-caller-identity
2. Classify the Source
Ask the user which source type they want to connect to, or infer from hints:
| User says... | Source type | Connection type | Reference |
|---|---|---|---|
| "Oracle", "SQL Server", "Postgres", "MySQL", "RDS <engine>" | JDBC database | JDBC |
jdbc-setup.md |
| "Redshift", "my cluster", "my data warehouse on AWS" | Redshift | JDBC |
jdbc-setup.md (Redshift section) |
| "Snowflake" | Snowflake | SNOWFLAKE |
snowflake-setup.md |
| "BigQuery", "Google analytics warehouse" | BigQuery | BIGQUERY |
bigquery-setup.md |
If the user names DynamoDB or a local file, stop and tell them: DynamoDB is read directly by Glue without a connection, and local files belong in the ingesting-into-data-lake skill's local-upload workflow.
3. Gather Connection Hints from the User
You MUST ask for hints the user can provide -- do not guess.
For all sources:
- Desired connection name (lowercase, hyphens:
oracle-prod-sales,snowflake-analytics) - Existing Secrets Manager secret, or create one
- Is source reachable from a Glue VPC (same, peered, VPN, Direct Connect)
JDBC: hostname/endpoint, port, database, whether RDS/Aurora/self-managed, IAM DB auth enabled (Aurora/RDS MySQL/Postgres), SSL required.
Snowflake: account identifier, warehouse, role, default database, auth (password, key-pair, OAuth).
BigQuery: GCP project ID, location, whether service account JSON is provisioned.
4. Discover Existing Connections and Candidate Sources
Check what exists before creating.
Existing Glue connections:
aws glue get-connections --filter ConnectionType=<TYPE> --region <REGION>
If a suitable one exists, confirm and skip to Step 7.
Candidate sources in account (JDBC/Redshift only):
- RDS:
aws rds describe-db-instances - Aurora:
aws rds describe-db-clusters - Redshift:
aws redshift describe-clusters
Present candidates to user; let them pick. See discovery.md.
5. Register Credentials
You MUST encourage AWS Secrets Manager over plaintext passwords. You SHOULD prefer IAM database authentication where supported (Aurora/RDS MySQL and PostgreSQL, Redshift). See credential-security.md.
- You MUST confirm with user before creating a new Secrets Manager secret
- You MUST NOT write plaintext credentials into chat or logs
- For IAM DB auth, no secret is needed
6. Create the Glue Connection
Follow the source-specific reference for connection properties:
aws glue create-connection --connection-input '<JSON>' --region <REGION>
Private sources require PhysicalConnectionRequirements (SubnetId, SecurityGroupIdList, AvailabilityZone). See network-setup.md.
7. Test the Connection
You MUST test before handing off. Testing is two-phase: a quick API check, then an engine-level verification.
Phase A: Glue TestConnection (network and credential sanity check)
aws glue test-connection --connection-name <NAME> --region <REGION>
This validates that Glue can reach the source and authenticate. It does NOT prove the connection works end-to-end with the query engine the user plans to use.
Phase B: Engine-level verification
After TestConnection passes, verify the connection works with the user's intended engine by running a minimal query through it:
- Glue ETL (default): Run a smoke-test Glue job that reads one row via the connection. See troubleshooting.md.
- Athena: If the user plans to query via Athena with a federated connector, run a
SELECT 1through the Athena connection to confirm the Lambda-based connector can reach the source. - Glue Crawler: If the user plans to crawl the source, run a test crawl on a single table.
Phase B catches issues that TestConnection misses: driver compatibility at job runtime, catalog configuration, Spark-level serialization, and engine-specific auth flows (e.g., Snowflake SNOWFLAKE type works in ETL but not via JDBC crawlers).
On success in both phases, tell user the connection name is ready for ingesting-into-data-lake. On failure in either phase, Step 8.
8. Troubleshoot (only if test failed)
Diagnose in order: network, credentials, driver. See troubleshooting.md.
Constraints:
- You MUST check VPC routing, security groups, and S3 VPC endpoint before blaming credentials
- You MUST verify Glue role can read the Secrets Manager secret
- You MUST NOT rotate credentials without user confirmation
Argument Routing
- No args: Walk through Steps 1-7 interactively
- Source type keyword (e.g.,
snowflake,oracle): Skip to Step 2 with the type prefilled - Existing connection name: Skip to Step 7 (test) then Step 8 if failing
- Hostname or RDS endpoint: Skip to Step 4 with the candidate prefilled
Gotchas
- Glue's
SNOWFLAKEconnection type is distinct fromJDBCconfigured for Snowflake. You MUST useSNOWFLAKEfor Spark ETL jobs; do not use JDBC. - Connection names are immutable. Choose carefully.
PhysicalConnectionRequirements.AvailabilityZoneMUST match the subnet's AZ or the connection fails at job runtime, not creation time.- IAM database authentication tokens expire in 15 minutes. The Glue job generates a fresh token on each connection; do not cache.
- An S3 VPC gateway endpoint MUST exist in the VPC used by private-source connections. Without it, Glue jobs cannot read their scripts or write results to S3.
Troubleshooting
| Error | Likely cause | Fix |
|---|---|---|
Connect timed out |
VPC routing, SG rule, or NAT gateway missing | See troubleshooting.md |
Access denied for user / ORA-01017 |
Credentials wrong, Secrets Manager access missing, or IAM DB auth misconfigured | See troubleshooting.md |
No suitable driver found |
Custom driver JAR not set or wrong class name | See troubleshooting.md |
SSL handshake failed |
JDBC_ENFORCE_SSL mismatch between Glue and source |
See troubleshooting.md |
UnableToFindVpcEndpoint |
S3 VPC endpoint missing | Create S3 gateway endpoint in the connection's VPC |
References
- jdbc-setup.md -- Oracle, SQL Server, PostgreSQL, MySQL, RDS, Redshift
- snowflake-setup.md -- Glue
SNOWFLAKEtype, auth modes - bigquery-setup.md -- Glue
BIGQUERYtype, GCP service accounts - discovery.md -- Finding existing connections and candidate sources
- credential-security.md -- Secrets Manager and IAM DB auth
- network-setup.md -- VPC, subnets, security groups, endpoints
- troubleshooting.md -- Connection errors and diagnostic flow
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。