Base de Datos Relacional Python

Este generador crea un nuevo proyecto de base de datos relacional Python respaldado por Amazon Aurora (PostgreSQL o MySQL), SQLModel para el modelado de datos, y Alembic para las migraciones de esquema. Genera el código de aplicación y la infraestructura necesarios para aprovisionar y administrar una base de datos usando AWS CDK o Terraform, con definición de esquema declarativa, despliegue automático de migraciones y un cliente de base de datos.

Uso

Generar una Base de Datos Relacional

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

También puede realizar una ejecución en seco para ver qué archivos se cambiarían

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. Instale el Nx Console VSCode Plugin si aún no lo ha hecho
2. Abra la consola Nx en VSCode
3. Haga clic en Generate (UI) en la sección "Common Nx Commands"
4. Busque @aws/nx-plugin - py#rdb
5. Complete los parámetros requeridos
6. Haga clic en Generate

Opciones

Parámetro	Tipo	Predeterminado	Descripción
name Requerido	string	-	Nombre del proyecto de base de datos a generar
directory	string	packages	El directorio donde almacenar la aplicación.
subDirectory	string	-	El subdirectorio donde se coloca el proyecto. Por defecto es el nombre del proyecto.
infra	aurora | none	aurora	Servicio de base de datos relacional a aprovisionar.
engine	postgres | mysql	postgres	Motor de base de datos a utilizar con el servicio seleccionado.
databaseUser	string	dbadmin	Nombre de usuario administrador de la base de datos. Por defecto es 'dbadmin'.
databaseName	string	-	Nombre inicial de la base de datos. Por defecto es el nombre del proyecto.
framework	sqlmodel	sqlmodel	Framework ORM a utilizar para el proyecto generado.
iac	inherit | cdk | terraform	inherit	El proveedor IaC preferido. Por defecto se hereda de tu selección inicial.
preferInstallDependencies	boolean	true	Si se prefiere instalar las dependencias después de que se ejecute el generador. Establecer en false para diferir la instalación al agrupar múltiples generadores (la instalación aún se ejecuta si es necesaria para que los generadores subsiguientes puedan calcular el grafo del proyecto); instalar una vez al final.

Salida del Generador

El generador crea la siguiente estructura de proyecto en el directorio <directory>/<name>:

• Directorio<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
  • Directoriomodels

    • example.py Example SQLModel table definition
• Directoriomigrations

  • 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

Los scripts de desarrollo local se comparten entre todos los proyectos de base de datos y se generan en packages/common/scripts/:

• Directoriopackages/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)

Infraestructura

Dado que este generador proporciona infraestructura como código basada en tu iac elegido, creará un proyecto en packages/common que incluye las construcciones CDK o módulos Terraform relevantes.

El proyecto común de infraestructura como código está estructurado de la siguiente manera:

CDK

• Directoriopackages/common/constructs

  • Directoriosrc

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

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

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

Proyecto Generado

Este proyecto se genera utilizando el generador ts#project y por lo tanto configura los mismos objetivos de compilación.

Terraform

• Directoriopackages/common/terraform

  • Directoriosrc

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

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

      • …
  • project.json Project build targets and configuration

Proyecto Generado

Este proyecto se genera utilizando el generador terraform#project y por lo tanto configura los mismos objetivos de compilación.

CDK

• Directoriopackages/common/constructs/src

  • Directorioapp

    • Directoriodbs

      • <name>.ts Infraestructura específica para su base de datos
  • Directoriocore

    • Directoriordb

      • aurora.ts Construcción genérica de base de datos Aurora

Terraform

• Directoriopackages/common/terraform/src

  • Directorioapp

    • Directoriodbs

      • Directorio<name>

        • <name>.tf Módulo específico para su base de datos
  • Directoriocore

    • Directoriordb

      • Directorioaurora

        • aurora.tf Módulo genérico de Aurora

Arquitectura

La base de datos desplegada tiene la siguiente arquitectura. Por defecto, un Amazon RDS Proxy se sitúa frente al clúster Aurora para agrupar conexiones y habilitar la autenticación IAM — consulta Deshabilitar RDS Proxy para la alternativa. La arquitectura es la misma ya sea que selecciones el motor PostgreSQL o MySQL; solo difiere el tipo de motor Aurora.

Desarrollo Local

Modelado de Datos

El proyecto generado usa SQLModel para definir tu esquema de base de datos. El flujo de trabajo es primero el modelo: agrega o actualiza clases de tabla SQLModel en el directorio <name>/models/ de tu proyecto de base de datos, luego genera una migración a partir de esos cambios de modelo.

Ejemplo de modelo:

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 tus modelos en <name>/models/__init__.py para que Alembic pueda descubrirlos durante la autogeneración.

Crear Migraciones

Después de agregar o actualizar modelos, usa Alembic para generar y aplicar scripts de migración. El objetivo alembic generado inicia automáticamente un contenedor de base de datos local antes de ejecutarse:

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"

Esto genera un nuevo script de migración en migrations/versions/. Revisa el script generado antes de aplicarlo.

Aplica la migración a tu base de datos local:

pnpm

pnpm nx run <project>:migrate

yarn

yarn nx run <project>:migrate

npm

npx nx run <project>:migrate

bun

bunx nx run <project>:migrate

Cuando despliegues el stack de AWS, la infraestructura generada aplica automáticamente las migraciones generadas a la base de datos desplegada.

Aplicar Migraciones Existentes

Cuando obtengas archivos de migración creados por otros desarrolladores, aplícalos a tu base de datos local:

pnpm

pnpm nx run <project>:migrate

yarn

yarn nx run <project>:migrate

npm

npx nx run <project>:migrate

bun

bunx nx run <project>:migrate

Ejecutar Comandos de Alembic

El objetivo alembic generado expone la CLI de Alembic, por lo que puedes ejecutar cualquier comando de Alembic contra la base de datos local. Consulta la referencia de comandos de Alembic para los comandos disponibles.

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>

Detener la Base de Datos Local

Detener dev (por ejemplo, con Ctrl+C) elimina automáticamente el contenedor de base de datos local, pero conserva el volumen nombrado para que tus datos persistan entre reinicios.

Windows

Debido a limitaciones con el manejo de señales en Windows, el contenedor no se elimina automáticamente cuando se detiene dev. Necesitarás eliminarlo manualmente:

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

Reemplaza <engine> con tu motor de contenedores (docker o finch), <scope> con el alcance de tu espacio de trabajo Nx (por ejemplo, proj), y <db-name> con el nombre de tu proyecto de base de datos (por ejemplo, my-db).

Conectarse a la Base de Datos

Importa session_context desde tu paquete de base de datos y úsalo como un administrador de contexto asíncrono para obtener una 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()

El cliente de base de datos automáticamente:

• Recupera la configuración de la base de datos desde AWS AppConfig en tiempo de ejecución
• Genera tokens de autenticación temporales a través de boto3 RDS Signer para autenticación IAM
• Establece conexiones TLS usando ssl.create_default_context()

Configuración en tiempo de ejecución

Esto depende de la variable de entorno RUNTIME_CONFIG_APP_ID para obtener la configuración de AWS AppConfig en tiempo de ejecución. Los proyectos construidos con este plugin (APIs, Agents, servidores MCP) ya tienen esta variable configurada automáticamente. Para otros proyectos, asegúrese de que RUNTIME_CONFIG_APP_ID esté establecida en el entorno de ejecución con el ID de aplicación de AppConfig aprovisionado por su infraestructura. Para más información, consulte la guía de Configuración en tiempo de ejecución.

Desplegar tu Base de Datos

El generador de base de datos relacional crea infraestructura CDK o Terraform basada en tu iac seleccionado.

CDK

El constructo CDK se crea en common/constructs. Ejemplo de uso:

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,
      }
    });
  }
}

Esto aprovisiona un clúster Aurora con RDS Proxy, credenciales de administrador, usuario de base de datos de aplicación, registro de configuración en tiempo de ejecución y manejador de migraciones.

La infraestructura generada crea dos usuarios de base de datos:

• Usuario administrador - Creado durante el aprovisionamiento del clúster con credenciales almacenadas en AWS Secrets Manager
• Usuario de aplicación - Creado a través de un recurso personalizado Lambda con autenticación IAM habilitada y privilegios DML (SELECT, INSERT, UPDATE, DELETE) en la base de datos de aplicación

Terraform

El módulo Terraform se crea en common/terraform. Ejemplo de uso:

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
}

Esto aprovisiona un clúster Aurora con RDS Proxy, credenciales de administrador, Lambda create-db-user, registro de configuración en tiempo de ejecución, Lambda de migración y recursos de registro de contenedores.

El módulo de base de datos registra sus detalles de conexión bajo el espacio de nombres de configuración en tiempo de ejecución database. Incluye este espacio de nombres al instanciar la aplicación AppConfig de configuración en tiempo de ejecución compartida:

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"]
}

La infraestructura generada crea dos usuarios de base de datos:

• Usuario administrador - Creado durante el aprovisionamiento del clúster con credenciales almacenadas en AWS Secrets Manager
• Usuario de aplicación - Creado a través de una función Lambda con autenticación IAM habilitada y privilegios DML (SELECT, INSERT, UPDATE, DELETE) en la base de datos de aplicación

El usuario de aplicación se crea automáticamente con un nombre aleatorio y autenticación IAM. El cliente de base de datos generado ya está configurado para autenticarse como este usuario usando tokens RDS de corta duración, por lo que el código de tu aplicación nunca maneja contraseñas de base de datos.

Tu VPC debe incluir subredes públicas, subredes privadas con salida y subredes privadas aisladas. La base de datos puede ejecutarse en subredes privadas aisladas, mientras que las funciones Lambda de aplicación deben ejecutarse en subredes privadas con salida para que puedan alcanzar servicios de AWS como AppConfig.

Haz clic aquí para ver una configuración de VPC de ejemplo.

Usa el generador connection para conectar un proyecto a esta base de datos — consulta la guía de conexión para el tipo de cómputo relevante (por ejemplo, FastAPI, servidor MCP, agente) para el cableado de infraestructura requerido para alcanzarla.

Escaneo de Imágenes

La imagen Docker construida para este proyecto puede ser escaneada en busca de vulnerabilidades usando Trivy, ejecutándose desde la imagen Trivy alojada en ECR.

Se agrega un target trivy a tu proyecto que escanea la imagen construida y termina con código distinto de cero si se encuentra alguna vulnerabilidad de severidad HIGH o CRITICAL. El Dockerfile generado usa una imagen base sin vulnerabilidades corregibles conocidas de estas severidades al momento de la generación, y actualiza las herramientas incluidas (como npm) para mantenerlo así.

El escaneo usa el mismo motor de contenedores que tu construcción de imagen (docker o finch), por lo que no se requieren herramientas adicionales. Dado que el escaneo solo se vuelve a ejecutar cuando la imagen cambia, una imagen sin cambios no se vuelve a escanear. El script raíz trivy proporcionado escanea cada imagen en el workspace:

pnpm

pnpm trivy

yarn

yarn trivy

npm

npm run trivy

bun

bun trivy

Ejecuta Trivy en CI

El escaneo intencionalmente no está conectado a build ya que esto puede introducir fricción innecesaria al iterar durante el desarrollo, ya que la base de datos de vulnerabilidades de Trivy se actualiza continuamente con nuevos CVEs.

En su lugar, recomendamos ejecutar el comando anterior como un paso dedicado en tu pipeline de CI antes del despliegue a entornos de producción.

Las vulnerabilidades no corregibles son ignoradas

El escaneo se ejecuta con --ignore-unfixed, por lo que las vulnerabilidades sin una corrección disponible no fallan la construcción, ya que no pueden ser accionadas actualizando las herramientas en tu Dockerfile — no se reportan en la salida del escaneo de la construcción. A medida que se divulgan nuevas vulnerabilidades, el resultado de los escaneos puede cambiar con el tiempo, así que revisa la imagen periódicamente ejecutando trivy image <your-image> sin la bandera, y reconstruye contra una imagen base más nueva (o agrega pasos de contenedor para aplicar parches disponibles) una vez que se publique una corrección.

Suprimiendo Hallazgos de Trivy

Puede haber instancias en las que desees suprimir una vulnerabilidad específica, por ejemplo cuando aún no hay una corrección disponible y has evaluado el riesgo como aceptable.

Agrega el ID de vulnerabilidad (uno por línea) al archivo .trivyignore en la raíz de tu proyecto (es decir, junto a tu project.json):

.trivyignore

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

Para más detalles sobre el filtrado de hallazgos, consulta la documentación de filtrado de Trivy.

Configuración de RDS Proxy

La infraestructura generada incluye un RDS Proxy de forma predeterminada, que se sitúa entre tu aplicación y el clúster Aurora. RDS Proxy proporciona varios beneficios:

• Agrupación de conexiones - Mantiene un pool de conexiones de base de datos que pueden compartirse entre instancias de aplicación, reduciendo la sobrecarga de establecer nuevas conexiones
• Resiliencia de conexión - Maneja automáticamente las conmutaciones por error y reconexiones durante reemplazos de instancias Aurora o mantenimiento
• Autenticación IAM - Admite autenticación de base de datos basada en IAM, eliminando la necesidad de gestionar credenciales de base de datos en el código de tu aplicación
• Seguridad mejorada - Aplica cifrado TLS para todas las conexiones

Costo Adicional

RDS Proxy está habilitado de forma predeterminada pero incurre en cargos adicionales además del costo del clúster Aurora. Consulta precios de AWS RDS Proxy para más detalles. Si prefieres deshabilitar el proxy, consulta la sección a continuación.

Deshabilitar RDS Proxy

Puedes deshabilitar el proxy RDS de la siguiente manera:

CDK

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

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

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

Cuando RDS Proxy está deshabilitado, tu aplicación se conecta directamente al endpoint del clúster Aurora.

Terraform

De forma predeterminada, RDS Proxy está habilitado. Puedes deshabilitarlo si es necesario:

packages/infra/src/main.tf

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

Cuando RDS Proxy está deshabilitado, tu aplicación se conecta directamente al endpoint del clúster Aurora.

Requisitos SSL al Conectarse sin RDS Proxy

El paquete de CA de Amazon RDS debe estar en el almacén de confianza del sistema del tiempo de ejecución.

Tiempos de Ejecución de Contenedores

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

Funciones Lambda Zip

Para funciones Lambda desplegadas como zip (como una py#api FastAPI), el almacén de confianza de CA integrado del entorno de ejecución Lambda de Amazon Linux 2023 incluye las CA raíz de Amazon utilizadas por RDS.

Cuando uses RDS Proxy, no necesitas configurar el paquete de CA de RDS en el tiempo de ejecución que se conecta a la base de datos.

Instancias de Clúster

Configure las instancias de escritura y lectura para su clúster 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
}

Capacidad Serverless

Controla los límites de escalado de Aurora Serverless v2 para que coincidan con tu carga de trabajo.

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
}

Versión del Motor

Fija una versión específica del motor Aurora.

Por defecto, la imagen del contenedor de la base de datos local generada coincide con la versión predeterminada del motor Aurora. Si cambias la versión del motor Aurora, se recomienda también usar una versión de imagen de contenedor local que coincida para máxima compatibilidad. Consulta las notas de lanzamiento de AWS para versiones de Aurora PostgreSQL y versiones de Aurora MySQL para identificar la versión correspondiente de la base de datos comunitaria.

La imagen de la base de datos local se configura en el campo localDev.image del archivo config.json generado en la raíz de tu proyecto de base de datos. Actualiza ese valor cuando cambies las versiones del motor.

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"
}

Protección contra Eliminación

La protección contra eliminación está habilitada por defecto (deletionProtection: true en CDK, deletion_protection = true en Terraform) para proteger el clúster Aurora de eliminaciones accidentales.

Deshabilitar la Protección contra Eliminación

Puede deshabilitar la protección contra eliminación para entornos donde se espera la eliminación de la base de datos, como stacks de desarrollo o vista previa de corta duración.

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
}

Política de Eliminación

El constructo CDK retiene el clúster Aurora por defecto (removalPolicy: RemovalPolicy.RETAIN). Cambia esto cuando quieras que la eliminación del stack CDK haga una instantánea o destruya el clúster en su lugar.

Cuando uses RemovalPolicy.DESTROY, la protección contra eliminación también debe estar deshabilitada antes de que el clúster pueda ser eliminado.

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,
});

Para un entorno efímero donde la base de datos debe ser eliminada con el 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,
});

Pérdida de Datos

RemovalPolicy.DESTROY borrará permanentemente todos los datos cuando el stack sea eliminado. Úsalo solo en entornos efímeros (como pruebas automatizadas). Usa RETAIN o SNAPSHOT para todos los stacks persistentes y de producción para prevenir la pérdida de datos.

Terraform

Terraform no usa políticas de eliminación de CDK. Por defecto, el módulo crea una instantánea final al eliminar (skip_final_snapshot = false). Para omitir la instantánea final en un entorno efímero:

packages/infra/src/main.tf

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

Pérdida de Datos

skip_final_snapshot = true borrará permanentemente todos los datos cuando el clúster sea eliminado. Úsalo solo en entornos efímeros (como pruebas automatizadas). Mantén skip_final_snapshot = false para todos los stacks persistentes y de producción para prevenir la pérdida de datos.

Registro y Monitoreo

engine = postgres

El registro postgresql se exporta para Aurora PostgreSQL, con el registro limitado solo a declaraciones DDL (log_statement=ddl) para que los valores de los parámetros de las declaraciones nunca se registren, siempre y cuando cada declaración se envíe por separado. log_statement=ddl registra todo el texto sin procesar de un lote de múltiples declaraciones (por ejemplo, una sola llamada psql -c "a;b;c") de forma literal si alguna declaración en él es DDL, incluyendo cualquier valor DML en ese mismo lote.

engine = mysql

Los registros audit y error se exportan para Aurora MySQL — general y slowquery se excluyen deliberadamente ya que registran el texto completo de las sentencias, incluidos los valores DML. Advanced Auditing está limitado a conexiones y DDL (server_audit_events=CONNECT,QUERY_DDL), por lo que los valores de los parámetros de las sentencias nunca se registran.

Performance Insights está habilitado en la instancia de escritura de Aurora de forma predeterminada (cifrado con la clave KMS del clúster). Los registros del motor de Aurora también se exportan a CloudWatch Logs de forma predeterminada, configurados para mostrar actividad a nivel de esquema sin filtrar datos de filas.

Deshabilite la exportación de registros por base de datos si no es necesario:

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
}

Rotación de Clave de Cifrado

La clave KMS utilizada para cifrar el clúster Aurora y su secreto de credenciales tiene la rotación automática de claves habilitada por defecto. Deshabilítela si su política de seguridad gestiona la rotación externamente.

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
}

Conexiones

Usa el generador connection para integrar este proyecto con otros en tu espacio de trabajo. Las siguientes conexiones involucran este proyecto:

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