Introducción
El equipo de empaquetado necesita pedidos NEW de todos los clientes. La clave primaria de cliente y fecha no puede atender ese patrón de acceso con una Query de la tabla base. Añadirás un índice secundario global, seleccionarás una proyección, consultarás la cola real y observarás cómo un pedido empaquetado se mueve entre particiones del índice después de una escritura en la tabla base.
Completa primero Consulta pedidos con claves de partición y ordenación. Esta VM nueva prepara únicamente la tabla base, los registros sintéticos, la tabla de referencia y la estructura de la aplicación. Crear el índice y configurar su consulta son tu trabajo. Utiliza /home/labex/project, AWS CLI oficial y AWS View.
Relación con las certificaciones
| Certificación | Tarea del examen | Práctica |
|---|---|---|
| Solutions Architect – Associate (SAA-C03) | Tarea 3.3 | Índices secundarios DynamoDB y proyección de atributos. |
| Developer – Associate (DVA-C02) | Tarea 1.3 | Índices secundarios DynamoDB y proyección de atributos. |
| Data Engineer – Associate (DEA-C01) | Tarea 2.4 | Práctica de fundamentos: Índices secundarios DynamoDB y proyección de atributos. |
Vista general del laboratorio

Añade un patrón de acceso alternativo
En este paso, añadirás un índice para una cola de empaquetado que necesita pedidos NEW de todos los clientes. La tabla preparada utiliza customer_id y order_key; una Query de tabla base no puede seleccionar todos los clientes por estado porque status no es su clave de partición. Un índice secundario global (GSI) proporciona otra vista de los mismos elementos con claves de partición y ordenación.
La búsqueda por cliente y la cola de preparación responden preguntas distintas sobre los mismos pedidos. El GSI permite seleccionar directamente una partición de estado entre clientes. Añadir un filtro de estado a la Query por cliente seguiría examinando solo la partición de ese cliente; no crearía la ruta alternativa que necesita la cola.

La tabla de pedidos y tres registros sintéticos están preparados de forma independiente para que puedas centrarte en el nuevo patrón de acceso. Inspecciónalos primero; conserva todos los registros sin cambios salvo la actualización de estado enseñada.
cd /home/labex/project
aws dynamodb describe-table --table-name labex-d03-orders --query 'Table.KeySchema'
aws dynamodb scan --table-name labex-d03-orders --consistent-read
Añade StatusDateIndex con status como clave de partición y order_key como clave de ordenación. Una proyección determina qué atributos almacena el índice. INCLUDE añade amount; las claves de tabla e índice se incluyen automáticamente. El atributo source, que no es de clave, permanecerá únicamente en la tabla base. El almacenamiento y las escrituras de índices tienen un coste en AWS.
aws dynamodb update-table \
--table-name labex-d03-orders \
--attribute-definitions AttributeName=status,AttributeType=S AttributeName=order_key,AttributeType=S \
--global-secondary-index-updates '[{"Create":{"IndexName":"StatusDateIndex","KeySchema":[{"AttributeName":"status","KeyType":"HASH"},{"AttributeName":"order_key","KeyType":"RANGE"}],"Projection":{"ProjectionType":"INCLUDE","NonKeyAttributes":["amount"]}}}]'
aws dynamodb describe-table \
--table-name labex-d03-orders \
--query 'Table.GlobalSecondaryIndexes[].{Name:IndexName,State:IndexStatus,Keys:KeySchema,Projection:Projection}'
Continúa únicamente cuando StatusDateIndex indique ACTIVE. La creación puede llevar tiempo en AWS; repite el comando describe mientras el índice siga creándose. Un waiter table-exists no demuestra que un índice nuevo esté listo. AWS View muestra el índice dentro de la tarjeta de la tabla después de que el servicio informe de él.
Consulta el índice de estados e inspecciona su proyección
En este paso, leerás la cola NEW mediante las claves alternativas. --index-name selecciona el GSI. La condición de clave utiliza igualdad de status; un filtro sobre un scan de la tabla base leería primero elementos ajenos a la selección.
aws dynamodb query \
--table-name labex-d03-orders \
--index-name StatusDateIndex \
--key-condition-expression '#state = :state' \
--expression-attribute-names '{"#state":"status"}' \
--expression-attribute-values '{":state":{"S":"NEW"}}'
El índice devuelve O100 de Ada y O200 de Bob, cada uno con amount. Su atributo source está ausente porque no se proyectó. Recuperar atributos adicionales de la tabla base requeriría una lectura independiente por clave.
Las actualizaciones de GSI son asíncronas en AWS y sus lecturas tienen consistencia eventual. No añadas --consistent-read a una Query de GSI: esa solicitud se rechaza con ValidationException. Espera y repite una lectura si una escritura reciente todavía no ha llegado al índice; no consideres un resultado desactualizado como prueba de que la escritura falló.
La aplicación order-lookup proporcionada del laboratorio anterior lee los ajustes normales de lookup.json. Escribe la solicitud para elegir este índice y la cola NEW. Un heredoc entre comillas escribe JSON literalmente; ConsistentRead: false hace explícita la elección de lectura del índice.
cat > lookup.json <<'JSON'
{
"paginate": true,
"request": {
"TableName": "labex-d03-orders",
"IndexName": "StatusDateIndex",
"KeyConditionExpression": "#state = :state",
"ExpressionAttributeNames": {
"#state": "status"
},
"ExpressionAttributeValues": {
":state": {
"S": "NEW"
}
},
"ConsistentRead": false
}
}
JSON
./order-lookup
La aplicación devuelve los mismos dos pedidos. Despliega StatusDateIndex en AWS View y compara la proyección real con el resultado de consulta. Conservar ambos clientes es correcto para una cola de estados, aunque una vista específica de cliente requeriría otro patrón de claves.
Observa cómo un pedido cambia entre colas de estados
En este paso, empaquetarás O100 y observarás cómo cambia su entrada de índice. Un GSI sigue las escrituras de la tabla base; no escribes directamente en el índice. Actualizar status cambia la partición del índice del elemento mientras su clave primaria base sigue siendo la misma.
aws dynamodb update-item \
--table-name labex-d03-orders \
--key '{"customer_id":{"S":"ada"},"order_key":{"S":"2026-10-01#O100"}}' \
--update-expression 'SET #state = :state' \
--expression-attribute-names '{"#state":"status"}' \
--expression-attribute-values '{":state":{"S":"PACKED"}}' \
--return-values ALL_NEW
./order-lookup
La cola NEW ahora contiene únicamente O200 de Bob. Consulta PACKED para confirmar que O100 aparece junto a O101 en lugar de desaparecer del servicio.
aws dynamodb query \
--table-name labex-d03-orders \
--index-name StatusDateIndex \
--key-condition-expression '#state = :state' \
--expression-attribute-names '{"#state":"status"}' \
--expression-attribute-values '{":state":{"S":"PACKED"}}'
Espera O100 y O101 de Ada en PACKED. En AWS, repite estas lecturas hasta que la propagación al índice sea visible. La respuesta de actualización y una lectura consistente de la tabla base son el estado inmediato autorizado del elemento; el GSI es una vista derivada de consistencia eventual. AWS View muestra el nuevo estado de O100 y la consulta NEW que contiene únicamente O200.

Elimina el índice y la tabla propios
En este paso, eliminarás la vista alternativa y después la tabla propia. Eliminar un índice deja intactos los elementos de la tabla base; eliminar una tabla elimina los elementos y sus índices restantes. Indica únicamente los recursos propios.
aws dynamodb update-table \
--table-name labex-d03-orders \
--global-secondary-index-updates '[{"Delete":{"IndexName":"StatusDateIndex"}}]'
aws dynamodb describe-table \
--table-name labex-d03-orders \
--query 'Table.GlobalSecondaryIndexes'
Continúa cuando la lista de índices esté vacía. En AWS, repite DescribeTable mientras la eliminación esté en curso. La tabla todavía contiene tres elementos en este momento.
aws dynamodb scan --table-name labex-d03-orders --consistent-read --select COUNT
aws dynamodb delete-table --table-name labex-d03-orders
aws dynamodb wait table-not-exists --table-name labex-d03-orders
aws dynamodb list-tables
aws dynamodb get-item \
--table-name labex-d03-reference \
--key '{"id":{"S":"platform"}}' \
--consistent-read
La tabla de pedidos y su índice están ausentes; la nota de referencia sigue siendo keep unchanged. Las lecturas correctas de inventario y referencia distinguen la limpieza de un servicio desconectado. AWS View conserva únicamente la referencia ajena a la tarea. La conexión desechable termina con la VM.
Resumen
Añadiste un GSI para una cola de estados de todos los clientes, seleccionaste atributos proyectados y utilizaste las claves del índice en consultas reales. Una actualización de estado en la tabla base movió el pedido entre particiones del índice sin cambiar su clave primaria. Distinguiste el estado inmediato de la tabla base de la propagación eventual al índice y después eliminaste únicamente el índice y la tabla propios.
Para ampliar este tema, consulta la referencia de AWS: Índices secundarios globales, proyecciones y consistencia.



