AWS Glueのデータベース接続を作成・トラブルシューティングします。Oracle、SQL Server、PostgreSQL、MySQLといったJDBC(プログラムからデータベースにアクセスするための標準インターフェース)形式のデータベース、Redshift、Snowflake、BigQueryに対応しています。 ユーザーから接続に必要な情報を集め、既存の接続やRDS・Redshift の候補を自動で検出します。その後、認証情報をSecrets Manager(認証情報管理サービス)またはIAM DB認証に登録し、VPC(仮想ネットワーク)を設定して接続をテストします。 **次のような場合に使用:** - データベースに接続したい - Glue接続を設定したい - データソースを登録したい - Snowflake、BigQuery、RDSに接続したい - 接続がタイムアウトしている - 接続をテストしたい - 接続に関する問題を解決したい **このスキルで行わないこと:** データの移動(データ移行スキルを使用)、テーブル作成(データレイク テーブル作成スキルを使用)、データクエリ(データクエリスキルを使用)、データカタログの確認(カタログ探索スキルを使用)、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).
外部データソースをAWS Glueに登録し、後続のスキル(ingesting-into-data-lake)がそこからデータを移動できるようにします。 Glue connectionは、1つのソースに対するネットワーク設定・ドライバ・認証情報の参照先を保存します。 ソースごとに一度作成すれば、複数のジョブで再利用できます。
connectionは「名前付きパイプ」であり、「パイプライン」ではありません。 このスキルは、テスト済みで再利用可能なGlue connectionを作成します。データの移動は行いません。
MCPサーバーに接続している場合、コマンドの実行には必ずAWS MCPサーバーのツールを使用してください。 MCPサーバーツールはバリデーション・サンドボックス実行・監査ログを提供します。 MCPが利用できない場合のみ、AWS CLIへフォールバックしてください。 各ステップを実行する前に、必ずその内容をユーザーに説明してください。
aws sts get-caller-identity で認証情報を検証してくださいユーザーに接続先のソースタイプを確認するか、ヒントから推測してください:
| ユーザーの発言 | ソースタイプ | 接続タイプ | 参照先 |
|---|---|---|---|
| "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ワークフローで扱います。
ユーザーが提供できるヒントを必ず確認してください。推測で補完しないでください。
すべてのソースに共通:
oracle-prod-sales、snowflake-analytics)JDBC: ホスト名/エンドポイント、ポート、データベース名、RDS/Aurora/セルフマネージドの区別、IAM DB認証の有効化(Aurora/RDS MySQL/PostgreSQL)、SSL要否
Snowflake: アカウント識別子、ウェアハウス、ロール、デフォルトデータベース、認証方式(パスワード・キーペア・OAuth)
BigQuery: GCPプロジェクトID、ロケーション、サービスアカウントJSONの準備状況
作成前に既存のリソースを確認してください。
既存のGlue connectionの確認:
aws glue get-connections --filter ConnectionType=<TYPE> --region <REGION>
適切なconnectionが既に存在する場合は、ユーザーに確認のうえステップ7へスキップしてください。
アカウント内のソース候補の確認(JDBC/Redshiftのみ):
aws rds describe-db-instancesaws rds describe-db-clustersaws redshift describe-clusters候補をユーザーに提示し、選択してもらってください。discovery.md を参照してください。
平文パスワードよりもAWS Secrets Managerの使用を強く推奨してください。 サポートされている場合(Aurora/RDS MySQL・PostgreSQL、Redshift)はIAMデータベース認証を優先してください。 credential-security.md を参照してください。
ソース種別ごとの参照ドキュメントに従って接続プロパティを設定してください:
aws glue create-connection --connection-input '<JSON>' --region <REGION>
プライベートなソースには PhysicalConnectionRequirements(SubnetId、SecurityGroupIdList、AvailabilityZone)が必要です。
network-setup.md を参照してください。
引き渡し前に必ずテストを実施してください。テストはAPIチェックとエンジンレベルの検証の2フェーズで行います。
aws glue test-connection --connection-name <NAME> --region <REGION>
Glueがソースに到達し認証できることを検証します。 ただし、ユーザーが実際に使用するクエリエンジンでエンドツーエンドに動作することは保証されません。
TestConnectionが成功したら、ユーザーが使用予定のエンジンでconnectionが機能するか、最小限のクエリを実行して確認してください:
SELECT 1 を実行し、Lambdaベースのコネクタがソースへアクセスできることを確認する。フェーズBは、TestConnectionでは検出できない問題を捉えます: ジョブ実行時のドライバ互換性、カタログ設定、Sparkレベルのシリアライゼーション、エンジン固有の認証フロー (例: SnowflakeのSNOWFLAKEタイプはETLでは動作するが、JDBCクローラーでは動作しない)。
両フェーズの成功時は、ingesting-into-data-lake で使用できるconnection名をユーザーに伝えてください。
いずれかのフェーズで失敗した場合は、ステップ8へ進んでください。
ネットワーク → 認証情報 → ドライバの順に診断してください。 troubleshooting.md を参照してください。
制約事項:
snowflake、oracle): ソースタイプを指定済みとしてステップ2へスキップSNOWFLAKE タイプを使用し、JDBCを使用しないでください。PhysicalConnectionRequirements.AvailabilityZone はサブネットのAZと一致させる必要があります。
不一致の場合、connection作成時ではなくジョブ実行時に失敗します。| エラー | 想定される原因 | 対処法 |
|---|---|---|
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ゲートウェイエンドポイントを作成する |
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.
A connection is a named pipe, not a pipeline. This skill produces a tested, reusable Glue connection. It does not move data.
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.
aws sts get-caller-identityAsk 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.
You MUST ask for hints the user can provide -- do not guess.
For all sources:
oracle-prod-sales, snowflake-analytics)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.
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):
aws rds describe-db-instancesaws rds describe-db-clustersaws redshift describe-clustersPresent candidates to user; let them pick. See discovery.md.
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.
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.
You MUST test before handing off. Testing is two-phase: a quick API check, then an engine-level verification.
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.
After TestConnection passes, verify the connection works with the user's intended engine by running a minimal query through it:
SELECT 1 through the Athena connection to confirm the Lambda-based connector can reach the source.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.
Diagnose in order: network, credentials, driver. See troubleshooting.md.
Constraints:
snowflake, oracle): Skip to Step 2 with the type prefilledSNOWFLAKE connection type is distinct from JDBC configured for Snowflake. You MUST use SNOWFLAKE for Spark ETL jobs; do not use JDBC.PhysicalConnectionRequirements.AvailabilityZone MUST match the subnet's AZ or the connection fails at job runtime, not creation time.| 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 |
SNOWFLAKE type, auth modesBIGQUERY type, GCP service accounts原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。