Forem: Miguel Angel Muñoz Sanchez

Aurora DSQL: How to Control Time

Miguel Angel Muñoz Sanchez — Thu, 07 Aug 2025 06:00:00 +0000

In the previous article, we explored how we arrived at Amazon Aurora DSQL and why we need a database that allows consistent writes across multiple regions. At the end of that article, we posed the key question: How did AWS achieve a database with multi-regional writes without breaking ACID?

The answer lies in something that seems impossible: controlling time.

In this article, we will explore how AWS has enabled Aurora DSQL to achieve something that seemed impossible or at least very complex: allowing a Postgres database to support writes across multiple regions with consistency.

In this article, we will cover:

The fundamental problem of time in distributed databases
AWS's solution: Global-scale time synchronization
Aurora DSQL: Real distributed synchronization architecture
Comparison with Aurora PostgreSQL
Limitations and considerations

The Fundamental Problem: Time in Distributed Databases

Before understanding how Aurora DSQL solves the problem, we need to comprehend why time presents such complexity in distributed systems.

The CAP Theorem or Brewer's Theorem

In 2000, Eric Brewer formulated the CAP Theorem, which establishes that in a distributed system, you can only guarantee two of these three properties:

Consistency: All nodes see the same data at the same time
Availability: The system continues functioning even when some nodes fail
Partition tolerance: The system continues operating even when communication between nodes breaks

Any database, such as Aurora PostgreSQL or Aurora MySQL, prioritizes Consistency and Availability over partition tolerance. That's why for writes in Aurora PostgreSQL, we have a primary node and the rest serve as secondary replicas, both within the same region and across multiple regions.
But Aurora DSQL requires all three properties to work together, which demands an entirely different approach.

The Temporal Ordering Problem

Imagine this sequence of events:

Region us-east-1  (10:00:00.020123): UPDATE users SET balance = 900 WHERE id = 123
Region us-west-2  (10:00:00.019548): UPDATE users SET balance = 200 WHERE id = 123
Region eu-west-1  (10:00:00.022020): UPDATE users SET balance = 500 WHERE id = 123
Region eu-south-2 (10:00:00.019386): UPDATE users SET balance = 300 WHERE id = 123

Which of these transactions should execute first?

These executions occur in 4 different regions within the exact second, using the same data, but with different values.

If we use a system like Aurora PostgreSQL with a primary node in the us-east-1 region, the correct data would come from this region, since we would need to add latency to the other executions, which would produce inconsistencies.

Beyond this problem, we assume that systems synchronize completely to the millisecond, but this doesn't always happen. Time synchronization presents significant challenges.

Finally, we see an example of a single action, while a transaction involves several nested actions, which can create even bigger problems.

This represents the problem Aurora DSQL must solve: Create a global and consistent temporal order for all transactions, regardless of where they originate, and maintain real, synchronized time across regions.

AWS's Solution: Global-Scale Time Synchronization

Traditionally, any data center has used NTP (Network Time Protocol) to synchronize with atomic clocks that achieve nanosecond-level precision. However, NTP presents critical limitations for systems requiring extreme precision, as it depends on connected networks and therefore suffers from network latency, potentially achieving only millisecond precision.

AWS needed much greater synchronization between regions if it wanted to build a system like Aurora DSQL.

Amazon Time Sync Service

AWS has invested heavily in synchronizing its infrastructures, creating the Amazon Time Sync Service for this purpose.

Amazon Time Sync Service uses a fleet of satellites with atomic clocks that connect with all AWS regions, providing the same time to all of them.
Atomic clocks are expensive, but satellite positioning systems like GPS require them.
They offer an additional advantage: when they send time data, we know precisely how far away the satellite is and therefore the signal latency with very high precision.
Unlike NTP services against ground-based atomic clocks, satellite-based latency remains stable and therefore provides much greater precision.

The precision achieved reaches nanosecond levels between regions, something unthinkable just a few years ago.

ClockBound: Measuring Time Precision

Complementing Time Sync Service, AWS has developed ClockBound, an open-source daemon and library that measures EC2 instance clock precision and enables determination of the real temporal order of events.

Although Amazon Time Sync Service provides exact time, minor synchronization deviations always exist. ClockBound quantifies these synchronization deviations and adds fundamental functionalities for Amazon DSQL:

Main functionalities:

Time intervals with uncertainty: Instead of an exact timestamp like 10:00:00.123456789, ClockBound provides a range [10:00:00.123456785, 10:00:00.123456793] that guarantees the real time falls within that interval.
Definitive temporal comparison: It can determine if event A definitely occurs before event B, or if they potentially happen concurrently.
Concurrency detection: It identifies when two events may have co-occurred, which proves crucial for resolving transaction conflicts in DSQL.
Wait optimization: It calculates the minimum time an application must wait to guarantee a globally unique timestamp.

With ClockBound, we can compare our time sequence more precisely:

Event us-east-1: [10:00:00.020120, 10:00:00.020126] 
Event us-west-2: [10:00:00.019545, 10:00:00.019551]
Result: us-west-2 definitely occurred before us-east-1

Event eu-west-1: [10:00:00.022018, 10:00:00.022022]
Event eu-south-2: [10:00:00.019384, 10:00:00.019388] 
Result: eu-south-2 definitely occurred before eu-west-1

Event us-east-1: [10:00:00.020120, 10:00:00.020126]
Event us-west-2: [10:00:00.019545, 10:00:00.019551]
Conflicting event: [10:00:00.019550, 10:00:00.020125]
Result: The conflicting event overlaps with both

As you can imagine, without ClockBound, Aurora DSQL probably wouldn't exist.

By the way, although AWS developed ClockBound, it's an open-source project that anyone can use.

Aurora DSQL: Real Distributed Synchronization Architecture

Now it's time to start discussing how Aurora DSQL works and what components make it up.

Now that we understand how AWS has solved the time problem, we can explore how Aurora DSQL uses this technology to create a truly distributed database that maintains ACID properties at a global scale.

How Does DSQL Work?

Aurora DSQL isn't simply an improved Aurora PostgreSQL. It represents an entirely new architecture that reimagines how a database should function to enable multi-region consistency.

Main components:

It's important to understand that each layer scales horizontally, independently of other layers, and dynamically, all depending on the load we demand from our Aurora DSQL.

The horizontal scaling capability makes Aurora DSQL a completely serverless service.

Adjudicators:

Although Query Processor represents the first layer, let's discuss the Adjudicator layer first.

The Adjudicator layer probably represents Aurora DSQL's most innovative component.
These distributed processes implement consensus algorithms to ensure all regions agree on transaction order.

When a transaction needs to execute, the adjudicator layer checks if conflicts exist with any other recent transactions. For conflict detection, adjudicators use an optimized and distributed consensus algorithm that enables conflict detection.

Additionally, this layer scales horizontally, allowing multiple adjudicators for different database partitions, with each adjudicator handling a distinct space within our database.

In Aurora DSQL, all layers operate independently, allowing us to define different partition systems for each layer. Independent layer operation means adjudicators partition based on how we analyze conflicts between transactions, rather than how we store our data, which improves the task's performance.

Aurora DSQL does not replicate adjudicators in each region; instead, the system distributes them across database spaces, allowing any adjudicator to change regions at any time.

Journal Layer:

The Journal records all transactions that Adjudicators approve.
The Journal resembles Aurora PostgreSQL's WAL (Write-Ahead Log), but Aurora DSQL distributes it across multiple regions.

The Journal Layer allows each transaction approved by an adjudicator to write directly to the Journal.
The Journal Layer handles data durability, as Journal records remain immutable, distributed, and replicated in the regions we choose so that we can maintain reliable traceability of all transactions in the log with backup.

Storage:

Aurora DSQL's storage layer extends the Aurora Storage concept but adds global distribution capabilities and temporal consistency.

One of Aurora DSQL Storage's main advantages is that it doesn't need to handle conflicts (adjudicator) or durability (journal), giving this layer more flexibility and enabling greater optimization.

Instead of basing the storage layer on synchronous data replication, Aurora DSQL bases storage distribution on data partitions, but adds sharding capabilities based not only on key partitions, but also on access time and regions, so the system distributes data more optimally while also replicating across different regions.

Traditional databases cannot achieve this.

Query Processor:

Now that we understand how the other layers work, we can discuss Query Processor.

Query Processor represents the layer that receives any Query and where Aurora DSQL receives SQL requests and converts them into distributed operations. Unlike Aurora PostgreSQL, no single "primary" node exists here.

As we saw before, our storage doesn't partition in a standard way; data doesn't replicate in the same storage, but is distributed across different storage partitions to improve performance.

The distributed storage approach makes read operations less efficient because we must determine the data's location. The same happens with write operations since the adjudicator layer analyzes write operations before writing to the Journal and subsequently to the Storage layer.

Additionally, we've seen that all these layers distribute across different partitions that don't need to match, meaning the adjudicator layer doesn't partition the same way as the storage layer.

For this reason, Query Processor represents a fundamental layer, as it orchestrates all our queries, enabling it to know which partition contains data in storage for consultation or which adjudicator should handle any data write task.

Through query orchestration, the Query Processor layer minimizes latency by reducing tasks and loops that any transaction can generate.

Another advantage for maintaining consistency is that the Query Processor performs temporal ordering of reads and chooses the most optimal versioned data, so if we perform a read query on data that someone has modified after our read, but due to latency our write was faster, instead of returning the modified data, the system will give us the data version at the time of query execution.

Complete Diagram Example:

But how does this architecture improve on traditional architecture?

The architecture looks good, but does it work?

Strong Snapshot Isolation

Aurora DSQL uses a variation of the Optimistic Concurrency Control protocol instead of a traditional model. Optimistic Concurrency Control proves crucial for performance in a distributed environment.

The Optimistic Concurrency Control protocol essentially states that when executing a transaction that can compete with another, its commit can only proceed if it adheres to the defined isolation rules.

That's why DSQL uses Strong Snapshot Isolation; this working mode allows multiple transactions to execute in parallel, following a series of rules:

All transaction reads use the transaction start timestamp (Tstart).
When committing data, the commit timestamp gets established (Tcommit).
The transaction can execute the commit only if no other transaction has committed to the same key during the transaction start time (Tstart) and commit time (Tcommit).
Writes execute using the Commit timestamp (Tcommit).

Strong Snapshot Isolation offers several advantages:

We will never see data that doesn't come after a commit.
Reads remain repeatable and therefore cacheable.
Reads come from a single point in time (logical).
Conflicting writes get rejected; no writes get lost.

For this reason, the Query Processor and Adjudicator layers prove so important, as they handle the magic that makes this work.

Multi-Region Optimization

So far, what we've seen doesn't seem very multi-regional, and we would still have latency problems. Still, we've seen a vital point: DSQL separates reads from writes and also has a fundamental component like Query Processor where writes queue before Commit execution.

Through write queuing, the entire transaction can execute locally, even with distributed data, since we only need the Adjudicator layer for the Commit execution, which we can perform even if the adjudicator operates in another region.

Local transaction execution significantly improves performance by avoiding unnecessary jumps between regions, resulting in a much lower absolute latency than expected.

FailOver Optimization

Another advantage is that the Adjudicator layer only stores recent transactions, making it easy to replicate in case of regional failure.

On the other hand, the Journal layer distributes and replicates data, ensuring that in case of failure, it replicates across multiple regions.

Finally, the storage layer, which always takes longer to replicate, has the capacity to redo all pending writes using the Journal layer.

Comparison with Aurora PostgreSQL or Traditional Databases

Elimination of the "Primary" Concept

In Aurora PostgreSQL, a primary node handles all writes.

In Aurora DSQL, we can initiate writes from any region, minimizing multi-region latencies.

Real Horizontal Scalability

Aurora DSQL can scale by adding more regions without performance degradation.

Faster FailOver

In Aurora PostgreSQL, if the primary region fails, one of the replicas in another region must become primary (1-2 minute process).

In Aurora DSQL, the failover process happens much faster because no primary exists, and the system distributes the load.

Horizontal Scaling

Aurora DSQL represents a database with completely decoupled layers, making horizontal scaling and descaling possible, which isn't possible in Aurora PostgreSQL or traditional databases.

Additionally, it's an entirely serverless database.

Limitations and Considerations

Aurora DSQL is a marvel, but it's not suitable for everyone, so I don't recommend it for everyone.

It's an incredible database if your use case fits, but if you have a traditional use case, it's probably not your database; it might even perform much worse than Aurora PostgreSQL.

It's important to note that Aurora DSQL prioritizes consistency over extreme latency:

Simple transactions: 10-50ms additional vs Aurora PostgreSQL.
Complex transactions: Can be 2-5x slower than Aurora PostgreSQL.
Reads: Not much variation since it uses local replicas.

Same-region Latency Comparison

If our workloads exist in a single region, Aurora DSQL will have much higher latency.

Aurora DSQL Pricing Model

Aurora DSQL uses a serverless pricing model that charges for:

Compute (Processing):

Billing by Aurora Compute Units (ACUs) consumed.
Automatic scaling based on workload.
No provisioning required.

Storage:

Charge per GB stored per month
Automatic replication included in price
Automatic backup included

I/O (Input/Output):

Charge per million I/O requests
Includes both reads and writes

Cost Comparison: Aurora DSQL vs Aurora PostgreSQL

Example scenario - Medium application:

Aurora PostgreSQL (Provisioned):

- Instance db.r6g.large: ~$200/month
- Storage (100GB): ~$10/month
- I/O (10M requests): ~$2/month
- Approximate total: ~$212/month (single region)

Aurora DSQL (Serverless):

- Compute (equivalent): ~$300-400/month
- Storage (100GB): ~$15-20/month
- I/O (10M requests): ~$3-5/month
- Multi-region included: No additional cost
- Approximate total: ~$320-425/month (multi-region)

Factors affecting cost:

Traffic pattern: Aurora DSQL proves more efficient for variable loads
Multi-region requirements: Aurora DSQL includes replication across multiple regions at no additional cost.
Transaction complexity: Complex distributed transactions can increase cost
Automatic scaling: Can be more economical for applications with traffic spikes

When is Aurora DSQL more cost-effective?

Applications with highly variable traffic (serverless adapts automatically) As long as Latency allows
Multi-region necessity.

Non-Recommended Use Cases

Aurora DSQL isn't ideal for:

Applications requiring ultra-low latency (<1ms)
Primarily read workloads
Systems with minimal budgets
Applications that can tolerate eventual consistency

Aurora DSQL represents a new category of database that revolutionizes distributed and multi-region databases.
With this new database, AWS has opened the door to global applications that were previously technically impossible.

Aurora DSQL: Cómo controlar el tiempo

Miguel Angel Muñoz Sanchez — Tue, 05 Aug 2025 06:00:00 +0000

En el artículo anterior vimos cómo hemos llegado hasta Amazon Aurora DSQL y por qué necesitamos una base de datos que permita escrituras consistentes en múltiples regiones. Al final del artículo planteamos la pregunta clave: ¿Cómo ha conseguido AWS una BBDD con escritura multiregional sin romper ACID?

La respuesta está en algo que parece imposible: controlar el tiempo.

En este artículo vamos a explorar cómo AWS ha conseguido que Aurora DSQL consiga algo que parecía imposible o al menos muy complejo y es que una BBDD Postgres admita la escritura en múltiples regiones con consistencia.

En este artículo vamos a ver:

El problema fundamental del tiempo en bases de datos distribuidas
La solución de AWS: Sincronización de tiempo a escala global
Aurora DSQL: Arquitectura real de sincronización distribuida
Comparativa con Aurora PostgreSQL
Limitaciones y consideraciones

El Problema Fundamental: El Tiempo en Bases de Datos Distribuidas

Antes de entender cómo Aurora DSQL resuelve el problema, necesitamos comprender por qué el tiempo es tan complejo en sistemas distribuidos.

El Teorema CAP o Teorema Brewer

En 2000, Eric Brewer formuló el Teorema CAP que establece que en un sistema distribuido solo puedes garantizar dos de estas tres propiedades:

Consistency (Consistencia): Todos los nodos ven los mismos datos al mismo tiempo
Availability (Disponibilidad): El sistema sigue funcionando aunque fallen algunos nodos
Partition tolerance (Tolerancia a particiones): El sistema continúa operando aunque se pierda comunicación entre nodos

Cualquier base de datos como Aurora PostgreSQL o Aurora MySQL elige Consistencia y Disponibilidad, sacrificando la tolerancia a particiones. Por eso para escritura en Aurora PostgreSQL tenemos un nodo primario y el resto de nodos son réplicas secundarias, tanto en la misma región como en múltiples regiones.
Pero Aurora DSQL requiere que las tres propiedades estén garantizadas, lo que requiere un enfoque completamente diferente.

El Problema de la Ordenación Temporal

Imagina esta secuencia de eventos:

Región us-east-1  (10:00:00.020123): UPDATE users SET balance = 900 WHERE id = 123
Región us-west-2  (10:00:00.019548): UPDATE users SET balance = 200 WHERE id = 123
Región eu-west-1  (10:00:00.022020): UPDATE users SET balance = 500 WHERE id = 123
Región eu-south-2 (10:00:00.019386): UPDATE users SET balance = 300 WHERE id = 123

¿Cuál de estas transacciones debería ejecutarse primero?

Son ejecuciones en 4 regiones diferentes en el mismo segundo, sobre el mismo dato y con valores diferentes.

Si utilizamos un sistema como Aurora PostgreSQL con un nodo en la región us-east-1 primario, el dato correcto sería el dato de esta región, ya que el resto de ejecuciones tendríamos que sumar la latencia, lo que produciría inconsistencias.

Además de este problema estamos suponiendo que los sistemas están completamente sincronizados al milisegundo, pero esto no es siempre así. Una sincronización de tiempo no es sencilla.

Por último estamos viendo un ejemplo de una acción, mientras que una transacción conlleva varias acciones anidadas, lo que puede suponer un problema mayor.

Este es el problema que Aurora DSQL debe resolverCrear un orden temporal global y consistente para todas las transacciones, independientemente de dónde se originen y tener un tiempo real y sincronizado entre regiones.

La Solución de AWS: Sincronización de Tiempo a Escala Global

Tradicionalmente, cualquier centro de datos ha utilizado NTP (Network Time Protocol) para sincronizar con relojes atómicos que tienen una precisión a nivel del nanosegundo. Sin embargo, NTP presenta limitaciones críticas para sistemas que requieren precisión extrema, ya que tiene dependencias con una red conectada y por tanto sufre de latencia de red y por tanto puede llegar a una precisión de milisegundos.

AWS necesitaba una sincronización entre regiones mucho mayor, si quería tener un sistema como Aurora DSQL.

Amazon Time Sync Service

AWS ha invertido mucho en que sus infraestructuras estén sincronizadas, para ello creó Amazon Time Sync Service.

Este servicio utiliza una flota de satélites con relojes atómicos que se conectan con todas las regiones de AWS proporcionando el mismo tiempo a todas ellas.
Los relojes atómicos son muy caros, pero son necesarios en cualquier sistema de posicionamiento satélite como GPS.
Además tienen una ventaja adicional, cuando envían los datos de tiempo sabemos con exactitud a qué distancia está el satélite y por tanto la latencia de la señal con un nivel de precisión muy alto.
A diferencia de un servicio tipo de NTP contra relojes atómicos en tierra esta latencia es estable y por tanto nos da una precisión mucho mayor.

La precisión alcanzada es del orden de nanosegundos entre regiones, algo impensable hace pocos años.

ClockBound: Midiendo la Precisión del Tiempo

Complementando Time Sync Service, AWS ha desarrollado ClockBound, un demonio y librería open source que mide la precisión del reloj de las instancias EC2 y permite determinar el orden temporal real de los eventos.

Aunque el Amazon Time Sync Service proporciona tiempo muy preciso, siempre existe una pequeña desviación en la sincronización. ClockBound cuantifica esta desviación, y añade ciertas funcionalidades fundamentales para Amazon DSQL:

Funcionalidades principales:

Intervalos de tiempo con incertidumbre: En lugar de un timestamp exacto como 10:00:00.123456789, ClockBound proporciona un rango [10:00:00.123456785, 10:00:00.123456793] qué garantiza que el tiempo real está dentro de ese intervalo.
Comparación temporal definitiva: Puede determinar si un evento A ocurre definitivamente antes que un evento B, o si son potencialmente concurrentes.
Detección de concurrencia: Identifica cuándo dos eventos pueden haber ocurrido al mismo tiempo, lo que es crucial para resolver conflictos de transacciones en DSQL
Optimización de esperas: Calcula el tiempo mínimo que debe esperar una aplicación para garantizar que un timestamp sea globalmente único.

Con ClockBound podemos comparar nuestra secuencia de tiempos de forma más exacta:

Evento us-east-1: [10:00:00.020120, 10:00:00.020126] 
Evento us-west-2: [10:00:00.019545, 10:00:00.019551]
Resultado: us-west-2 ocurrió definitivamente antes que us-east-1

Evento eu-west-1: [10:00:00.022018, 10:00:00.022022]
Evento eu-south-2: [10:00:00.019384, 10:00:00.019388] 
Resultado: eu-south-2 ocurrió definitivamente antes que eu-west-1

Evento us-east-1: [10:00:00.020120, 10:00:00.020126]
Evento us-west-2: [10:00:00.019545, 10:00:00.019551]
Evento con conflicto: [10:00:00.019550, 10:00:00.020125]
Resultado: El evento conflictivo se solapa con ambos

Como podéis suponer sin ClockBound Aurora DSQL probablemente no existiría.

Por cierto aunque ClockBound ha sido desarrollado por AWS es un proyecto de código abierto que cualquiera puede usar.

Aurora DSQL: Arquitectura Real de Sincronización Distribuida

Bueno ya va siendo hora de empezar a hablar de cómo funciona Aurora DSQL y qué componentes lo conforman.

Ahora que entendemos cómo AWS ha resuelto el problema del tiempo, podemos explorar cómo Aurora DSQL utiliza esta tecnología para crear una base de datos verdaderamente distribuida que mantiene las propiedades ACID a escala global.

¿Cómo Funciona DSQL?

Aurora DSQL no es simplemente un Aurora PostgreSQL mejorado. Es una arquitectura completamente nueva que reimagina cómo debe funcionar una base de datos para permitir la consistencia en multi-región.

Componentes principales:

Es importante entender que cada capa escala de forma horizontal, independientemente del resto de capas y dinámicamente, todo ello dependiendo de la carga que demandemos a nuestro Aurora DSQL.

Esto hace que sea un servicio totalmente serverless.

Adjudicators:

Aunque la primera capa es Query Processor, vamos a hablar primero de la capa de Adjudicator.

La capa de Adjudicator es probablemente el componente más innovador de Aurora DSQL.
Son procesos distribuidos que implementan algoritmos de consenso para garantizar que todas las regiones estén de acuerdo sobre el orden de las transacciones.

Cuando una transacción necesita ejecutarse, la capa de adjudicator revisa si existe conflicto con alguna otra transacción reciente. Para esto utilizan un algoritmo de consenso optimizado y distribuido, que permite detectar posibles conflictos.

Además esta capa escala horizontalmente pudiendo tener múltiples adjudicators para diferentes particiones de nuestra BBDD, cada adjudicator se ocupa de un espacio diferente de nuestra BBDD.

En Aurora DSQL todas las capas están desacopladas, esto implica que podemos definir sistemas de particiones diferentes para cada capa, de forma que los adjudicator no se particionan en función de cómo vamos a almacenar nuestros datos, sino de cómo vamos a analizar los conflictos entre transacciones, mejorando el rendimiento de esta tarea.

Los adjudicators no están replicados en cada región, sino que están distribuidos por espacios de la BBDD, en cualquier momento un adjudicator puede cambiar de región.

Journal Layer:

El Journal es donde se registran todas las transacciones aprobadas por los Adjudicators.
Es similar al WAL (Write-Ahead Log) de Aurora PostgreSQL, pero distribuido en varias regiones.

Esto permite que cada transacción aprobada por un adjudicator se escriba directamente en los Journal.
Esta capa es la responsable de la durabilidad de los datos, ya que los registros del Journal son inmutables, están distribuidos y replicados en las regiones que elijamos, de forma que podemos tener una trazabilidad de todas las transacciones en este log de forma confiable y con respaldo.

Storage:

La capa de almacenamiento de Aurora DSQL extiende el concepto de Aurora Storage pero añadiendo capacidades de distribución global y consistencia temporal.

Una de las ventajas principales del Storage de Aurora DSQL, es que no es necesario que se ocupe de los conflictos (adjudicator) ni de la durabilidad (journal), esto da más flexibilidad a esta capa permitiendo una optimización mayor.

En vez de basar esta capa en una replicación de datos síncrona, lo que hace esta capa es basar la distribución del storage en particiones de datos, pero añadiendo capacidades de sharding no solo basados en particiones por claves, sino también por tiempo de acceso y regiones, de esta forma los datos están distribuidos de una forma más óptima aunque también estén replicados en las diferentes regiones.

Esto no es posible en una base de datos tradicional.

Query Processor:

Ya que hemos entendido cómo funcionan el resto de capas podemos hablar de Query Processor.

Query Processor es la capa donde se recibe cualquier Query y es donde Aurora DSQL recibe las peticiones SQL y las convierte en operaciones distribuidas. A diferencia de Aurora PostgreSQL, aquí no hay un nodo "primario" único.

Como hemos visto antes nuestro storage no está particionado de una forma estándar, los datos no están replicados en el mismo storage, sino que están distribuidos en diferentes particiones de storage para mejorar el rendimiento.

Esto provoca que cualquier operación de lectura sea menos eficiente porque tenemos que saber dónde está el dato. También pasa con las operaciones de escritura ya que estas van a ser analizadas por la capa de adjudicator antes de escribirse en el Journal y posteriormente a la capa de Storage.

Además hemos visto que todas estas capas están distribuidas en diferentes particiones y que no tienen por qué ser iguales, es decir la capa de adjudicator no está particionada igual que la capa de storage.

Por este motivo Query Processor es una capa fundamental, ya que es la capa que orquesta todas nuestras querys, de forma que es capaz de saber en qué partición está un dato en storage para consultarlo o a qué adjudicator tiene que asignar la tarea de escritura de cualquier dato.

De esta forma esta capa minimiza la latencia reduciendo las tareas y loops que se pueden generar en cualquier transacción.

Otra ventaja para mantener la consistencia es que hace una ordenación temporal de las lecturas y elige el dato versionado más óptimo, por eso si realizamos una consulta de lectura de un dato que ha sido modificado después de nuestra lectura, pero por latencia nuestra escritura ha sido más rápida, en vez de devolvernos el dato modificado nos va a dar la versión del dato en el momento de la ejecución de la query.

Ejemplo de Diagrama Completo:

¿Pero en qué mejora esta arquitectura a una arquitectura tradicional?

La verdad es que la arquitectura está bien, pero realmente funciona ¿?

Strong Snapshot Isolation

Aurora DSQL utiliza una variación del protocolo Optimistic Concurrency Control en lugar de un modelo tradicional. Esto es crucial para el rendimiento en un entorno distribuido.

Básicamente el protocolo de Optimistic Concurrency Control define que si estamos ejecutando una transacción que pueden concurrir con otra, el commit de esta transacción solamente puede ejecutarse en el caso que cumpla con las reglas de aislamiento definidas.

Por eso DSQL usa Strong Snapshot Isolation, este modo de trabajo permite que varias transacciones puedan ejecutarse en paralelo cumpliendo una serie de reglas:

Todas las lecturas de la transacción se hacen utilizando el timestamp del inicio de la transacción (Tstart).
En el momento de realizar el commit de los datos se establece el timestamp de commit (Tcommit).
La transacción puede ejecutar el commit única y exclusivamente si ninguna otra transacción ha realizado un commit en la misma clave durante el tiempo de inicio de la transacción (Tstart) y el tiempo de commit (Tcommit)
Se ejecutan las escrituras utilizando el timestamp de Commit (Tcommit)

Esto tiene varias ventajas:

Nunca vamos a ver datos que no vengan después de un commit.
Las lecturas son repetibles y por tanto cacheables.
Las lecturas vienen desde un solo punto de tiempo (lógico).
Las escrituras conflictivas son rechazadas, no se pierden escrituras.

Por este motivo es tan importante la capa de Query Processor y Adjudicator, ya que es la encargada de hacer magia y que esto funcione.

Optimización Multi-Región

Hasta ahora lo que hemos visto parece que no es muy multi-región, además que seguiríamos teniendo un problema con las latencias, pero hemos visto un punto importante DSQL separa las lecturas de las escrituras y además tiene un componente fundamental como Query Processor que es donde se encolan las escrituras antes de realizarse el Commit.

De esta forma toda la transacción se puede llegar a ejecutar localmente aunque los datos estén distribuidos ya que únicamente a la hora de realizar el Commit es cuando necesitamos que la capa de Adjudicator valide y es posible que este adjudicator esté en otra región, pero solamente lo necesitamos para ejecutar el commit, no para escribir el dato.

Esto mejora increíblemente el rendimiento, evitando saltos entre regiones innecesarios, por lo que la latencia real de DSQL es mucho más baja de lo que esperaríamos.

Optimización de FailOver

Otra ventaja es que la capa de Adjudicator es una capa que no guarda todos los datos, solamente las transacciones recientes, para estudiar si hay conflicto por lo que es fácilmente replicable en caso de caída de una región.

Por otro lado la capa de Journal sí está distribuida y replicada, por lo que en caso de caída los datos están replicados en multi-región.

Por último la capa de storage, que siempre es algo más lenta a la hora de replicar, tiene la capacidad de rehacer todas las escrituras pendientes utilizando la capa de Journal.

Comparativa con Aurora PostgreSQL o bases de datos tradicionales

Eliminación del Concepto de "Primario"

En Aurora PostgreSQL, hay un nodo primario que maneja todas las escrituras.

En Aurora DSQL, podemos iniciar una escritura desde cualquier región, minimizando las latencias en multi-región.

Escalabilidad Horizontal Real

Aurora DSQL puede escalar añadiendo más regiones sin que tengamos una degradación de rendimiento.

FailOver más rápido

En Aurora PostgreSQL, si la región primaria falla, es necesario que una de las réplicas en otra región pase a ser primario (proceso de 1-2 minutos).

En Aurora DSQL el proceso es mucho más rápido porque no existe un primario y la carga está distribuida.

Escalado Horizontal

Aurora DSQL es una BBDD con capas totalmente desacopladas, lo que hace que sea posible realizar un escalado horizontal y desescalado horizontal, cosa que en Aurora PostgreSQL o en una BBDD tradicional no es posible

Además es una BBDD totalmente serverless.

Limitaciones y Consideraciones

Aurora DSQL es una maravilla, pero no es una base de datos para todos los públicos, por lo que personalmente no la recomiendo para todo el mundo.

Es una base de datos increíble si tu caso de uso es el adecuado, pero si tienes un caso de uso tradicional, probablemente no sea tu base de datos, incluso puede llegar a ser muchísimo peor que Aurora PostgreSQL.

Es importante remarcar que Aurora DSQL prioriza consistencia sobre latencia extrema:

Transacciones simples: 10-50ms adicionales vs Aurora PostgreSQL.
Transacciones complejas: Puede ser 2-5x más lento que Aurora PostgreSQL.
Lecturas: No hay mucha variación ya que se utilizan réplicas locales.

Comparativa de Latencia en la misma región

Si nuestras cargas están en una única región, Aurora DSQL va a tener una latencia mucho mayor.

Modelo de Precios de Aurora DSQL

Aurora DSQL utiliza un modelo de precios serverless que cobra por:

Compute (Procesamiento):

Se factura por Aurora Compute Units (ACUs) consumidas.
Escalado automático basado en la carga de trabajo.
No es necesario provisionar

Storage (Almacenamiento):

Cobro por GB almacenado por mes
Replicación automática incluida en el precio
Backup automático incluido

I/O (Entrada/Salida):

Cobro por millones de requests de I/O
Incluye tanto lecturas como escrituras

Comparación de Costes: Aurora DSQL vs Aurora PostgreSQL

Escenario ejemplo - Aplicación mediana:

Aurora PostgreSQL (Provisioned):

- Instancia db.r6g.large: ~$200/mes
- Almacenamiento (100GB): ~$10/mes
- I/O (10M requests): ~$2/mes
- Total aproximado: ~$212/mes (región única)

Aurora DSQL (Serverless):

- Compute (equivalente): ~$300-400/mes
- Almacenamiento (100GB): ~$15-20/mes
- I/O (10M requests): ~$3-5/mes
- Multi-región incluida: Sin costo adicional
- Total aproximado: ~$320-425/mes (multi-región)

Factores que afectan el costo:

Patrón de tráfico: Aurora DSQL es más eficiente para cargas variables
Requisitos multi-región: Aurora DSQL incluye replicación en múltiples regiones sin costo adicional.
Complejidad de transacciones: Transacciones distribuidas complejas pueden incrementar el costo
Escalado automático: Puede resultar más económico para aplicaciones con picos de tráfico

¿Cuándo Aurora DSQL es más rentable?

Aplicaciones con tráfico muy variable (serverless se adapta automáticamente) Siempre que la Latencia lo permita
Necesidad de multi-región.

Casos de Uso No Recomendados

Aurora DSQL no es ideal para:

Aplicaciones que requieren latencia ultra-baja (<1ms)
Cargas de trabajo principalmente de lectura
Sistemas con presupuesto muy limitado
Aplicaciones que pueden tolerar eventual consistency

Aurora DSQL es una nueva categoría de base de datos que da una vuelta a las bases de datos distribuidas y multi-región.
Con esta nueva base de datos, AWS ha abierto la puerta a aplicaciones globales que antes eran técnicamente imposibles.

El camino hacia Amazon Aurora DSQL

Miguel Angel Muñoz Sanchez — Wed, 23 Jul 2025 06:00:00 +0000

Amazon Aurora DSQL ha sido probablemente el anuncio más impactante en los últimos años en AWS, es un avance brutal que añade una nueva capa a un servicio como Amazon Aurora que ya era impresionante.

Eso sí, no es una BBDD para todos los públicos y vamos a hablar de ella en esta serie de artículos, en este primer artículo vamos a hablar de cómo hemos llegado hasta aquí y qué alternativas tenemos a Amazon Aurora DSQL, porque Amazon Aurora DSQL puede no ser lo más adecuado para nuestro caso de uso.

Por resumir que es Amazon Aurora DSQL, es una BBDD distribuida que permite la consistencia en escritura y por tanto permite transacciones ACID en multi-región.

En este artículo vamos a ver:

Que es ACID y su importancia
Cómo han ido evolucionando las BBDD para ser más eficientes.
Cómo Aurora revolucionó las BBDD.
Que nos aporta Aurora Global Database y qué limitaciones tiene.
Por qué necesitamos Aurora DSQL

¿ACID qué es eso?

Lo primero es aclarar que es ACID (Atomicity, Consistency, Isolation and Durability).

ACID es un término que se acuñó en 1983 y en el que se basa todo el desarrollo de las BBDD actuales y aunque se acuñó en 1983, desde 1973 ya existían este tipos de Bases de Datos.

Para ser ACID compliant una BBDD debe permitir que sus transacciones cumplan estos requisitos:

Atomicity (Atomicidad)

Una transacción suele tener múltiples pasos, pero tiene que tratarse como una única entidad o la transacción se ejecuta correctamente o falla en su totalidad, no puede dejar datos modificados parcialmente.

Consistency (Consistencia)

La consistencia de una transacción es que los datos son consistentes, de forma que no puedan corromperse al ejecutar una transacción.

Isolation

El aislamiento garantiza que las operaciones se ejecutan de forma aislada y sin afectarse entre sí, de forma que al existir múltiples operaciones modificando el mismo registro una no se ejecute hasta que termine la anterior.

Durability

Garantiza que una transacción una vez completada no pueda perderse incluso en caso de desastre y que los datos sigan estando disponibles una vez recuperado el desastre.

¿Todas las BBDD soportan transacciones ACID?

No todas las BBDD soportan ACID, por ejemplo Amazon MemoryDB no es ACID e incluso otras BBDD en AWS como Athena o DynamoDB originalmente no soportaban transacciones ACID (Actualmente las 2 las soportan).

Ahora vamos a ver cómo se ha ido solucionando este problema históricamente y cómo hemos llegado a Amazon Aurora DSQL.

¿Es fácil conseguir que nuestra BBDD sea ACID?

No, no lo es, de hecho es una de las principales limitaciones de una BBDD, si alguna vez os habéis preguntado por qué las BBDD tienen tantos problemas con los sistemas de ficheros en Unix en general, es por esto.

Una transacción en BBDD suele conllevar muchas operaciones de lectura/escritura, además requiere cierto nivel de bloqueo (Mientras se realiza una transacción no se puede ejecutar otra que modifique los mismos datos).

Esto genera muchos problemas a nivel de latencia, pero no solo de latencia de red, incluso de latencia entre los propios componentes de un servidor. Para las BBDD históricamente la latencia de escritura a disco era un problema muy grande.

Los discos han mejorado mucho en velocidad, pero aun así no era suficiente, por eso hace unos años se optó por escribir en memoria en vez de disco. La memoria RAM es mucho más rápida en escritura y lectura por lo que todo son ventajas, pero también tiene una serie de problemas. Por un lado es volátil, con lo que podemos perder los datos y por otro lado tampoco podemos cargar el contenido entero, porque la memoria habitualmente tiene menos tamaño que nuestros discos.

Así que se optó por utilizar algo bastante habitual que es la memoria paginada que es crear “Páginas” de memoria que no dejan de ser bloques físicos de memoria. De esta forma podemos tener parte de nuestros datos en una página de memoria (Los datos frecuentes o nuevos) y volcamos de forma asíncrona los datos a disco para persistirlos. Esto además mejora tanto el performance al usar memoria, como el performance de disco ya que podemos optimizar las escrituras y las lecturas.

Pero tendríamos un problema en caso de un fallo antes de volcar los datos a disco o si necesitamos recuperarlos, pero esto se soluciona con un sistema de logging transaccional conocido como Write-Ahead Logging (WAL) que sigue el principio DO-UNDO-REDO.

Adicionalmente a escribir en memoria el resultado la transacción, se escribe un log con la transacción en sí:

De esta forma si tenemos un fallo podemos cargar una página antigua que esté persistida y aplicar todos las transacciones que no se han persistido (REDO). O en caso contrario si queremos rectificar una transacción podemos saber que ha modificado y volver al estado anterior (UNDO):

Este sistema mejora infinitamente el rendimiento de las BBDD y es algo que lleva utilizándose muchos años en cualquier motor de BBDD.

¿Y cómo una BBDD puede ser ACID en múltiples Zonas de Disponibilidad?

Hasta aquí hemos visto cómo conseguimos esto en un solo servidor, pero si queremos tener alta disponibilidad, tenemos que montar 2 servidores (Un primario y un Stand-By) y aquí aparece el principal problema de todos la latencia de red.

Una transacción no es solo una lectura o escritura en una BBDD, sino que es una secuencia de operaciones y por tanto el tiempo de ejecución de una transacción depende de la latencia.

Esto es un problema con una replicación síncrona, porque tenemos que esperar a que cada operación se replique. Esto incrementa mucho la duración de la transacción, porque tenemos que mandar la operación por red, que se ejecute en la réplica y esperar a que nos devuelva el ACK. Como la latencia de red es mucho más elevada, el tiempo de ejecución de una transacción se multiplica exponencialmente.

Podemos optar por una solución un poco más eficiente, que son las Read Réplicas, que en vez de utilizar una replicación síncrona utilizan una replicación asíncrona, de forma similar a como hacíamos con el disco, pero que van a tener un lag de replicación que es el tiempo en el que la réplica no tendrá el dato actualizado.

Seguramente os preguntaréis cómo podemos garantizar que una transacción es ACID con una replicación, si vamos a tener un lag de replicación, la respuesta es sencilla, limitando las escrituras a una sola instancia. De esta forma garantizamos la consistencia y el aislamiento.

¿Es mejorable?

Este método era mejorable, ya que el lag de replicación nos puede afectar bastante y aquí es donde entra la magia de Amazon Aurora.

Amazon Aurora hizo algo muy interesante que fue separar la capa de Almacenamiento y la de Computo. Dejando el motor de la BBDD en una instancia y gestionando la capa de almacenamiento de forma independiente.

El motor de BBDD es exactamente igual, pero a la hora de realizar una escritura en vez de llamar directamente a disco, llama a los Storage Node de Aurora.

Cada nueva escritura lanza este esquema:

Los registros se reciben en el Incoming Queue y se almacenan en el Hot Log en memoria
Se devuelve el ACK al motor de la BBDD sin esperar la persistencia
Los datos se registran en el Update Queue y se agrupan para optimizar las escrituras
Se genera un nuevo Data Page distribuyéndolo en 6 copias sincronizadas (2 por cada AZ)
Se realizan backups periódicos de Hot Logs y Data Pages a S3

De esta forma se consigue una latencia de replicación muy baja, menor a 100 ms (La cual es bajísima para un entorno multi AZ) en varias zonas de disponibilidad repartidas en 6 Copias, además se consiguen backups continuos y la posibilidad de hacer restauraciones a puntos determinados de tiempo.

Lo mejor es que esto no impacta en el rendimiento de la BBDD ya que las operaciones de Storage no se ejecutan en la misma instancia donde está nuestro motor de BBDD, permitiendo un mayor rendimiento en general.

Y además se replica vía Log todas las transacciones en todos los nodos.

Aurora soporta hasta 15 read réplicas y 64 TB de almacenamiento automático y puede manejar hasta 500,000 lecturas y 100,000 escrituras por segundo.

Nota: Existen más pasos que he simplificado para un correcto entendimiento, ya que es un almacenamiento distribuido, no solo existe un nodo de Storage, etc.

Nota 2: A nivel de motor de BBDD también se guardan los registros en memoria de forma que la escritura es más rápida.

¿Y en múltiples Regiones?

Si necesitamos replicar nuestra BBDD en otra región, nos vamos a encontrar que la latencia de replicación es mucho mayor, básicamente porque la latencia de red entre regiones es muy alta.

Pero aquí es donde entra Amazon Aurora Global Database a ayudarnos.

Amazon Aurora Global Database extiende su modelo de replicación a otras regiones, en este caso además de separar la capa de Almacenamiento, separa la capa de replicación.

De esta forma vamos a tener una capa independiente para gestionar la replicación entre regiones y una capa de storage independiente para gestionar la replicación entre zonas. Esto permite que Amazon Aurora Global Database tenga mejor rendimiento a nivel de BBDD y una replicación entre regiones muy optimizada.

Cada nueva escritura lanza este esquema:

Se escriben los nuevos registros en los Storage nodes y réplicas de la BBDD zonales y adicionalmente se escribe en un servidor de replicación.
El servidor de replicación replica los registros de escritura en el servidor con el agente de replicación perteneciente al grupo de servidores de replicación en otras regiones.
Este servidor de replicación actúa como si fuese una BBDD primaria y ejecuta los registros de escritura tanto en la réplica global de la BBDD como en los Storage nodes de esta región.
Por último, si el servidor de replicación detecta que no ha recibido algún registro de escritura, los recogerá de los storage nodes de la región primaria.

De esta forma también se consigue una latencia de replicación muy baja, menor a 1 segundo en hasta 5 regiones secundarias. Cada región secundario tendrá adicionalmente replicación en zonas de disponibilidad y 6 Copias repartidas entre ellas, además tenemos backup multiregionales y continuos ya que el backup se almacenará también en cada región secundaria.

¿Y la escritura en múltiples regiones?

Es el mayor problema que hay en este modelo, ya que las escrituras solo pueden ejecutarse en la región primaria y por tanto la latencia de escritura en multiregión es altísima.

Existe una solución intermedia que es utilizar write forwarding en Amazon Aurora, esto nos permite configurar una réplica global para escribir en ella, aunque realmente lo que estamos haciendo es enviar estas peticiones con un forward a la BBDD principal.
Es una forma un poco más eficiente de escribir en multiregion, que nos permite utilizar endpoints por región, pero no es muy eficiente en escritura.

El Desafío de las escrituras multiregión consistentes

Como hemos visto, tanto Amazon Aurora como Aurora Global Database han resuelto los problemas de rendimiento y replicación, siguen teniendo una limitación fundamental: las escrituras deben centralizarse en una región primaria para garantizar la consistencia ACID.

Esta arquitectura funciona perfectamente para aplicaciones que pueden funcionar con escrituras centralizadas, pero ¿qué pasa cuando necesitamos que usuarios en diferentes regiones puedan escribir con baja latencia manteniendo la consistencia de escritura? Aquí es donde Amazon Aurora DSQL entra a escena.

Uno de los problemas de las escrituras, es controlar la secuencia de tiempos, porque si lanzamos una escritura desde una región y lanzamos otra escritura sobre el mismo registro 100ms después en otra región, para cada una de estas regiones el dato correcto no es el mismo, porque no podemos controlar el tiempo y tendremos un problema de consistencia bastante grande.
(Bueno realmente sí podemos controlar el tiempo, pero lo veremos en el próximo artículo).

Conclusiones.

A lo largo de este artículo hemos recorrido la evolución en AWS que ha llevado al desarrollo de Amazon Aurora DSQL, desde los fundamentos de ACID hasta las limitaciones de los sistemas multiregión actuales.

El sistema de replicación que utiliza Amazon Aurora y Amazon Aurora Global Database es una auténtica maravilla, porque mejora el performance increíblemente y además reduce los tiempos de replicación drásticamente.

Si no necesitamos escrituras multiregion Amazon Aurora o Amazon Global Database es la mejor opción para la mayoría de casos, pero en caso de requerir una BBDD global, distribuida y con escritura consistente en multiregion tenemos que optar por Amazon Aurora DSQL.

Característica	Aurora	Aurora Global	Aurora DSQL
Latencia escritura	Baja en la zona primaria	Baja en la zona primaria y alta en multiregion	Baja en multiregion
Regiones escritura	1	1 primaria y hasta 5 adicionales con write forwarding	Múltiples
Read réplicas	Hasta 15	Hasta 16 por región	Distribuidas globalmente
Casos de uso	Apps regionales	Apps globales con lectura intensiva, dashboards	Apps globales con escritura intensiva en múltiples regiones, gaming, IoT

¿Cuánto cuesta Aurora DSQL?

Aunque AWS todavía no ha publicado precios oficiales, Aurora DSQL será considerablemente más caro que Aurora debido a su complejidad distribuida.

Tomando como referencia Aurora MySQL/PostgreSQL\
Aurora Global Database: es un 65% más caro \
Aurora DSQL: Se estima entre 3 y 5 veces más que Aurora Global

¿Cuál elegir?

NO uses Aurora DSQL si:

Tus escrituras pueden centralizarse en una región (>80% de casos)
Necesitas usar MySQL como motor de BBDD
Tus transacciones no requieren baja latencia en escritura multiregión

Puedes utilizar Aurora Global Database cuando :

Puedes tolerar write forwarding o escrituras en una sola región
Requieres lecturas intensivas multiregion con escrituras ocasionales
Necesitas un DR multiregión pero no escrituras activo-activo

Puedes utilizar Aurora Cuando:

Tienes Aplicaciones regionales
El presupuesto limitado
Requieres una simplicidad operacional

Ahora que tenemos claro el problema, nos tenemos que hacer una pregunta: ¿Cómo ha conseguido AWS una BBDD con escritura multiregional sin romper ACID?

En el próximo artículo desvelaremos los secretos de Aurora DSQL y como AWS ha conseguido domar el tiempo en una BBDD.

👉 Próximo: "Aurora DSQL: Como controlar el tiempo"

The Path to Amazon Aurora DSQL

Miguel Angel Muñoz Sanchez — Wed, 23 Jul 2025 06:00:00 +0000

Amazon Aurora DSQL has probably been the most impactful announcement in recent years at AWS. It's a significant advancement that adds a new layer to a service like Amazon Aurora, which was already impressive.

However, it's not a database for everyone, and we will discuss it in this series of articles. In this first article, we'll discuss how we arrived at this point and what alternatives we have to Amazon Aurora DSQL, as Amazon Aurora DSQL may not be the most suitable option for our use case.

To summarize, Amazon Aurora DSQL is a distributed database that provides write consistency, enabling ACID transactions in multi-region scenarios.

In this article, we'll cover:

What ACID is and its importance
How databases have evolved to be more efficient
How Aurora revolutionized databases
What Aurora Global Database brings us and its limitations
Why do we need Aurora DSQL

What is ACID?

First, let's clarify what ACID is (Atomicity, Consistency, Isolation, and Durability).

Researchers coined the term ACID in 1983, and it forms the foundation of all current database development. Although researchers coined the term in 1983, these types of databases have existed since 1973.

For a database to be ACID compliant, its transactions must meet these requirements:

Atomicity

A transaction typically involves multiple steps, but the system must treat it as a single entity; either the transaction executes correctly or fails. It cannot leave data partially modified.

Consistency

Transaction consistency ensures that data remains unchanged, preventing corruption when executing a transaction.

Isolation

Isolation ensures that operations execute in isolation without affecting each other, so when multiple operations are modifying the same record, one doesn't execute until the previous one finishes.

Durability

The system guarantees that once it completes a transaction, it cannot lose the transaction, even in the event of a disaster, and the data remains available once the system recovers from the disaster.

Do all databases support ACID transactions?

Not all databases support ACID. For example, Amazon MemoryDB is not ACID, and even other AWS databases, such as Athena or DynamoDB, initially didn't support ACID transactions (both currently support them).

Now, let's examine how developers have historically solved this problem and how we arrived at Amazon Aurora DSQL.

Is it easy to make our database ACID?

No, it's not. It's one of the main limitations of a database. If you've ever wondered why databases have so many problems with Unix file systems in general, this is why.

A database transaction typically involves multiple read/write operations, and it requires a certain level of locking (i.e., while the system performs a transaction, another transaction that modifies the same data cannot execute).
This creates many latency problems, not just network latency, but even latency between server components. For databases, historically, disk write latency has been a significant problem.

Manufacturers have significantly improved disk speeds, but it still wasn't enough. Therefore, years ago, developers decided to write to memory instead of disk. RAM provides significantly faster writing and reading, offering several advantages, but it also presents some challenges. On the one hand, it's volatile, we can lose data; on the other hand, we can't load the entire content because memory usually has less capacity than our disks.

Therefore, developers decided to utilize a common approach: paged memory, which creates memory "pages" that are physical memory blocks. This way we can have part of our data in a memory page (frequent or new data) and asynchronously dump data to disk to persist it. This improves both performance and disk utilization by optimizing write and read operations.

However, we would encounter a problem in the event of failure before dumping data to disk or if we need to recover it. A transactional logging system known as Write-Ahead Logging (WAL) addresses this issue, which follows the DO-UNDO-REDO principle.

In addition to writing the transaction result to memory, the system writes a log with the transaction itself:

This way, if we have a failure, we can load an old persisted page and apply all transactions that haven't been persisted (REDO). Or conversely, if we want to rectify a transaction, we can know what it modified and return to the previous state (UNDO):

This system continuously improves database performance and has been utilized for many years in various database engines.

How can a database be ACID across multiple Availability Zones?

So far, we've seen how to achieve this on a single server, but if we want high availability, we need to set up two servers (a primary and a standby), and here appears the main problem of all: network latency.

A transaction is not just a read or write in a database, but a sequence of operations, so the execution time of a transaction depends on latency.

This is a problem with synchronous replication because we have to wait for each operation to replicate. This dramatically increases transaction duration because we have to send the operation over the network, have it execute on the replica, and wait for it to return the ACK. Since network latency is much higher, transaction execution time multiplies exponentially.

We can opt for a slightly more efficient solution: Read Replicas, which, instead of using synchronous replication, use asynchronous replication, similar to how we did with disk. However, they will experience replication lag, which is the time when the replica does not have the most up-to-date data.

You might wonder how we can guarantee that a transaction is ACID with replication if we have replication lag. The answer is simple: by limiting writes to a single instance. This way, we guarantee consistency and isolation.

Can it be improved?

This method is improvable since replication lag can significantly affect us, and this is where Amazon Aurora's magic comes in.

Amazon Aurora did something exciting: it separated the Storage and Compute layers, leaving the database engine in one instance and managing the storage layer independently.

The database engine is precisely the same, but when performing a write, instead of calling the disk directly, it calls Aurora's Storage Nodes.

Each new write launches this scheme:

Records are received in the Incoming Queue and stored in the Hot Log in memory
ACK is returned to the database engine without waiting for persistence
Data is registered in the Update Queue and grouped to optimize writes
A new Data Page is generated, distributing it in 6 synchronized copies (2 per AZ)
Periodic backups of Hot Logs and Data Pages are made to S3

This approach enables the achievement of very low replication latency, less than 100 ms (which is exceptionally low for a multi-AZ environment), across multiple availability zones, with six copies, along with continuous backups and the ability to perform point-in-time restores.

The best part is that this doesn't impact database performance, as storage operations are executed on a separate instance from where our database engine resides, allowing for better overall performance.

Additionally, the system replicates all transactions via the Log to all nodes.

Aurora supports up to 15 read replicas and 64 TB of automatic storage and can handle up to 500,000 reads and 100,000 writes per second.

Note: There are additional steps that I've simplified for proper understanding. Since it's a distributed storage system, there isn't just one Storage node, etc.

Note 2: At the database engine level, records are also stored in memory, so writing is faster.

What about multiple regions?

If we need to replicate our database to another region, we'll find that replication latency is significantly higher, primarily because network latency between regions is very high.

However, this is where Amazon Aurora Global Database comes to our aid.

Amazon Aurora Global Database extends its replication model to other regions. In this case, in addition to separating the Storage layer, it separates the replication layer.

This way, we'll have an independent layer to manage replication between regions and an independent storage layer to manage replication between zones. This enables Amazon Aurora Global Database to achieve better database-level performance and highly optimized inter-region replication.

Each new write launches this scheme:

New records are written to Storage nodes and zonal database replicas, and additionally written to a replication server.
The replication server replicates write records to the server with the replication agent belonging to the replication server group in other regions.
This replication server acts as if it were a primary database and executes write records both in the global database replica and in this region's Storage nodes.
Finally, if the replication server detects it hasn't received any write records, it will collect them from the primary region's storage nodes.

This approach also achieves very low replication latency, with values of less than 1 second in up to 5 secondary regions. Each secondary region will also have availability zone replication and six copies distributed among them, in addition to multi-regional and continuous backups, as the system stores backups in each secondary region.

What about multi-region writes?

This is the biggest problem with this model, as writes can only be executed in the primary region, resulting in extremely high multi-region write latency.

There's an intermediate solution: using write forwarding in Amazon Aurora. This allows us to configure a global replica to write to it, although what we're doing is sending these requests with a forward to the central database.

It's a slightly more efficient way to write in multi-region, allowing us to use endpoints per region, but it's not very efficient for writing.

The Challenge of Consistent Multi-Region Writes

As we've seen, both Amazon Aurora and Aurora Global Database have addressed performance and replication issues. However, they still have a fundamental limitation: writes must be centralized in a primary region to ensure ACID consistency.

This architecture works perfectly for applications that can function with centralized writes, but what happens when we need users in different regions to be able to write with low latency while maintaining write consistency? This is where Amazon Aurora DSQL comes into play.

One of the write problems is controlling the time sequence, because if we launch a write from one region and launch another write on the same record 100ms later in another region, the correct data for each of these regions is not the same. After all, we can't control time, and we'll have a reasonably significant consistency problem.

(Well, we actually can control time, but we'll see that in the following article.)

Conclusions

Throughout this article, we've covered the evolution in AWS that led to the development of Amazon Aurora DSQL, from ACID fundamentals to the limitations of current multi-region systems.

The replication system used by Amazon Aurora and Amazon Aurora Global Database is truly remarkable, as it significantly improves performance and drastically reduces replication times.

If we don't need multi-region writes, Amazon Aurora or Amazon Global Database is the best option in most cases. However, if we require a global, distributed database with consistent multi-region writes, we need to opt for Amazon Aurora DSQL.

Feature	Aurora	Aurora Global	Aurora DSQL
Write latency	Low in primary zone	Low in primary zone and high in multi-region	Low in multi-region
Write regions	1	1 primary and up to 5 additional with write forwarding	Multiple
Read replicas	Up to 15	Up to 16 per region	Globally distributed
Use cases	Regional apps	Global apps with intensive reading, dashboards	Global apps with intensive writing in multiple regions, gaming, IoT

How much does Aurora DSQL cost?

Although AWS hasn't published official prices yet, Aurora DSQL will be considerably more expensive than Aurora due to its distributed complexity.

Taking Aurora MySQL/PostgreSQL as reference:
Aurora Global Database: is 65% more expensive
Aurora DSQL: Estimated between 3 and 5 times more than Aurora Global

Which to choose?

DON'T use Aurora DSQL if:

Your writes can be centralized in one region (>80% of cases)
You need to use MySQL as a database engine
Your transactions don't require low-latency multi-region writes

You can use Aurora Global Database when:

You can tolerate write forwarding or writes in a single region
You require intensive multi-region reads with occasional writes
You need multi-region DR but not active-active writes

You can use Aurora when:

You have regional applications
Limited budget
You require operational simplicity

Now that we have the problem clear, we need to ask ourselves a question: How has AWS achieved a database with multi-regional writes without breaking ACID?

In the following article, we'll unveil the secrets of Aurora DSQL and how AWS has managed to tame time in a database.

👉 Next: "Aurora DSQL: How to Control Time"

Como optimizar las cargas IPv4 en AWS y ademas generar ahorro de costes.

Miguel Angel Muñoz Sanchez — Tue, 20 Feb 2024 22:40:37 +0000

Cover image by Sander Weeteling on Unsplash

Introducción.

AWS anunció en julio de 2023 que todas las direcciones IPv4 públicas a partir del 1 de febrero de 2024 tendrían coste.

Hasta ahora, en AWS solo se pagaba por direcciones IPv4 públicas cuando no estaban asignadas a ningún recurso, y algunas personas piensan que es terrible que AWS esté tratando de ganar más dinero ...

Pero otras personas como nosotros pensamos que eso no es gran cosa y que es una excelente oportunidad para guardar direcciones IPv4.
(AWS sigue perdiendo dinero por cada dirección IPv4 aún facturándolas)

Tenemos un gran problema con las direcciones IPv4; Cuando DARPA (Defense Advanced Research Projects Agency) escribió el protocolo en 1981, nadie pensó que se agotarían 4.294.967.296 IP en el futuro.

En aquella época, los ordenadores personales eran raros, la Web no existía y nadie podía imaginar la idea de los smartphones, o de los dispositivos IOT.

En 2011, IANA (Internet Assigned Numbers Authority) asignó los últimos bloques de direcciones IPv4. Si ahora necesitamos una dirección IPv4 hay que comprarla a cualquier persona que tenga una dirección IPv4 sin usar, lo que crea muchos problemas para cualquier empresa que necesite una dirección IPv4.

A finales de 1995, el IETF (Internet Engineering Task Force) comenzó a escribir un nuevo protocolo (IPv6) porque sabían en ese momento que las direcciones IPv4 se agotarían en unos pocos años. En ese momento Internet estaba en una etapa temprana de adopción (pocas personas lo usaban).

La adopción de IPv6 es demasiado lenta. Muchas empresas de telecomunicaciones utilizan IPv6, y nosotros, como usuarios de ellas, utilizamos IPv6. Aun así, muchas empresas que publican servicios en Internet no lo utilizan porque es un cambio difícil de implementar rápidamente.

Esa es la razón de este cambio. Es necesario utilizar menos direcciones IPv4; Si AWS no traspasa ese coste, se seguirán usando muchas direcciones IPv4.

Y desspues de esta introduccion la grandes preguntas que aparecen son:

¿Cuántas direcciones IPv4 se estan usando en AWS?
¿Cuánto cobrará AWS por estas IPs?
¿Y cómo se puede reducir el número de IPv4 fácilmente sin usar IPv6?

Cómo conocer las direcciones IPv4 que estan en uso.

Con este anuncio, AWS lanzó una herramienta para descubrir, analizar y auditar las direcciones IPv4 públicas que se utilizan. Esta herramienta se llama Amazon VPC IP Address Management (IPAM).

Antes de profundizar en este tema, debemos diferenciar cuatro tipos de direcciones IPv4 públicas en AWS:

EC2 public IP addresses: Las direcciones IPv4 públicas se toman de un grupo de Amazon y solo se asocian con las instancias EC2. Al detener, hibernar o finalizar la instancia, la IP se devuelve al grupo y no se puede reutilizar.
Elastic IP addresses: Direcciones IPv4 públicas que se pueden asignar a las cuentas. Se pueden asociar y desasociar de instancias según sea necesario. Se asignan hasta que se decide liberarlas (de la cuenta y no del servicio)
Service-managed public IPv4 addresses IPs de servicios administrados desde Internet de AWS implementados en su cuenta.: Elastic Load Balancers, NAT Gateways, AWS Global Accelerator, AWS Site-to-Site VPN...
BYOIP addresses (IP públicas que te pertenecen y que puedes traer hacia AWS) AWS no te cobrará por traer tu propio espacio de IPs públicas Estás IP se pueden usar en grupos para asignarlas a las instancias EC2 o puertas de enlace NAT.

Teniendo esto eso en cuenta, ahora es el momento de utilizar el IPAM de Amazon VPC para comprobar el espacio público IPv4 que está en uso y tus recursos.

Inicie sesión en tu cuenta de AWS.
Busque Amazon VPC IP Address Manager en la barra de búsqueda.

Haga clic en “Create IPAM.”
Seleccione las opciones marcadas:

Notas:

En el nivel gratuito se realizarán las comprobaciones de tu cuenta para las direcciones IPv4 públicas.
En el nivel avanzado verificará en toda la organización las direcciones IP públicas y privadas.

Puedes agregarle un tag de nombre o una descripción (opcional)
Haga clic en “Add All Regions” para realizar un informe sobre nuestra infraestructura global
Luego, haga clic en “Create IPAM.”

Después de unos minutos, podrá ver un informe con todas las IPv4 públicas en el menú Public IP Insights:

Por cada IPv4 en uso, AWS facturará $0,005 por hora; esto significa 0,005 x 8760 horas en un año = *$43,8 por año por cada IPv4 *.

Si se tienen 10 IP en uso, se pagarán $438 por estas direcciones IP.

Si se tienen 100... se sumarán $4380.

Si se tienen 1000... bueno... se agregara otro 0.

Tu cara, antes y después de usar la herramienta IPAM.

¿Cómo puedo optimizar mi arquitectura para reducir el uso de IPv4?

Usar un Load Balancer.

Usar un Load Balancer para exponer nuestra aplicación es una de las buenas prácticas de AWS y reduce la cantidad de IP públicas; en lugar de usar una IP para cada EC2, usaremos una IP por subred donde esté implementado el ALB.

Ventajas:

Mejora tu disponibilidad porque los ALBs trabajan en una configuración de alta disponibilidad.
Permite la escalabilidad utilizando Auto Scaling Groups como Targets del Load Balancer.
Permite desacoplar la encriptación SSL utilizando certificados en el propio Load Balancer.
Tu seguridad puede mejorar utilizando las reglas del WAF.
Se puede usar puertos HTTP o HTTPS usando ALB o cualquier puerto TCP usando NLB.

Desventajas:

Costo (no demasiado, pero agrega coste a la solución)

Usar un Load Balancer haciendo de proxy inverso

¿Qué pasa si implementamos muchos Load Balancers con pocas instancias EC2? Eso es un problema porque estamos desperdiciando muchas IP (y balanceadores de carga)

Desde 2017, AWS admite el uso de un Application Load Balancer como un proxy inverso. Esta es una mejora notable porque podemos usar un Load Balancer para múltiples grupos objetivo dependiendo de la cabecera host con la URL solicitada.

Con esta funcionalidad, se puede utilizar un solo Load Balancer para todas las aplicaciones.

¿Pero qué pasa con el cifrado? Necesitamos utilizar varios certificados, uno por URL.

Podrías usar la misma zona DNS y un certificado wildcard. Aun así, no es una muy buena idea y a los equipos de seguridad no les gustan los certificados wildcard (existen algunos problemas de seguridad con los certificados wildcard...)

Pero podemos usar otra característica interesante de ALB como SNI (Server Name Indicator) que permite usar múltiples certificados para diferentes nombres DNS en el mismo ALB.

Ventajas:

Reducir el número de IP Públicas utilizadas por las aplicaciones
Reducir el número de ALB utilizados por las aplicaciones.
Se ahorran costes porque menos ALB e IP públicas significan menos costes.
Centralizar la gestión de ALBs.

Desventajas:

Crea una dependencia de otros equipos. Si hay varios stacks para gestionar cada aplicación, se crea una dependencia con el stack que contiene el ALB centralizado.
Puede ser un problema al usar WAF porque las reglas de WAF son las mismas para todas las aplicaciones y algunas reglas deben ser más específicas.
La solución sólo funciona en una implementación de múltiples cuentas. Los ALB pueden enviar solicitudes a Target Groups en la misma cuenta, pero no a Target Groups en otras cuentas. Los ALB permiten enviar solicitudes a las IP de otras cuentas (si existe conectividad privada), pero eso no permite elasticidad. Se podría usar un servidor proxy inverso en una EC2, pero no es una solución administrada y genera más sobrecarga operativa.

Usar un Bastion

Usar un Bastion host es una solución típica para acceder a servidores en la nube; en lugar de agregar una dirección IP pública a cualquier servidor que se administra, se crea un Bastion Host con una IP pública y se inicia sesión en este Bastion Host usando SSH o RDP (dependiendo del sistema operativo de nuestro Bastion Hosts). Desde este bastión podremos saltar a las EC2 o RDS.

Esa es una forma segura de acceder los recursos porque se puede limitar el alcance del security group agregando solo las IP públicas que se usan desde la red corporativa o las IP públicas individuales de los Admins.

Desde el Bastion Host se puede acceder a cualquier EC2, RDS, ECS, EKS, etc.

Solo es necesario agregar el security group o IP del Bastion Host a los security group para las instancias a las que necesitamos acceso.

Podemos acceder a la VPC donde está el Bastion Host, pero también podemos acceder a otras VPC si implementamos el peering de VPC o implementamos una topología de Transit Gateway.

Estas interconexiones entre VPC permiten centralizar nuestro Bastion host de forma que se reduce y simplifica la infraestructura de gestión.

Este método es fácil de usar; un Bastion Host es algo habitual; se puede usar diferentes claves de acceso, diferentes usuarios del sistema operativo, es auditable, etc.

Además, si es necesario una forma más segura de acceder, se puede usar un Cliente VPN en lugar de una conexión directa a los Bastion Hosts usando SSH o RDP.

Ventajas:

Se reduce la cantidad de IP públicas utilizadas para administrar instancias.
Se mejora la seguridad porque hay menos puntos de entrada a los servidores.
Se necesita mantener menos instancias para la administración.
Un Bastion Host es una topología familiar en infraestructura de TI.
Se pueden guardar los logs de acceso al Bastion host y auditar la actividad.

Desventajas:

Se necesita una EC2 para la gestión.
Se debe gestionar y auditar security group para limitar el acceso a nuestro Bastion Host.
Existe riesgo de exponer la infraestructura si alguien obtiene acceso a Bastion Host.
Se pueden recibir ataques de fuerza bruta SSH y se debe implementar métodos de protección.

Usar Session Manager

AWS Systems Manager Session Manager (SSM)](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) es una manera de acceder a instancias EC2 como si estuviéramos usando SSH pero sin utilizarlo, con beneficios adicionales de seguridad de AWS.

Para usar SSM, se tienen que cumplir unos requisitos:

Es necesario tener los agentes SSM instalados en las instancias (Si se usa una AMI de AWS, el agente viene instalado por defecto).
La Instancia necesita acceso al endpoint de SSM usando un NAT Gateway o desplegando un endpoint privado de AWS.
Es necesario añadir un perfil de Instancia con permisos a SSM para permitir al EC2 ejecutar algunas llamadas API a servicios SSM.
Es necesario permisos para usar SSM en el usuario o rol de IAM.

Se pude realizar la configuración usando la Documentación de AWS.

Este método de acceso permite iniciar sesión en una instancia sin utilizar SSH, utilizando las credenciales de IAM. Esto es muy útil porque se puede utilizar IAM identity Center y centralizar el acceso a los sistemas utilizando las credenciales de un IdP en lugar de las credenciales locales de Linux.

Además, si se utiliza IAM Identity Center o IAM Roles, se estan utilizando credenciales de seguridad temporales que mejoran significativamente la seguridad. Esas credenciales rotan muy a menudo (sólo están activas durante unas horas o menos si así se decide). Si alguien roba estas credenciales, se revocarán automáticamente cuando caducara el token, y también se pueden revocar las credenciales inmediatamente.

Si se utilizan servidores Windows, se puede utilizar AWS Systems Manager Fleet Manager, que utiliza un sistema similar pero para conexiones RDP.

También, es posible utilizar una mezcla de SSM con un Bastion Host privado.

Es el mismo método que si se utilizara un Bastion Host pero sin exponerlo a Internet.

Sin embargo, SSM es inutilizable para algunas personas porque necesitan usar X11 en servidores remotos o subir archivos usando SCP o la terminal en lugar de la consola de AWS o AWS CLI.

Pero no hay problema; SSM tiene una característica llamada Port Forwarding que nos permite crear un túnel desde un ordenador a los Bastion Hosts y conectarse a otros servidores directamente. Es como un túnel SSH y es muy potente.

Se puede acceder a los servidores RDS o sitios web privados sin publicarlos. También se puede reenviar X11 y utilizar consolas gráficas remotas.

Ventajas:

No es necesario usar IPs Públicas
Se utilizan credenciales IAM con credenciales temporales en lugar de credenciales Linux o claves SSH.
Es posible usar credenciales IdP para iniciar sesión en instancias EC2.
Se puede tener una conexión cifrada HTTPs cifrada por AWS.
No se exponen los servidores en internet.
Es posible auditar logs y acciones.
Se pueden explorar logs en Cloudwatch y crear métricas y alarmas.
Es posible revocar credenciales automáticamente.
Se puede utilizar la función de reenvío de puertos para crear túneles seguros.
La solución no tiene ningún coste; SSM es gratuito.

Desventajas:

Es necesario utilizar AWS CLI o la consola de AWS para conectarse a los servidores.
El método es más complejo y es necesario que los usuarios estén familiarizados con este tipo de túneles.
Es necesario instalar agentes y crear perfiles de Instancia.

Usar EC2 Instance connect de manera privada.

El servicio EC2 Instance Connect (EIC) permite conectar con las instancias EC2 públicas/privadas estableciendo una sesión SSH a través del navegador. La API de instance connect publicará una clave pública SSH de un solo uso en los metadatos de la instancia EC2, que permanecerá ahí durante 60 segundos.

Si la instancia tiene instalado EC2 Instance Connect, un daemon SSH extraerá la información de la clave pública de los metadatos de la instancia para la autenticación en este periodo de tiempo.
La conexión SSH se establecerá utilizando la clave privada de un solo uso que la API de Instance Connect generó en el momento de la solicitud.

IAM respalda el servicio; ningún usuario que no tenga acceso a este servicio podrá conectarse. Para obtener más información sobre el funcionamiento del servicio, se puede consultar la guía del usuario.

Inicialmente, EC2 instance connect estaba pensado para conectarse a instancias EC2 con una dirección IP pública. En Junio de 2023, AWS lanzó una actualización de este servicio, permitiendo a los usuarios conectarse a las instancias EC2 con IP Privada a través de internet.

Para realizar esta tarea, se crea un EC2 Instance Connect Endpoint en la subnet privada de tu VPC. Este endpoint actúa como un túnel privado que te conecta desde Internet con las instancias privadas.

Es posible conectarse a diferentes subredes dentro de la VPC utilizando el mismo endpoint.

(Si la conexión es a una instancia en una AZ diferente del Endpoint, pueden aplicarse algunos cargos por transferencia de datos)

Aquí se puede encontrar una guía sobre cómo conectarse utilizando el EIC Endpoint a una instancia privada que usa IPv4.

Ventajas:

Es posible conectarte a las instancias desde Internet sin un gateway.
El acceso para crear y utilizar los endpoints para realizar la conexión puede restringirse/permitirse a través de políticas y permisos de IAM.
Mejora la seguridad ya que se tiene un control de acceso centralizado a las instancias EC2 y se elimina la necesidad de gestionar las claves SSH.
Se elimina la necesidad de un Bastion host.
CloudTrail rastrea todos los eventos.

Desventajas:

No soporta direcciones IPv6.

Migrar a IPv6

Desde 2011, AWS ha estado promoviendo IPv6; cada año, Amazon ha ido añadiendo y adaptando más servicios para utilizar esta tecnología.

Modos de compatibilidad de red soportados por AWS:

Solo IPv4: Los recursos pueden comunicarse a través de IPv4; si se comunican con IPv6, requerirá una capa de interoperabilidad.
Solo IPv6: Los recursos pueden comunicarse a través de IPv6; si se comunican con IPv6, se requerirá una capa de interoperabilidad.
Dual- stack: Los recursos pueden comunicarse a través de IPv4 e IPv6.

En este artículo se puede encontrar la lista de servicios que pueden utilizar IPv6.

Para más información sobre cómo diseñar una red IPv6, se puede seguir el manual de mejores prácticas.

Ventajas:

Reduce costes al dejar de utilizar IPv4
Elimina la necesidad de mecanismos de traducción (NAT), eliminando la sobrecarga de rendimiento de las traducciones, simplificando el enrutamiento de paquetes
IPv6 añade más seguridad, utilizando IPsec como estándar

Desventajas:

No todos los servicios soportan IPv6 _ Debe realizarse un análisis de la arquitectura antes de implementar/adaptar nada.

Artículo creado para la comunidad "AWS Español" por:

Luis Maria Horvath Mayor

Miguel Angel Muñoz Sanchez

¿Es AWS seguro?

Miguel Angel Muñoz Sanchez — Thu, 01 Feb 2024 09:57:16 +0000

Seguramente, esta pregunta o nos la hemos hecho en alguna ocasión o, bien, nos la ha preguntado alguien. Desde que empecé en este mundo de AWS, me he dado cuenta de que mucha gente asume que la seguridad en Cloud o no existe o es muy baja.

Y, he de reconocer que, antes de empezar en este mundo, yo también tenía esta visión, pero era una visión basada en mi desconocimiento y en ciertas afirmaciones que había leído o escuchado que eran erróneas.

Vamos a dedicar este post a intentar explicar ciertos conceptos de la seguridad en AWS, repasar cómo funciona AWS y cómo podemos securizar nuestras cargas al máximo.

Haciendo peticiones a AWS

Lo primero es saber cómo funciona una petición en AWS. Vamos a explicar una llamada para crear un bucket S3 y desde ahí vamos a ver cómo de seguro es AWS y cómo podemos gestionar la Seguridad.

Vamos a usar un usuario federado desde un Identity Provider utilizando AWS Identity Center, que es el sucesor de AWS Single Sign-On.

Esta llamada es exactamente igual si la realizamos vía consola, vía API o desde el cli de AWS.

Primero es necesario realizar una llamada a AWS Identity Center para autentificar el usuario.
AWS Identity Center se conectará con el Identity Provider que tengamos configurado para autentificar al usuario y este solicitará las credenciales al usuario para validarlas.
El Identity Provider validará la credenciales y autentificará la petición contra AWS Identity Center que permite al usuario asumir un rol en AWS dependiendo de los permisos que tenga otorgados en Identity Center.
AWS Identity Center realizará una llamada a STS (Security Token Service) para generar una credencial temporal que devolverá en la petición inicial del usuario y que podremos reutilizar durante un corto periodo de tiempo (de 1 hora a 12 horas máximo, dependiendo de configuración).

Este primer flujo es el correspondiente a un login en la consola, un login vía cli o un AssumeRoleWithSAML vía API y solamente es necesario realizarlo una vez, es posible utilizar el token durante el periodo de validez de este.

Con este token asumimos un rol dentro de una cuenta en AWS con los permisos que tenga ese rol asignado.

Con esta credencial temporal lanzaremos la petición para crear un bucket S3 al endpoint de S3 en nuestra región.
El servicio de S3 llamará a IAM para autorizar la petición dependiendo de los permisos que tenga el rol IAM que se ha asumido con las credenciales.
IAM autorizará la petición devolviéndole esta firmada a S3.
Finalmente, S3 creará el Bucket.
S3 responderá a la petición indicando que se ha generado el bucket.

Este flujo está simplificado al máximo para explicarlo de la forma más sencilla posible (es algo más complejo).

Todas las peticiones a AWS van firmadas de forma individual con AWS Signature Version 4 (AWS SigV4) que es el proceso por el que AWS firma todas sus peticiones y que lleva en uso desde hace más de 10 años sin ningún problema conocido.

Cada petición aunque sean iguales y reiterativas tienen una firma diferente y no es posible ni siquiera realizar un ataque por fuerza bruta aunque se tuviese la potencia de computación suficiente.

Si queréis más info sobre este tema, os recomiendo la sesión de Eric Brandwine sobre este tema.

Este tipo de flujo es extremadamente seguro y vamos a tratar de explicar todas sus ventajas.

Securizando las acciones via IAM y SCPs

En primer lugar, al utilizar AWS Identity Center además de poder autentificar con un IdP propio, utilizamos AWS STS para generar tokens seguros y temporales, de forma que estos Token tienen una duración limitada y aunque alguien consiguiera robar uno (en caso de que un usuario los publicara de forma explícita por error), este token expirará automáticamente pasadas unas horas, además es posible revocar un token temporal en caso necesario.

Como otra ventaja de este modelo es que cada petición es autorizada vía IAM y requiere que la acción esté permitida de forma explícita en alguna política asociada al rol o usuario IAM y que además no esté denegada en ninguna otra política asociada.

IAM es extremadamente flexible y podemos llegar a limitar acciones muy determinadas o permitir diferentes grados de acceso con una granularidad inmensa.

Todo esto sin entrar en la potencia de las Permission Boundaries que es un feature muy potente para delegar la Administración IAM a otros usuarios, pero limitando los permisos que pueden gestionar.

Además, es posible denegar ciertas acciones de forma organizativa usando una funcionalidad de AWS Organizations llamada Service Control Policies (SCPs), que permiten bloquear acciones a nivel de cuenta de AWS, OUs (que son agrupaciones de cuentas similares a una carpeta) o toda la organización.

De esta forma, podemos limitar ciertas acciones, como por ejemplo que los usuarios creen infraestructura para que su VPC tenga acceso a Internet de forma directa. O el uso de ciertos servicios sin una configuración determinada.

Hay mil casos de uso en los cuales se pueden utilizar SCP y permiten una potencia infinita a la hora de limitar ciertas acciones, tanto en la documentacion de AWS, en aws-samples, o en la documentación de Control Tower hay multitud de ejemplos muy utilies, además de poder construir tus propias SCPs.

Auditando recursos con CloudTrail y Config

Ya hemos visto que debido al flujo de peticiones de AWS podemos bloquear ciertas acciones, pero ¿qué pasa si no podemos bloquearlas todas o queremos más control sobre ella? El siguiente paso es CloudTrail, que si no está activado en vuestras cuentas, estáis tardando en activarlo: es gratis (el primer trail en cada cuenta) y sin él no tenéis auditoría de vuestros eventos.

CloudTrail registra automáticamente todos los eventos generados en nuestra cuenta de AWS, es posible centralizarlo utilizando AWS Organization y tiene diferentes niveles de configuración, pero basicamente nos da la posibilidad de auditar todas las peticiones que se realicen en nuestra cuenta a servicios de AWS.

Aquí se suele decir que CloudTrail está muy bien, aunque no bloquea acciones indebidas, solo nos avisa. Para esto, tenemos otros servicios de AWS que se pueden combinar con CloudTrail.

Amazon EventBridge es una maravilla (anteriormente conocido como CloudWatch Events), que simplificando mucho es un bus de eventos que nos permite enlazar servicios de AWS.

Con Amazon EventBridge podemos capturar los eventos registrados en CloudTrail y generar llamadas a otros servicios como Lambda.

De esta manera, podemos generar una acción de evaluación sobre diferentes acciones en la consola e incluso derivar en acciones de remediación.

Por ejemplo, con respecto a seguridad, un gran miedo suele ser que alguien genere un Security group abriendo puertos indebidos a todo el mundo (por ejemplo, SSH y RDP). De esta forma, podemos generar un automatismo que revise cada vez que se genera o modifica una regla dentro de un Security group; si esta cumple ciertos requisitos, eliminarla y, a su vez, mandar un aviso al responsable de la cuenta indicando que se ha ejecutado esta remediación.

Para mí, esta es una de las grandes ventajas del cloud podemos evaluar un montón de acciones con este método y generar automáticamente remediaciones. Y con la ventaja de que usamos 2 servicios con un coste muy bajo, como son EventBridge y Lambda.

Si nos parece muy complejo generar estas reglas de evaluación con Lambda, ya que no disponemos de un equipo que desarrolle estas reglas, tenemos AWS Config. AWS Config es un servicio que evalúa todos nuestros recursos y los cambios de configuración de estos basándose en unas reglas que podemos configurar.

Existen multitud de reglas a implementar AWS tiene muchas reglas gestionadas para diferentes casos de uso que podéis consultar aquí y también existe un recurso muy interesante que las recopila por Conformace Packs para diferentes casos de uso.

Con base en esto, podemos evaluar si nuestros recursos cumplen nuestros estándares y es posible ejecutar acciones de remediación, para estas acciones podemos utilizar o bien Lambda o también System Manager Automation que permite la ejecución de ciertos runbook desarrollados por AWS para multitud de acciones de remediación.

Como nota importante de AWS Config, es usado por todos los CSPM (Cloud Security Posture Management) para evaluar recurso. Y, también, destacar que es un servicio que en ocasiones puede tener unos costes bastante elevados.

Inspeccionando nuestros recursos con Amazon Inspector y System Manager

Vale ya hemos visto que las acciones dentro de AWS están cubiertas, pero ¿y las instancias de EC2 y el código que ejecutan? Aquí entran otros servicios maravillosos de AWS.

El primero es Amazon Inspector que permite analizar las cargas de trabajo en AWS en busca de vulnerabilidades. Este servicio es capaz de encontrar vulnerabilidades en instancias EC2, en imágenes de contenedores almacenadas en ECR (Elastic Container Registry que es el servicio de Registry para contenedores de AWS) y, desde hace relativamente poco tiempo, en el propio código desplegado en Lambda.

Es un servicio muy útil y que como todos los servicios de AWS permite la integración con otros como Lambda y System Manager para automatizar remediaciones.

Pero además, hemos hablado un poco de System Manager que es un servicio alucinante con un montón de módulos (varios de ellos muy interesantes para seguridad).

El primero de ellos sería Patch Manager, que permite gestionar nuestro parque de instancias EC2 para mantenerlas actualizadas y aplicar los parches de forma automática. Es un servicio sencillo de usar y con una potencia infinita que permite mantener nuestras máquinas actualizadas, permitiéndonos generar ventanas para su aplicación, diferentes ventanas por tipo de entorno, SO, e incluso llegar a tener diferentes niveles de parcheo para poder probar en un pequeño número de instancias actualizaciones que puedan ser más disruptivas.
Otro servicio que se utiliza poco, pero me parece fundamental es Session Manager, que nos permite acceder a nuestras instancias utilizando nuestras credenciales IAM y sin utilizar el protocolo SSH. Esta funcionalidad es increíble, ya que permite un acceso mucho más securizado a nuestra instancias sin necesidad de exponerlas de ninguna manera. Únicamente requieren acceso al servicio de SSM (que se puede realizar de forma totalmente privada utilizando VPC Endpoints).
También existe este mismo servicio para instancias Windows sin utilizar el protocolo RDP y en este caso se llama **Fleet Manager.
Lo más impresionante de System Manager es que los 3 módulos de los que hemos hablado son **gratuitos.

Automatizando el análisis de eventos de seguridad con AWS GuardDuty

Tenemos un montón de servicios que nos dan apoyo de forma preventiva, pero ¿qué pasa si alguien consigue entrar en nuestras cuentas y empieza a hacer el mal?

Aquí tenemos uno de los servicios más importantes de AWS en seguridad. AWS GuardDuty es un servicio que utiliza la inteligencia artificial para detectar amenazas.

Esto suena muy bien, pero ¿cómo funciona realmente? Este servicio es capaz de identificar patrones de uso inadecuados dentro de AWS. Esto es sencillo porque hay que tener en cuenta que se alimenta de los datos de seguridad de todas las cuentas existentes en AWS.

AWS no es capaz de acceder a tus datos, pero sí que tiene visibilidad sobre las acciones que se realizan sobre sus servicios de forma que es bastante “sencillo” identificar patrones de uso inadecuados. Y es más, al utilizar Inteligencia Artificial y alimentarse de una cantidad ingente de datos, si en una cuenta se denuncia un uso inadecuado se puede identificar el patrón de uso y analizar si se repite en más cuentas de AWS generando avisos a los usuarios para que mitiguen el problema.

Es un servicio brutal, que detecta instantáneamente si se están produciendo eventos inadecuados.

Mucha gente no utiliza el servicio pensando que es extremadamente caro, cuando no lo es. Es más, realmente a mí me parece un servicio muy económico, teniendo en cuenta que nos puede ahorrar muchos problemas detectando usos inadecuados incluso dentro de nuestra propia organización.

Además de este servicio existe un equipo de seguridad dentro de AWS, llamado Ghostbusters, que es el último escalado para eventos de seguridad de AWS que es increíble. Os recomiendo revisar esta sesión en la que hablan sobre este equipo y cómo gestionaron un evento como Log4Shell.

Entonces ¿cómo de seguro es AWS?

Solo hemos hablado de unos pocos servicios involucrados en la seguridad dentro de AWS, pero hay muchos más: Macie (servicio para detectar datos sensible), Secret Manager (gestión de secretos), Network Firewall (solución de Firewall Perimetral), WAF (Web Application Firewall con reglas gestionadas de AWS o de Third Parties), Firewall Manager (gestión centralizada de reglas de seguridad, WAF, etc.), AWS Shield Advanced (mejora sobre la protección para ataques DDoS) y muchos más.

De esta forma, podemos tomar consciencia del nivel de seguridad que podemos alcanzar en AWS, que puede ser extremadamente alto si implementamos los servicios de seguridad que AWS provee.

Además, una de las ventajas no es solo el nivel de seguridad y aviso que podamos tener, sino la posibilidad de auto remediar que a mi modo de ver es la gran ventaja que tenemos en el mundo AWS.

La posibilidad de automatizar no solo el descubrimiento de incidentes, sino automatizar la remediación reduciendo el tiempo de respuesta al mínimo es una ventaja inmensa.
También es común pensar que nosotros requerimos un nivel de seguridad que AWS no va a ser capaz de proveer, para estos casos recomiendo revisar quién usa las Secret Regions de AWS.

Un entorno seguro tiene que ser utilizable. Esta es quizás la parte más complicada, tener un entorno seguro sin sacrificar la usabilidad es muy complejo, pero con las herramientas de AWS es más sencillo llegar a un entorno seguro y utilizable. Existen muchos entornos hiperseguros, pero que son inutilizables y esto suele provocar que se busquen alternativas poco seguras y de las que probablemente los equipos de seguridad no tengan constancia.

Con un entorno en AWS, podemos llegar a tener un entorno que sea utilizable y a la vez que podamos controlar y securizar el entorno.

Como conclusión AWS no es solamente seguro, sino que probablemente nos puede ayudar a incrementar la seguridad de nuestro propio entorno y llegar a unos niveles muy altos de seguridad, incrementando la automatización

Y tú, ¿odias o amas Kubernetes?

Miguel Angel Muñoz Sanchez — Fri, 12 Jan 2024 08:11:43 +0000

En los últimos meses, me he encontrado con bastante gente con cierta tendencia a odiar Kubernetes e intentar evitarlo a toda costa. Precisamente, no ha sido gente que apueste por modelos legacy, sino todo lo contrario: gente con un bagaje grande en modernización de aplicaciones y uso de AWS. Esto es curioso porque el estado actual de implantación de Kubernetes es cada día más alto y tiene muchísimos defensores.

Kubernetes es un gran producto, creo que nadie lo duda y tiene muchos casos de uso válidos. También existen muchas alternativas válidas a Kubernetes que pueden ser más adecuadas dependiendo del caso de uso.

Pero ¿cuáles son los problemas que veo a Kubernetes?, ¿por qué otras alternativas me gustan más? Os invito a acompañarme en esta bonita historia de odio hacia un stack tecnológico.

¿Qué es Kubernetes?
Kubernetes es un orquestador de contenedores. Sobre esta frase, que sigue estando en la página oficial de Kubernetes, he tenido un montón de discusiones y ha generado también bastantes bromas (hay quien tiene un kimono muy bonito con esa frase serigrafiada en la espalda). Por desgracia, y dando la razón al propietario del Kimono, no es un orquestador de contenedores, es muchas más cosas. Y aquí es donde quizás viene el primer problema: Kubernetes no es sencillo, nunca lo ha sido y nunca lo será.

Para explicar esto hay que irse al origen de Kubernetes. En 1979… vale, igual no hace falta irse tan atrás, pero los ancestros de contenerización de aplicaciones se remontan a esa fecha ;). En 2006, varios ingenieros de Google empezaron a desarrollar algo curioso dentro del kernel de Linux llamado “process containers”, aunque luego lo renombraron como “control groups” o como se le conoce más comúnmente “cgroups”. Esta feature es la que permitió el nacimiento de los contenedores tal y como los conocemos ahora.

De forma interna, Google empezó a usar esta funcionalidad para sus aplicaciones y, como necesitaba gestionarlas, creó Borg (el ancestro de Kubernetes) para gestionar sus propios contenedores.

Años después se liberó Docker (ya existían implementaciones de contenedores anteriores, pero ninguna tan buena y simple). Aquí surgió el primer problema, los contenedores eran una idea increíble, pero no existía una forma de gestionarlos y gobernarlos (es verdad que existían ciertas soluciones, pero no eran muy completas).

A finales de 2014 todo cambió. Google reescribió Borg con todo el conocimiento que tenía y lo liberó como Kubernetes. Kubernetes vino a solucionar todos los problemas y rápidamente se convirtió en la tecnología preferente para gestionar y gobernar contenedores. Curiosamente, 2014 fue un año prolífico: a finales de ese año se lanzaron 2 servicios de AWS basados en contenedores de los que hablaremos más adelante, como son Lambda y ECS.

Empiezan los problemas

Kubernetes era la solución más completa y más madura, realmente Google llevaba casi 10 años utilizando y manteniendo Borg cuando lanzó Kubernetes.

Como es una solución que está pensada para gestionar miles y miles de contenedores repartidos entre cientos de clusters físicos, se nota bastante a la hora de utilizarlo. No está pensado para pequeñas cargas, más bien está pensado para cargas muy grandes.

Kubernetes solucionaba muchas cosas, pero también trajo nuevos problemas, como gestionar el networking de Kubernetes, la insolación de cargas, escalado, securización, cifrado, modelo de despliegue, modelo de operación, parcheos, etc.

Un claro ejemplo de estos problemas, es el escalado de Kubernetes. Escalar y desescalar un pod (que es un grupo de uno o más contenedores) es sencillo. Pero escalar y desescalar la infraestructura donde se ejecutan los pod (nodes) es muy complejo, porque hay que generar infraestructura, los pods no tienen tamaños homogéneos, hay que distribuir las réplicas de los pods en diferentes servidores, reunificar pods en un mismo server para liberar otros y poderlos apagar, etc.

Aunque existen muchas soluciones que ayudan (como Karpenter), el esfuerzo y coste de gestionar y mantener un cluster de Kubernetes es muy alto.

Kubernetes requiere bastante expertise en la tecnología y un equipo que mantenga el stack tecnológico.

En 2014 la implantación Cloud todavía era pequeña. Por ejemplo, OpenStack estaba en su punto más alto, en ese momento el mundo IT era mucho más complejo y dependiente de la infraestructura pura. Gestionar capas y capas de complejidad era nuestro día a día.

Pero no estamos en 2014 y el mundo Cloud nos ha facilitado la vida y ha cambiado el paradigma. Ahora estamos en un momento en el que se intenta simplificar al máximo estas tareas y se tiende a empoderar a los desarrolladores para agilizar los despliegues. Por este motivo, añadir estas capas de complejidad en infraestructura es ir a contracorriente.

Aquí entran a jugar una serie de servicios Cloud más sencillos que un cluster puro de Kubernetes, pero en los que podemos ejecutar cargas contenerizadas como pueden ser Lambda, Fargate, ECS (Elastic Container Service) y EKS (Elastic Kubernetes Service).

Voy a ser sincero: ninguno, incluido EKS que es un servicio gestionado de Kubernetes, tienen la potencia de un Kubernetes puro, pero no necesitamos esa potencia.

¿Es necesario desplegar Kubernetes en todos los casos de uso?

La respuesta es no. Muchos casos de uso, por no decir la mayoría, no requieren de algo tan complejo como Kubernetes.

Lambda es un servicio serverless que permite la ejecución de código directamente, sin necesidad de provisionar infraestructura.
No podemos gestionar el contenedor propiamente, pero realmente nos genera un contenedor o contexto preconstruido que nos permite ejecutar código directamente.
Fargate (ECS o EKS) es un servicio que permite la ejecución de contenedores en modo serverless sin necesidad de preocuparte por el cluster que ejecuta la carga.

Tanto Lambda como Fargate te abstraen de toda esa complejidad, ellos se encargan de gestionarla. Simplemente, despliegas tu código o tu imagen y ya está. Algo muy sencillo, pero a la vez muy potente. Los 2 hacen uso de una tecnología open source desarrollada por Amazon muy interesante llamada Firecracker.

ECS es el orquestador de contenedores gestionado de AWS, es mucho más sencillo que Kubernetes. Es únicamente un orquestador de contenedores que está delegando el resto de tareas a otros servicios de AWS.
EKS es servicio gestionado de Kubernetes que nos abstrae del despliegue de infraestructura y se encarga de gestionar parte de nuestros clusters de Kubernetes (los master de Kubernetes), eliminando parte de la complejidad de Kubernetes pero dejándonos cierta flexibilidad

Todos estos servicios permiten desplegar aplicaciones basadas en un modelo de contenedores de forma más sencilla, abstrayéndose de la complejidad de Kubernetes. Son servicios que están más acotados y pensados para una gran variedad de casos de uso.

¿Por qué desplegar algo tan complejo como Kubernetes, si podemos utilizar herramientas más sencillas? Bueno es algo bastante complicado de explicar, pero vamos a intentar responderlo y analizarlo en el post.

Kubernetes no tiene Lock-In
**Es bastante común pensar que Kubernetes no tiene Lock-In y es una de las justificaciones más utilizadas para priorizar el uso de Kubernetes frente a otras alternativas. Pero desgraciadamente **Kubernetes tiene Vendor Lock-In.

Por un lado, un desarrollo hecho en Kubernetes, requiere ejecutarse en Kubernetes, no vas a poder ejecutarlo en otro tipo de contenerización y menos fuera del mundo de contenedores. Y eso es un Lock-In, no muy grande, porque el modelo de contenedores es bastante flexible y permite movernos de forma “sencilla”.

Pero seamos sinceros, nadie despliega Kubernetes Vainilla. Kubernetes Vainilla tiene poco Lock-In (aunque lo tiene), pero es difícil de desplegar y además requiere de más software para poder gestionar toda la complejidad asociada a Kubernetes.

Aquí entran los Vendors que nos proponen diferentes Stacks que añaden herramientas que solucionan o facilitan muchos de los problemas que hemos comentado. El problema aquí es que cada Vendor añade sus propias funcionalidades para dar valor a su Stack provocando que existan Lock-In entre diferentes Stacks. Es curioso hablar de evitar el Lock-In con Stacks que utilizan sus propias herramientas cerradas e incluso que modifican el modelo de Kubernetes.

Mucha gente piensa que migrar de un sabor a otro de Kubernetes es transparente, mientras que si vamos a un servicio Cloud va a ser muy costoso. Una vez que estamos en contenedores el esfuerzo va a ser muy similar.

Existe un artículo reciente que compara migrar un proyecto estándar a diferentes sabores de Kubernetes gestionados y adicionalmente a ECS, curiosamente el tiempo de migración y el esfuerzo de migración es exactamente el mismo.

De Lock-In hemos hablado otras veces en el blog. Es un mal necesario, y debemos gestionarlo como tal. Existe mucha tendencia a evitarlo. En parte, es culpa de un abuso de Lock-In por ciertos Vendors y, por otro lado, que en el pasado no se gestionó adecuadamente. Hay que valorar si un Lock-In como el que pueda tener Lambda, Fargate, ECS o EKS nos conviene y nos facilita la vida y además tener en cuenta cuánto nos costaría salir a otra tecnología.

Lo importante no es no tener Lock-In (porque básicamente es imposible evitarlo), sino gestionarlo correctamente.

Kubernetes es Multi-Cloud

Esta es la mayor mentira jamás contada en Cloud y la respuesta es que no. Kubernetes no es Multi-Cloud, puedes ejecutar Kubernetes en Múltiples Cloud, pero no por ello significa que en cada Cloud funcione igual.

Un ejemplo que me gusta utilizar es Terraform, ya que permite desplegar infraestructura en todas las Cloud, pero un código de Terraform que has generado para AWS, solo funcionará en AWS, no funcionará en otro Cloud.

Lo que nos da Terraform es la posibilidad de usar la misma estructura y lenguaje, pero no el mismo contenido. Lo mismo pasa con Kubernetes (aunque realmente esta potencia nos la dan los contenedores y no Kubernetes).

Un cluster de Kubernetes en AWS no funcionará igual en Azure o en Google Cloud y esto es debido a que las diferentes Cloud se parecen, pero su implementación es totalmente diferente. Solamente con ver las diferencias en el modelo de networking y el modelo de IAM (Identity and Access Management) nos podemos dar cuenta de las diferencias.

Desde hace un tiempo y gracias al genial Corey Quinn siempre recomiendo lo mismo al hablar de Multi-Cloud, antes de nada prueba a montarlo en Multi-Region dentro del mismo Cloud Provider.

Gestionar algo tan sencillo como la persistencia se empieza a complicar mucho en el momento que pasamos de una región a varias regiones. Y cada capa que vayamos añadiendo se complica cada vez más y estamos hablando de un mismo Cloud donde el modelo es igual y las APIs son compatibles, si nos vamos a otro Cloud el problema se multiplica exponencialmente.

Kubernetes = Cloud

Hay una concepción bastante grande de que si utilizamos Kubernetes, estamos utilizando Cloud. Si bien todos los Cloud Providers tienen servicios gestionados de Kubernetes, Kubernetes como tecnología no nació en el cloud y su evolución fue de forma paralela.

Es cierto que las buenas prácticas de Kubernetes se alinean mucho con las buenas prácticas tanto de Cloud, como de modernización de aplicaciones. El uso de contenedores tiene sentido en arquitecturas de microservicios.

Los contenedores no son algo nuevo, realmente el uso de contenedores o más bien de ancestros de los contenedores viene de lejos y muchos administradores de sistemas Unix hemos utilizado esos ancestros, por lo que evolucionar a Kubernetes no era algo difícil e incluso se puede ver como algo natural.

Esto en sí no es un problema, tener una estrategia en On-Prem de contenedores no es malo. El problema es que a veces se utiliza Kubernetes como parte de una evolución cloud inexistente.

Hablamos de una estrategia Cloud que se basa en el uso de Kubernetes en Cloud como si de una infraestructura OnPrem se tratase. Esto es una muy mala idea, porque realmente estamos utilizando el Cloud como un CPD anexo y el Cloud no funciona igual que un CPD.

**En Kubernetes no entra todo
**Entramos en la parte final y para mí el gran problema de Kubernetes. Al final se ha dado tanta flexibilidad a Kubernetes que se puede ejecutar cualquier carga.

Esto en principio parece bueno, pero el que se pueda ejecutar, no significa que sea lo más optimo, y menos si queremos evolucionar. Un claro ejemplo serían las BBDD en Kubernetes. Es posible ejecutar una BBDD en Kubernetes, pero no tiene sentido. Al final no estás contenerizado un microservicio, sino que estás contenerizado un servidor entero de BBDD.

¿De qué sirve un pod, que consume un servidor entero?
**
Otro ejemplo horrible son los famosos “Lift and Shift to Kubernetes”, **¿qué sentido tiene pasar de un servidor virtualizado a un pod en Kubernetes? Es posible hacerlo, pero solamente estamos generando problemas y utilizando la tecnología de contenedores para algo que no es su propósito.

El problema no es que Kubernetes pueda ejecutar estas cargas, el problema es que es un mal caso de uso, que se está generalizando demasiado. Un gran poder conlleva una gran responsabilidad y en el caso de Kubernetes este poder se está utilizando para contenerizar cargas que no debieran de ejecutarse en Kubernetes.

Conclusiones

No os voy a mentir, Kubernetes no es una mala solución, hay casos de uso en que es la solución más óptima. En Paradigma hay compañeros que están trabajando en proyectos de Kubernetes en los cuales no hay otra opción al uso de Kubernetes y se está haciendo un gran trabajo. He visto bastantes clusters de Kubernetes que están muy bien montados, muy bien operados y que son necesarios.

Realmente no odio Kubernetes, odio las malas implementaciones de Kubernetes, que por desgracia últimamente son las más habituales. Una buena tecnología que tendría que usarse para un tipo de casos de uso, se está utilizando para casos de uso erróneos. Esto es un problema, porque muchas veces estamos generando una complejidad innecesaria. Al final estas malas implementaciones están abocadas al fracaso.

Es muy habitual que empecemos por montar un cluster de Kubernetes para ejecutar nuestras futuras cargas de trabajo, sin tener en cuenta las cargas de trabajo en sí. Primero montamos el cluster y luego ya definimos las cargas. También existe la variante de directamente desarrollar en Kubernetes sin tener en cuenta si va a ser lo más optimo.

Estamos en 2023, la división entre infraestructura y desarrollo es algo del pasado, debemos de pensar en la carga que vamos a desarrollar y elegir el lugar más optimo para ejecutarla.

*Mi recomendación es ir de menos a más complejidad, carga a carga y evaluando cada salto.
*
El orden que yo propongo sería el siguiente:

Lambda
Fargate
ECS
EKS
Kubernetes EC2
Kubernetes OnPrem

Es importante en cada salto evaluar el “por qué”.

Si no puedo utilizar Lambda debo de preguntarme el motivo y si realmente está razonado. En muchos casos no se utiliza Lambda porque se requiere que el contenedor siempre esté ejecutándose.

Pero realmente ese requerimiento está razonado o simplemente es porque me resulta más cómodo o habitual un desarrollo en el que el servicio no depende de eventos y esté siempre ejecutándose. Lo mismo pasa con Fargate, que en muchas ocasiones se descarta por no permitir discos persistentes.

Aunque ECS, EKS y Kubernetes permiten montar discos persistentes en los pods no es algo recomendado, es más se debería de evitar al máximo.

Este ejercicio lo debemos hacer con todas las cargas y en todos los pasos, en muchas ocasiones se abusa de Kubernetes, porque nos permite malos usos del pasado. Pero esto no es una ventaja, es un problema.

También es importante analizar cada carga sin tener en cuenta el global. Si por ejemplo el 80% de nuestras cargas pueden funcionar en Fargate y el resto requiere de un EKS, no pasa nada, montemos un cluster pequeño para ese 20% restante y ejecutemos el 80% en lambda.

Por último, no debemos de olvidarnos de EC2, existen cargas que no tiene sentido contenerizar ahora mismo. Un monolito contenerizado, no deja de ser un monolito. Para estos casos quedarnos en EC2 e ir evolucionando nuestra aplicación a otros modelos en el futuro no es malo.

Hasta aquí este análisis de mi odio hacia Kubernetes o, más bien, de mi odio hacia su mal uso. PD: Durante el artículo hay varios vínculos a tecnologías muy interesantes como Karpenter y Firecracker, os recomiendo que le echéis un vistazo.

And you? Do you hate or Love Kubernetes?

Miguel Angel Muñoz Sanchez — Thu, 11 Jan 2024 16:36:51 +0000

This month, we will deal with a very controversial topic within the AWS world.

In the past few months, I have encountered many people who tend to hate Kubernetes and try to avoid it at all costs. It has not been precisely people who commit to legacy models but, quite the opposite, people with an extensive background in application modernization and the use of AWS.

This is interesting because the current state of implementation of Kubernetes grows bigger every day, and it has many defenders.

Kubernetes is a great product. I think no one questions this, and it has a lot of valid use cases.

Many valid alternatives to Kubernetes may be more suitable depending on the use case.

But what problems do I see with Kubernetes, and why do I like other alternatives better? I invite you to follow me in this beautiful story of hatred of a technological stack.

What Is Kubernetes?

"Kubernetes is a container orchestrator". I have had a lot of discussions about this sentence, which is still on the official page of Kubernetes. It has even generated quite a few jokes (someone has a lovely kimono with that phrase screenprinted on the back). But in short (and agreeing with the owner of the Kimono), Kubernetes is not a container orchestrator; it is many more things, and this is where perhaps the first problem arises: Kubernetes is not easy; it never was, and it never will be.

To explain this, we must go back to the origin of Kubernetes. In 1979 …, it is unnecessary to go that far back, but the ancestors of containerizing applications go back to that date. ;) In 2006, several Google engineers began to develop something curious within the Linux kernel called "process containers"—although they later renamed it "control groups" or, as it is better known, "cgroups." This feature allowed the birth of the containers as we now know them.

Google began to use this functionality internally for its applications, and as it needed to manage them, it created Borg (the ancestor of Kubernetes) to manage its containers.
Years later, Docker was released (previous container implementations already existed, but none were as good and simple).

The first problem arose here: Containers were an incredible idea, but there was no way to manage and govern them (there were indeed specific solutions, but they were not complete).

Everything changed at the end of 2014. Google rewrote Borg with all the knowledge it had gained and released it as Kubernetes. Kubernetes was here to fix all problems and quickly became the preferred technology for managing and governing containers. This is a concise summary and in broad strokes; we could write row after row about the history of containers since 1979 or something like that… 2014. It was a prolific year. At the end of the year, two container-based AWS services were launched that we will talk about later: Lambda and ECS.

The Problems Begin

Kubernetes was the most complete and mature solution. When it launched Kubernetes, Google used and maintained Borg for almost ten years.

However, it is a solution designed to manage thousands and thousands of containers distributed among hundreds of physical clusters, which is quite noticeable when using it.
It is not intended for small workloads but for massive workloads.

Kubernetes solved many things but also brought about new problems, such as managing Kubernetes networking, load isolation, scaling, securitization, encryption, deployment model, operation model, patching, etc.

A clear example of these problems is the scaling of Kubernetes. Escalating and de-escalating a pod (Which is a group of one or more containers) is easy. But escalating and de-escalating the infrastructure where the pods are running (nodes) is very complicated because you have to create the infrastructure. The pods do not have homogeneous sizes, and you have to distribute the replicas of the pods on different servers, reunify pods on the same server to empty others and be able to turn them off, etc.

Although many solutions are of help (such as Karpenter), the effort and cost of managing and maintaining a Kubernetes cluster are very high.

Kubernetes requires a lot of expertise in the technology and a team to maintain the technology stack.

In 2014, cloud implementation was still small. For example, OpenStack was at its highest point. At that time, the I.T. world was much more complex and dependent on pure infrastructure.

Managing layers and layers of complexity was our daily bread. But we are not in 2014 anymore, and the Cloud has made life easier for us and shifted the paradigm.

We live in a time when attempts are made to simplify these tasks as much as possible, and developers tend to be empowered to speed up deployments. Thus, adding these layers of infrastructure complexity is going against the grain.

Here, a series of cloud Services that are simpler than a pure Kubernetes Cluster but in which we can execute containerized loads come into play: Lambda, Fargate, ECS (Elastic Container Service), and EKS (Elastic Kubernetes Service).

I'm going to be honest: None, including EKS, a Kubernetes-managed service, have the power of pure Kubernetes, but we don't need that power.

Is It Necessary to Deploy Kubernetes in All Use Cases?

The answer is no. Many use cases do not require something as complex as Kubernetes.

Lambda is a serverless service that allows code to be run directly without providing infrastructure.
It can't manage the container itself but generates a pre-built container or context that allows us to run code directly.
Fargate (ECS or EKS) is a service that allows you to run containers in a serverless mode without worrying about the cluster running the load.

Both Lambda and Fargate remove you from all that complexity; they take care of managing it. You deploy your code or your image, and that's it—something straightforward but compelling at the same time.

Both use an exciting open-source technology developed by Amazon called Firecracker.

ECS is an AWS-managed container orchestrator. It's much simpler than Kubernetes. It is just a container orchestrator that delegates the rest of the tasks to other AWS services.
EKS is a managed Kubernetes service that abstracts us from infrastructure deployment. EKS is in charge of managing part of our Kubernetes clusters (Kubernetes Masters). It eliminates part of the complexity of Kubernetes but affords us some flexibility.

All these Services make it easier to deploy applications based on a container model by abstracting from the complexity of Kubernetes.
These services are more limited and designed for various use cases.

Why deploy something as complex as Kubernetes if we can use more straightforward tools?

Well, it isn't straightforward to explain, but there are usually reasons for this, which we will see and discuss here.

Kubernetes Does Not Have Lock-In

It is pretty standard to think that Kubernetes does not have a Lock-In, and it is one of the most used justifications for prioritizing Kubernetes over other alternatives. But, unfortunately, Kubernetes has Vendor Lock-In.

First, a Kubernetes development must be executed in Kubernetes; you will not be able to run it in another type of containerization, and even less outside the world of containers.

And that is a Lock-In. It is not very big because the container model is quite flexible and allows us to move in a "simple" way. But let's be honest: no one deploys vanilla Kubernetes.

Vanilla Kubernetes has little Lock-In (although it does), but it is challenging to deploy and requires more software to deal with all the complexity associated with Kubernetes.

The Vendors who propose different Stacks that add tools that solve or facilitate many of the problems we have mentioned come here.

The problem is that each Vendor adds its features to add value to its Stack, thereby causing a Lock-In between different Stacks. It is ironic to talk about avoiding Lock-Ins with Stacks that use their tools and even modify the Kubernetes model.

Many think migrating from one flavor of Kubernetes to another is transparent while going to a cloud service will be expensive.

Once we are working in containers, the effort will be very similar.
A recent study compares migrating a standard project to different flavors of managed Kubernetes and ECS. Interestingly, the migration time and the migration effort are precisely the same.

We have talked about Lock-In at other times on this blog.
And it's a necessary evil, so we must manage it.

There is a great tendency to avoid it, partly due to an abuse of Lock-In by certain Vendors and not having been appropriately managed in the past.

It is necessary to assess whether a Lock-In like the one that Lambda, Fargate, ECS, or EKS may have suits us and makes life easier for us and whether it considers how much it would cost us to move to another technology.

The important thing isn't having a Lock-In (because it's impossible to avoid) but managing it correctly.

Kubernetes is Multi-Cloud

This is the biggest lie ever told in Cloud computing, and the answer is no. Kubernetes is not Multi-Cloud. You can run Kubernetes on multiple clouds, but it does not mean it works the same way in each Cloud.

An example I would like to give is Terraform. Terraform allows infrastructure to be deployed in all Clouds, but a Terraform code you created for AWS will only work on AWS; it will not work on any other Cloud.

Terraform allows us to use the same structure and language—but not the same content. The same goes for Kubernetes (although, in actuality, i*t is the power given to us by the containers*, not Kubernetes).

A Kubernetes Cluster on AWS won't work the same in Azure and Google Cloud, and this is so because the different Clouds are similar, but their implementation is different. Only by looking at the differences between the networking model and the IAM (Identity and Access Management) model can we realize the differences.

For a while, and thanks to the great Corey Quinn, I have always recommended the same thing when talking about multi-cloud: First of all, try to mount it in multi-region with the same cloud provider.

Managing something as simple as persistence becomes very complicated when we move from a single region to multiple regions.

And each layer we add gets increasingly complicated—and we are talking about the same Cloud where the model is the same, and the APIs are compatible. If we move to another Cloud, the problem multiplies exponentially.

Kubernetes == Cloud

There's a pretty big assumption that if we're using Kubernetes, we're using the Cloud.

Although all Cloud Providers have managed Kubernetes services, Kubernetes as a technology was not born in the Cloud and evolved in parallel.

Indeed, Kubernetes' best practices align significantly with the excellent cloud and application modernization practices.

The use of containers makes sense in microservices architectures.

Containers are not a new thing. The use of containers, or, instead, the ancestors of containers, comes from way back, and many Unix system administrators have used those ancestors, so evolving to Kubernetes was not difficult and can even be seen as something natural.

This in itself is not a problem. Having a strategy in an On-Prem container is not bad per se. The problem is that Kubernetes is sometimes used as part of a non-existent cloud evolution.

We are discussing a cloud strategy based on using Kubernetes in the Cloud as an On-Prem infrastructure.
This is a terrible idea because we are using the Cloud as an attached CPD, which does not work the same as a CPD.

In Kubernetes, Not Everything Fits

In the end, Kubernetes has been given so much flexibility that many workloads can be run.

This seems reasonable at first, but the fact that it can be executed does not mean it is the most optimal solution, even less so if we want to evolve.

A clear example would be databases in Kubernetes.

It is possible to run a database on Kubernetes, but it just doesn't make sense. Ultimately, you are not containerizing a microservice but an entire database server.

*What good is a pod if it requires an entire server? *(You might be surprised at what you see out there.)

Another horrible example is the famous "Lift and Shift to Kubernetes." What is the point of moving from a virtualized server to a pod in Kubernetes?

It's possible, but we're just asking for trouble and using container technology for something that's not its intended purpose.

The problem is not whether Kubernetes can run these uploads. The problem is that it's a wrong use case and becoming too general.

With great power comes great responsibility, and in the case of Kubernetes, this power is being used to containerize loads that should not be running on Kubernetes.

Summary

I won't lie: Kubernetes is not a wrong solution. There are use cases where it is the most optimal solution.

Here at Paradigma, some colleagues are working on Kubernetes projects where there is no other option than using Kubernetes, and they are doing a great job.
I have seen quite a few Kubernetes Clusters that are very well set up, well operated, and necessary.

I don't hate Kubernetes; I wouldn't say I like bad Kubernetes implementations, which, unfortunately, are the most common of late.

A good technology that should be used for one type of use case is being used for the wrong use cases.

This is a problem because, a lot of times, we are creating unnecessary complexity. These bad implementations are doomed to failure.

We commonly start things by setting up a Kubernetes cluster to run our future workloads without considering them.

First, we assemble the cluster, and then we define the loads. There is also the possibility of directly developing in Kubernetes without considering if it will be the most optimal solution.

We are in 2023. The division between infrastructure and development is something of the past. We must think about the load we will generate and choose the most optimal place to execute it.

*I recommend going from less to more complexity, load by load, and evaluating each jump.
*
The order that I propose would be the following:

Lambda
Fargate
ECS
EKS
Kubernetes EC2
Kubernetes OnPrem

We are evaluating the "why" in each jump, which is essential.

If I can't use Lambda, I must ask myself why and if it is justified. In many cases, Lambda is not used because the container must be running. But is this requirement justified, or is it just because a development where the service does not depend on events and is always running is more comfortable or usual for me? The same goes for Fargate, which is often discarded for not allowing persistent disks to be mounted.

Although ECS, EKS, and Kubernetes allow persistent disks to be mounted in the pods, it is not recommended; it should be avoided as much as possible.

We must do this exercise with all the loads and steps. Often, Kubernetes is abused because it allows us to misuse it from the past. But this is not an advantage; it is a problem.

It is also essential to analyze each load without considering the global.
If, for example, 80% of our loads can work in Fargate and the rest require EKS, nothing happens. Let's then set up a small cluster for that remaining 20% and execute the other 80% in Lambda.

Last but not least, we must not forget about EC2. There are loads that it does not make sense to containerize right now. A containerized monolith is still a monolith. In these cases, staying in EC2 and evolving our application to other models in the future is not a bad idea.

This is all to discuss my hatred for Kubernetes or its misuse.
P.S.: The post includes links to exciting technologies such as Karpenter and Firecracker. I recommend that you take a look at them.