Die Bezeichnung Worker Service gibt es so nicht; was Du hast ist im Endeffekt eine Konsolenanwendung, die dauerhaft läuft.
Diese kannst Du aber in der Form nicht 1:1 in Azure hosten; jedenfalls nicht direkt (sondern dann über eine VM).
Die "Lift and Shift" Alternative ist ein Azure Web Job; hier kannst Du langlaufende Konsolen-Anwendungen starten lassen und mit bisschen Glue-Code klappt das auch mit normalen Konsolenanwendungen.
Oder aber Du packst das alles in einen Docker-Container, brauchst dann eine Web App mit Container Support und lässt das damit laufen (ab 8€).
Beide Dinge hat aber den Nachteil, dass Du Resourcen dauerhaft buchen musst, auch wenn Du sie nicht benötigst (weil zB. Deine App gerade im Idle ist, weil sie nichts tweeten muss).
Damit bezahlst Du entsprechend unnötig Zeugs und bist (im Vergleich) teurer unterwegs.
Auf einer Cloud-Plattform würde man das ganz anders programmieren, um Resourcen-schonend und damit auch extrem billig sowas laufen lassen zu können; zwei einfache Dinge.
- Du verwendest eine Azure Logic App und baust Dir Dein Twitter Bot. Es gibt hier vorgefertigte Bausteine (zB. "auf Schlagwort hören" und "Tweet absenden"). Kannst also Dein Bot zusammen stecken. Beispiel:
https://www.rubberduckdev.com/twitter-bot/
- Du verwendest eine Azure Function, die einen Trigger verwendet um auf Twitter-Wörter zu hören, sodass Dein Code nur ausgeführt wird, wenn er gebraucht wird.
Beides ist die absolut kostengünstigste Art und Weise so einen Bot umzusetzen.
Das kann sogar so günstig sein, dass es kostenlos ist, weil Du jeden Monaten hier ein Kontingent an freien Ressourcen hast (bei Functions zB. 1 Million Ausführungen pro Monat sind immer kostenlos).
In beiden Fällen erfolgt das Pricing immer nur nach den Ressourcen, die Du tatsächlich brauchst -> damit billig.