Database Relazionale Python

Questo generatore crea un nuovo progetto database relazionale Python supportato da Amazon Aurora (PostgreSQL o MySQL), SQLModel per la modellazione dei dati e Alembic per le migrazioni dello schema. Genera il codice dell’applicazione e l’infrastruttura necessari per il provisioning e la gestione di un database utilizzando AWS CDK o Terraform, con definizione dello schema dichiarativa, distribuzione automatica delle migrazioni e un client database.

Utilizzo

Genera un Database Relazionale

CLI

pnpm

pnpm nx g @aws/nx-plugin:py#rdb

yarn

yarn nx g @aws/nx-plugin:py#rdb

npm

npx nx g @aws/nx-plugin:py#rdb

bun

bunx nx g @aws/nx-plugin:py#rdb

Puoi anche eseguire una prova per vedere quali file verrebbero modificati

pnpm

pnpm nx g @aws/nx-plugin:py#rdb --dry-run

yarn

yarn nx g @aws/nx-plugin:py#rdb --dry-run

npm

npx nx g @aws/nx-plugin:py#rdb --dry-run

bun

bunx nx g @aws/nx-plugin:py#rdb --dry-run

VSCode

1. Installa il Nx Console VSCode Plugin se non l'hai già fatto
2. Apri la console Nx in VSCode
3. Clicca su Generate (UI) nella sezione "Common Nx Commands"
4. Cerca @aws/nx-plugin - py#rdb
5. Compila i parametri richiesti
6. Clicca su Generate

Opzioni

Parametro	Tipo	Predefinito	Descrizione
name Obbligatorio	string	-	Nome del progetto database da generare
directory	string	packages	La directory in cui memorizzare l'applicazione.
subDirectory	string	-	La sottodirectory in cui viene posizionato il progetto. Per impostazione predefinita corrisponde al nome del progetto.
infra	aurora | none	aurora	Servizio di database relazionale da fornire.
engine	postgres | mysql	postgres	Motore di database da utilizzare con il servizio selezionato.
databaseUser	string	dbadmin	Nome utente amministratore del database. Il valore predefinito è 'dbadmin'.
databaseName	string	-	Nome del database iniziale. Il valore predefinito corrisponde al nome del progetto.
framework	sqlmodel	sqlmodel	Framework ORM da utilizzare per il progetto generato.
iac	inherit | cdk | terraform	inherit	Il provider IaC preferito. Per impostazione predefinita viene ereditato dalla selezione iniziale.
preferInstallDependencies	boolean	true	Se preferire l'installazione delle dipendenze dopo l'esecuzione del generatore. Impostare su false per rimandare l'installazione quando si eseguono più generatori in batch (l'installazione viene comunque eseguita se necessaria affinché i generatori successivi possano calcolare il grafo del progetto Nx); installare una volta alla fine.

Output del Generatore

Il generatore crea la seguente struttura di progetto nella directory <directory>/<name>:

• Directory<name>

  • __init__.py Package exports (get_engine, session_context)
  • connection.py Database engine and session factory with IAM authentication
  • utils.py Runtime config and local development helpers
  • migration_handler.py Lambda handler that runs Alembic migrations during deployment
  • create_db_user_handler.py Lambda handler that creates the application database user during deployment
  • Directorymodels

    • example.py Example SQLModel table definition
• Directorymigrations

  • versions Alembic-generated migration scripts
  • env.py Alembic environment (connects to the database)
  • script.py.mako Alembic migration script template
• alembic.ini Alembic configuration
• config.json Local development connection details and runtime config key
• Dockerfile.migration Container image for the migration handler
• Dockerfile.create-db-user Container image for the create-db-user handler
• project.json Project configuration and build targets

Gli script di sviluppo locale sono condivisi tra tutti i progetti database e generati in packages/common/scripts/:

• Directorypackages/common/scripts/src/rdb

  • pull-image.ts Pulls the database container image
  • start-container.ts Starts a local database container
  • wait-for-postgres-db.ts Waits for the local database to be ready (PostgreSQL)
  • wait-for-mysql-db.ts Waits for the local database to be ready (MySQL)

Infrastruttura

Poiché questo generatore fornisce infrastruttura come codice basata sul tuo iac scelto, creerà un progetto in packages/common che include i costrutti CDK o i moduli Terraform pertinenti.

Il progetto comune di infrastruttura come codice è strutturato come segue:

CDK

• Directorypackages/common/constructs

  • Directorysrc

    • Directoryapp/ Constructs for infrastructure specific to a project/generator

      • …
    • Directorycore/ Generic constructs which are reused by constructs in app

      • …
    • index.ts Entry point exporting constructs from app
  • project.json Project build targets and configuration

Progetto Generato

Questo progetto è generato utilizzando il generatore ts#project e quindi configura gli stessi target di build.

Terraform

• Directorypackages/common/terraform

  • Directorysrc

    • Directoryapp/ Terraform modules for infrastructure specific to a project/generator

      • …
    • Directorycore/ Generic modules which are reused by modules in app

      • …
  • project.json Project build targets and configuration

Progetto Generato

Questo progetto è generato utilizzando il generatore terraform#project e quindi configura gli stessi target di build.

CDK

• Directorypackages/common/constructs/src

  • Directoryapp

    • Directorydbs

      • <name>.ts Infrastruttura specifica per il tuo database
  • Directorycore

    • Directoryrdb

      • aurora.ts Costrutto generico per database Aurora

Terraform

• Directorypackages/common/terraform/src

  • Directoryapp

    • Directorydbs

      • Directory<name>

        • <name>.tf Modulo specifico per il tuo database
  • Directorycore

    • Directoryrdb

      • Directoryaurora

        • aurora.tf Modulo generico Aurora

Architettura

Il database distribuito ha la seguente architettura. Per impostazione predefinita, un Amazon RDS Proxy si trova davanti al cluster Aurora per raggruppare le connessioni e per abilitare l’autenticazione IAM — vedi Disable RDS Proxy per l’alternativa. L’architettura è la stessa sia che si selezioni il motore PostgreSQL o MySQL; solo il tipo di motore Aurora differisce.

Sviluppo Locale

Modellazione dei Dati

Il progetto generato utilizza SQLModel per definire lo schema del database. Il flusso di lavoro è model-first: aggiungi o aggiorna le classi di tabella SQLModel nella directory <name>/models/ del tuo progetto database, quindi genera una migrazione da tali modifiche del modello.

Esempio di modello:

packages/my_db/my_db/models/example.py

from sqlalchemy import Column, String
from sqlmodel import Field, SQLModel


class ExampleModel(SQLModel, table=True):
    id: int | None = Field(default=None, primary_key=True)
    name: str = Field(sa_column=Column(String(255), nullable=False))
    description: str | None = Field(default=None, sa_column=Column(String(255), nullable=True))

Importa i tuoi modelli in <name>/models/__init__.py in modo che Alembic possa scoprirli durante l’autogenerazione.

Creazione di Migrazioni

Dopo aver aggiunto o aggiornato i modelli, utilizza Alembic per generare e applicare gli script di migrazione. Il target alembic generato avvia automaticamente un container database locale prima dell’esecuzione:

pnpm

pnpm nx run <project>:alembic revision --autogenerate -m "describe your change"

yarn

yarn nx run <project>:alembic revision --autogenerate -m "describe your change"

npm

npx nx run <project>:alembic revision --autogenerate -m "describe your change"

bun

bunx nx run <project>:alembic revision --autogenerate -m "describe your change"

Questo genera un nuovo script di migrazione in migrations/versions/. Rivedi lo script generato prima di applicarlo.

Applica la migrazione al tuo database locale:

pnpm

pnpm nx run <project>:migrate

yarn

yarn nx run <project>:migrate

npm

npx nx run <project>:migrate

bun

bunx nx run <project>:migrate

Quando distribuisci lo stack AWS, l’infrastruttura generata applica automaticamente le migrazioni generate al database distribuito.

Applicazione di Migrazioni Esistenti

Quando scarichi file di migrazione creati da altri sviluppatori, applicali al tuo database locale:

pnpm

pnpm nx run <project>:migrate

yarn

yarn nx run <project>:migrate

npm

npx nx run <project>:migrate

bun

bunx nx run <project>:migrate

Esecuzione di Comandi Alembic

Il target alembic generato espone la CLI di Alembic, quindi puoi eseguire qualsiasi comando Alembic sul database locale. Consulta il riferimento dei comandi Alembic per i comandi disponibili.

pnpm

pnpm nx run <project>:alembic <alembic-command>

yarn

yarn nx run <project>:alembic <alembic-command>

npm

npx nx run <project>:alembic <alembic-command>

bun

bunx nx run <project>:alembic <alembic-command>

Arresto del Database Locale

L’arresto di dev (ad esempio con Ctrl+C) rimuove automaticamente il container del database locale, ma conserva il volume nominato in modo che i tuoi dati persistano tra i riavvii.

Windows

A causa di limitazioni nella gestione dei segnali su Windows, il container non viene rimosso automaticamente quando dev viene arrestato. Dovrai rimuoverlo manualmente:

<engine> rm -f <scope>-<db-name>

Sostituisci <engine> con il tuo motore di container (docker o finch), <scope> con lo scope del tuo workspace Nx (ad esempio proj) e <db-name> con il nome del tuo progetto database (ad esempio my-db).

Connessione al Database

Importa session_context dal tuo package database e usalo come gestore di contesto asincrono per ottenere un AsyncSession:

from sqlmodel import select

from my_scope.my_db import session_context
from my_scope.my_db.models.example import ExampleModel

async def example():
    async with session_context() as session:
        results = (await session.execute(select(ExampleModel))).all()

Il client database automaticamente:

• Recupera la configurazione del database da AWS AppConfig a runtime
• Genera token di autenticazione temporanei tramite boto3 RDS Signer per l’autenticazione IAM
• Stabilisce connessioni TLS utilizzando ssl.create_default_context()

Configurazione runtime

Questo si basa sulla variabile d’ambiente RUNTIME_CONFIG_APP_ID per recuperare la configurazione da AWS AppConfig durante l’esecuzione. I progetti costruiti con questo plugin (API, Agents, server MCP) hanno già questa variabile configurata automaticamente. Per altri progetti, assicurati che RUNTIME_CONFIG_APP_ID sia impostata nell’ambiente di esecuzione con l’ID dell’applicazione AppConfig fornito dalla tua infrastruttura. Per maggiori informazioni, consulta la guida alla Configurazione Runtime.

Distribuzione del Database

Il generatore di database relazionali crea un’infrastruttura CDK o Terraform in base al tuo iac selezionato.

CDK

Il costrutto CDK viene creato in common/constructs. Esempio di utilizzo:

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

export class ApplicationStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    ...
    const db = new MyDatabase(this, 'Db', {
      vpc,
      vpcSubnets: {
        subnetType: SubnetType.PRIVATE_ISOLATED,
      }
    });
  }
}

Questo esegue il provisioning di un cluster Aurora con RDS Proxy, credenziali amministratore, utente del database dell’applicazione, registrazione della configurazione di runtime e gestore delle migrazioni.

L’infrastruttura generata crea due utenti del database:

• Utente amministratore - Creato durante il provisioning del cluster con credenziali memorizzate in AWS Secrets Manager
• Utente applicazione - Creato tramite una risorsa personalizzata Lambda con autenticazione IAM abilitata e privilegi DML (SELECT, INSERT, UPDATE, DELETE) sul database dell’applicazione

Terraform

Il modulo Terraform viene creato in common/terraform. Esempio di utilizzo:

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"

  # Database subnets have no internet route; Lambda subnets need NAT egress.
  vpc_id              = aws_vpc.main.id
  database_subnet_ids = aws_subnet.database[*].id
  lambda_subnet_ids   = aws_subnet.private[*].id

  tags = local.common_tags
}

Questo esegue il provisioning di un cluster Aurora con RDS Proxy, credenziali amministratore, Lambda create-db-user, registrazione della configurazione di runtime, Lambda di migrazione e risorse del registro dei container.

Il modulo del database registra i suoi dettagli di connessione nello spazio dei nomi della configurazione di runtime database. Includi questo spazio dei nomi quando istanzi l’applicazione AppConfig della configurazione di runtime condivisa:

packages/infra/src/main.tf

module "runtime_config_appconfig" {
  source = "../../common/terraform/src/core/runtime-config/appconfig"

  application_name = "my-app-runtime-config"
  namespaces       = ["connection", "agentcore", "database"]
}

L’infrastruttura generata crea due utenti del database:

• Utente amministratore - Creato durante il provisioning del cluster con credenziali memorizzate in AWS Secrets Manager
• Utente applicazione - Creato tramite una funzione Lambda con autenticazione IAM abilitata e privilegi DML (SELECT, INSERT, UPDATE, DELETE) sul database dell’applicazione

L’utente applicazione viene creato automaticamente con un nome casuale e autenticazione IAM. Il client del database generato è già configurato per autenticarsi come questo utente utilizzando token RDS di breve durata, quindi il codice dell’applicazione non gestisce mai le password del database.

Il tuo VPC dovrebbe includere subnet pubbliche, subnet private con egress e subnet private isolate. Il database può essere eseguito in subnet private isolate, mentre le funzioni Lambda dell’applicazione dovrebbero essere eseguite in subnet private con egress in modo che possano raggiungere i servizi AWS come AppConfig.

Clicca qui per una configurazione VPC di esempio.

Utilizza il generatore connection per connettere un progetto a questo database — consulta la guida alla connessione per il tipo di compute pertinente (ad es. FastAPI, server MCP, agent) per il cablaggio dell’infrastruttura necessario per raggiungerlo.

Scansione delle Immagini

L’immagine Docker costruita per questo progetto può essere scansionata per vulnerabilità utilizzando Trivy, eseguito dall’immagine Trivy ospitata su ECR.

Un target trivy viene aggiunto al tuo progetto che scansiona l’immagine costruita ed esce con codice diverso da zero se viene trovata qualsiasi vulnerabilità di gravità HIGH o CRITICAL. Il Dockerfile generato utilizza un’immagine base senza vulnerabilità risolvibili note di queste gravità al momento della generazione, e aggiorna gli strumenti inclusi (come npm) per mantenerla tale.

La scansione utilizza lo stesso motore container della tua build dell’immagine (docker o finch), quindi non sono richiesti strumenti aggiuntivi. Poiché la scansione viene rieseguita solo quando l’immagine cambia, un’immagine non modificata non viene scansionata nuovamente. Lo script root trivy fornito scansiona ogni immagine nel workspace:

pnpm

pnpm trivy

yarn

yarn trivy

npm

npm run trivy

bun

bun trivy

Esegui Trivy in CI

La scansione non è intenzionalmente collegata a build poiché questo può introdurre attriti non necessari durante l’iterazione in fase di sviluppo, dato che il database delle vulnerabilità di Trivy viene continuamente aggiornato con nuovi CVE.

Invece raccomandiamo di eseguire il comando sopra come passaggio dedicato nella tua pipeline CI prima del deployment agli stage di produzione.

Le vulnerabilità non risolvibili vengono ignorate

La scansione viene eseguita con --ignore-unfixed, quindi le vulnerabilità senza una correzione disponibile non fanno fallire la build, poiché non possono essere risolte aggiornando gli strumenti nel tuo Dockerfile — non vengono riportate nell’output della scansione della build. Man mano che vengono divulgate nuove vulnerabilità, il risultato delle scansioni può cambiare nel tempo, quindi rivedi periodicamente l’immagine eseguendo trivy image <your-image> senza il flag, e ricostruisci contro un’immagine base più recente (o aggiungi passaggi container per applicare le patch disponibili) una volta che viene pubblicata una correzione.

Soppressione dei Risultati di Trivy

Potrebbero esserci casi in cui desideri sopprimere una vulnerabilità specifica, ad esempio quando non è ancora disponibile una correzione e hai valutato il rischio come accettabile.

Aggiungi l’ID della vulnerabilità (uno per riga) al file .trivyignore nella root del tuo progetto (cioè accanto al tuo project.json):

.trivyignore

# node-tar arbitrary file write - not exploitable in our usage
CVE-2024-XXXXX

Per maggiori dettagli sul filtraggio dei risultati, consulta la documentazione sul filtraggio di Trivy.

Configurazione RDS Proxy

L’infrastruttura generata include un RDS Proxy per impostazione predefinita, che si posiziona tra la tua applicazione e il cluster Aurora. RDS Proxy offre diversi vantaggi:

• Connection pooling - Mantiene un pool di connessioni al database che possono essere condivise tra le istanze dell’applicazione, riducendo l’overhead di stabilire nuove connessioni
• Resilienza delle connessioni - Gestisce automaticamente i failover e le riconnessioni durante le sostituzioni delle istanze Aurora o la manutenzione
• Autenticazione IAM - Supporta l’autenticazione al database basata su IAM, eliminando la necessità di gestire le credenziali del database nel codice dell’applicazione
• Sicurezza migliorata - Impone la crittografia TLS per tutte le connessioni

Costo Aggiuntivo

RDS Proxy è abilitato per impostazione predefinita ma comporta costi aggiuntivi oltre al costo del cluster Aurora. Consulta i prezzi di AWS RDS Proxy per i dettagli. Se preferisci disabilitare il proxy, consulta la sezione seguente.

Disabilitare RDS Proxy

Puoi disabilitare il proxy RDS come segue:

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  enableRdsProxy: false,
});

Quando RDS Proxy è disabilitato, la tua applicazione si connette direttamente all’endpoint del cluster Aurora.

Terraform

Per impostazione predefinita, RDS Proxy è abilitato. Puoi disabilitarlo se necessario:

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  enable_rds_proxy = false
}

Quando RDS Proxy è disabilitato, la tua applicazione si connette direttamente all’endpoint del cluster Aurora.

Requisiti SSL per la Connessione Senza RDS Proxy

Il bundle CA di Amazon RDS deve essere nel trust store di sistema del runtime.

Runtime Container

Amazon Linux

ADD https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem /etc/pki/ca-trust/source/anchors/global-bundle.pem
RUN update-ca-trust

Debian

ADD https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem /usr/local/share/ca-certificates/rds-global-bundle.crt
RUN update-ca-certificates

Funzioni Lambda Zip

Per le funzioni Lambda distribuite come zip (come una py#api FastAPI), il trust store CA integrato dell’ambiente di esecuzione Lambda Amazon Linux 2023 include le CA Root di Amazon utilizzate da RDS.

Quando si utilizza RDS Proxy, non è necessario configurare il bundle CA di RDS nel runtime che si connette al database.

Istanze del Cluster

Configura le istanze writer e reader per il tuo cluster Aurora.

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  writer: ClusterInstance.serverlessV2('writer'),
  readers: [ClusterInstance.serverlessV2('reader')],
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  instance_count = 2  # 1 writer + 1 reader
}

Capacità Serverless

Controlla i limiti di scalabilità di Aurora Serverless v2 per adattarli al tuo carico di lavoro.

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  serverlessV2MinCapacity: 0.5,
  serverlessV2MaxCapacity: 8,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  serverless_min_capacity = 0.5
  serverless_max_capacity = 8
}

Versione del Motore

Fissa una versione specifica del motore Aurora.

Per impostazione predefinita, l’immagine del container del database locale generata corrisponde alla versione predefinita del motore Aurora. Se modifichi la versione del motore Aurora, si consiglia di utilizzare anche una versione dell’immagine del container locale corrispondente per la massima compatibilità. Consulta le note di rilascio AWS per le versioni di Aurora PostgreSQL e le versioni di Aurora MySQL per identificare la versione del database della community corrispondente.

L’immagine del database locale è configurata nel campo localDev.image del file config.json generato nella radice del progetto del database. Aggiorna quel valore quando modifichi le versioni del motore.

engine = postgres

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  engineVersion: AuroraPostgresEngineVersion.VER_17_7,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  engine_version = "17.7"
}

engine = mysql

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  engineVersion: AuroraMysqlEngineVersion.VER_3_12_0,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  engine_version = "8.0.mysql_aurora.3.12.0"
}

Protezione dalla Cancellazione

La protezione dalla cancellazione è abilitata per impostazione predefinita (deletionProtection: true in CDK, deletion_protection = true in Terraform) per proteggere il cluster Aurora dalla cancellazione accidentale.

Disabilitare la Protezione dalla Cancellazione

È possibile disabilitare la protezione dalla cancellazione per ambienti in cui la cancellazione del database è prevista, come stack di sviluppo o di anteprima di breve durata.

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  deletionProtection: false,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  deletion_protection = false
}

Politica di Rimozione

Il costrutto CDK mantiene il cluster Aurora per impostazione predefinita (removalPolicy: RemovalPolicy.RETAIN). Modifica questo comportamento quando desideri che l’eliminazione dello stack CDK crei uno snapshot o distrugga il cluster.

Quando si utilizza RemovalPolicy.DESTROY, la protezione dall’eliminazione deve essere disabilitata prima che il cluster possa essere eliminato.

CDK

packages/infra/src/stacks/application-stack.ts

import { RemovalPolicy } from 'aws-cdk-lib';
import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  removalPolicy: RemovalPolicy.SNAPSHOT,
});

Per un ambiente effimero in cui il database dovrebbe essere eliminato con lo stack:

packages/infra/src/stacks/application-stack.ts

import { RemovalPolicy } from 'aws-cdk-lib';
import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  deletionProtection: false,
  removalPolicy: RemovalPolicy.DESTROY,
});

Perdita di Dati

RemovalPolicy.DESTROY cancellerà permanentemente tutti i dati quando lo stack viene eliminato. Utilizzare solo in ambienti effimeri (come test automatizzati). Utilizzare RETAIN o SNAPSHOT per tutti gli stack persistenti e di produzione per prevenire la perdita di dati.

Terraform

Terraform non utilizza le politiche di rimozione CDK. Per impostazione predefinita, il modulo crea uno snapshot finale all’eliminazione (skip_final_snapshot = false). Per saltare lo snapshot finale in un ambiente effimero:

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  deletion_protection = false
  skip_final_snapshot = true
}

Perdita di Dati

skip_final_snapshot = true cancellerà permanentemente tutti i dati quando il cluster viene eliminato. Utilizzare solo in ambienti effimeri (come test automatizzati). Mantenere skip_final_snapshot = false per tutti gli stack persistenti e di produzione per prevenire la perdita di dati.

Logging e Monitoraggio

engine = postgres

Il log postgresql viene esportato per Aurora PostgreSQL, con la registrazione limitata alle sole istruzioni DDL (log_statement=ddl) in modo che i valori dei parametri delle istruzioni non vengano mai registrati — purché ogni istruzione venga inviata singolarmente. log_statement=ddl registra l’intero testo grezzo di un batch multi-istruzione (ad esempio una singola chiamata psql -c "a;b;c") testualmente se qualsiasi istruzione in esso è DDL, inclusi eventuali valori DML nello stesso batch.

engine = mysql

I log audit ed error vengono esportati per Aurora MySQL — general e slowquery sono deliberatamente esclusi poiché registrano il testo completo delle istruzioni, inclusi i valori DML. Advanced Auditing è limitato alle connessioni e al DDL (server_audit_events=CONNECT,QUERY_DDL), quindi i valori dei parametri delle istruzioni non vengono mai registrati.

Performance Insights è abilitato per impostazione predefinita sull’istanza writer di Aurora (crittografato con la chiave KMS del cluster). Anche i log del motore Aurora vengono esportati in CloudWatch Logs per impostazione predefinita, configurati per mostrare l’attività a livello di schema senza esporre i dati delle righe.

Disabilita l’esportazione dei log per database se non necessaria:

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  enableCloudwatchLogs: false,
  enablePerformanceInsights: false,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  enable_cloudwatch_logs      = false # disable if not required
  enable_performance_insights = false # disable if not required
}

Rotazione della Chiave di Crittografia

La chiave KMS utilizzata per crittografare il cluster Aurora e il suo secret delle credenziali ha la rotazione automatica della chiave abilitata per impostazione predefinita. Disabilitala se la tua politica di sicurezza gestisce la rotazione esternamente.

CDK

packages/infra/src/stacks/application-stack.ts

import { MyDatabase } from '@my-scope/common-constructs';

const db = new MyDatabase(this, 'Db', {
  ...
  enableKeyRotation: false,
});

Terraform

packages/infra/src/main.tf

module "my_database" {
  source = "../../common/terraform/src/app/dbs/my-database"
  ...
  enable_key_rotation = false
}

Connessioni

Utilizza il generatore connection per integrare questo progetto con altri nel tuo workspace. Le seguenti connessioni coinvolgono questo progetto:

Python Agent to Relational DatabaseConnect a Python Agent to an Aurora relational database

FastAPI to Relational DatabaseConnect a FastAPI to an Aurora relational database

Python MCP Server to Relational DatabaseConnect a Python MCP Server to an Aurora relational database