Is it bad practice to deploy an architecture across multiple Azure services?

No, it is not necessarily a bad practice and may in some circumstances be a good practice, although the implications need to be understood and addressed.

More and more in architecture and design today the preoccupation is separation: separation of concerns, command/query segregation, avoiding dependencies, bounded contexts. We go to great lengths to achieve separation and independence between one part and another in software systems today, and we do this at every level—architectural design, detailed design, coding—because of the benefits it brings in implementation, testing and maintenance.

We take it for granted that a microservice should be independent of other microservices, and its implementation details hidden from them. In one microservice we may leverage, say, a document database, while in another, a SQL database may be appropriate. But, other than bringing the need for the host environment to support both types of database, these implementation details are irrelevant outside the microservice. It is only a small conceptual leap from this separation in design to a separation in deployment.

That said, there are implications of doing so, which include potentially complicating the deployment process, the mechanisms for ensuring availability, and disaster recovery. The implications vary case by case; so too should the decision whether or not to incorporate such a split.