The database plays technically the same role as your cloud system, even if it's local on your server. So you could represent it with an actor (if really you have to choose something).
As the database is external to your system, you'd need of course to have some boundary object(s) (e.g. gateways) to allow the other objects to interact with it.
The Entity-Control-Boundary approach is closely related to use case modeling:
- The idea of their inventor, Ivar Jacobson, was to derive in a systematic manner the classes required in a system to implement the identified use cases.
- The philosophy is therefore that boundary classes represent the link between actors and use cases, that control classes are mapped to some use cases, and that entity classes represent the domain objects.
In a use case model, actors are humans or external system that interact with the system for the purpose of achieving a use case (i.e. an intent of an actor or a business requirement). For this reasons, databases are usually not part of the use case diagrams.
Databases appear if you dig below the use-case surface.
The database should not itself be an entity, nor a control, nor a boundary. Even if from a use-case point of view the database could be understood as part of the system under consideration (because it's not an external system involved in the business interactions), technically, it remains an independent component, external to the system that you are developing.
<<Entity>> stereotype is common enough that it was standardized in UML, totally in line with the ECB understanding:
<<Entity>>: A persistent information component representing a business
Clearly, your database is not an entity according to this understanding. Even if you would develop your own database from scratch as part of the system.
<<Control>> are non standard stereotypes. But if you need to access the external database, you'd need a boundary object acting as connector/gateway.
If you would develop a database from the scratch, as part of your system, then the database itself would be composed of a lot of
<<Control>> objects that would manage the flow of information and interactions in relation with the other controls, entities and boundaries (in particular the stream objects that would represent the boundary to the file system).