Teradata moved towards the cloud in order not to lose the connection to modern cloud databases.
How the essential things like security, backups, sizing are solved I show you with the AWS Cloud solution from Teradata.
The basic architecture is the same.
The database software is unchanged. Teradata has been adapted to the infrastructure of AWS.
On an on-premises Teradata, all services are executed on hardware servers. In the AWS cloud, each node runs on a computing instance (a virtual server).
This means certain limitations (BYNET is not running on Infiniband in AWS), but also new features that were not available before.
While an on-premise Teradata system is optimized for IO throughput, this is not the case in the AWS Cloud.
The nodes are provided by EC2 instances. Data is stored in Elastic Block Stores (EBS).
Teradata uses only SSD in the cloud to optimize IO throughput (in principle, hard disks would also be provided).
Fallback Protection is activated if at least two nodes exist.
The EBS is automatically replicated within the availability zone. This is equivalent to mirroring data (Raid 1).
Backups can be created on the S3 file system.
The data on an EBS is also stored encrypted.
Compute nodes (EC2 instances) can be exchanged (upscaling) or Instances can be added (out scaling).
Adding storage space is associated with the usual problems of a shared noting system. This is one of the reasons why Teradata has introduced the MAPS architecture.
The MAPS architecture makes it no longer necessary to redistribute data as soon as storage space is increased, but that this process can be delayed.
Nevertheless, Teradata can by no means keep up with the elasticity of modern cloud data banks like Snowflake which scales immediately.
These are available, but no longer absolutely necessary in AWS.
Since instances can be booted at any time, there is the so-called Node Failure Recovery Feature. A computing instance is started as soon as a node crashes and the Elastic Block storage from the failed node is coupled to the new node.