A production system has to meet precise goals: performance, reliability, security and compliance, traceability, manageability, flexibility and cost. Meeting them takes work on two levels, before you even reach the application's features.
The solution architect defines the architecture of the services: which cloud services to use and how to connect them to meet those goals. Microsoft describes the role as advising stakeholders and translating business requirements into technical designs, working with developers, administrators, and security and data specialists.
The software architect defines the common software rules that make those choices work: how each component writes logs and uses the monitoring tools, how it uses the services, how it handles errors and configuration.
Neither level is enough without the other. Monitoring has to be planned in the architecture, but useful data only arrives if development follows precise rules too. With restricted access to production this is obvious: when something goes wrong, you can rely only on what was planned beforehand.
Cloud experience →
For both roles, these services and rules almost always need assessing: they form a foundation, almost a framework in its own right, for a project that makes use of the cloud environment, can grow and can be monitored.
Once that is done, you move into the individual project and work out what it really needs. The software architect chooses which architecture to develop, for example whether to use Clean Architecture, and defines the development rules; together, the team chooses the services and cloud patterns that suit the case. Depending on the situation, you start with a prototype (proof of concept) that checks these rules are being met, then move on to development proper.
How I organise code →
The project's needs can also change the foundation: regulated data or high volumes may call for different services.
These are not standard titles. Large organisations add the enterprise architect, who works on the systems as a whole and on technology strategy rather than on a single project.
The role did not begin with the cloud, but today the two subjects almost always meet. In the cloud, infrastructure is not a one-off purchase: you choose from many services, describe them in versioned files and pay every month. An architecture decision also becomes a decision about cost, risk and dependence on a supplier.