We need to setup infrastructure for Sitecore 9 update 2 in azure PaaS. To achieve this we first need to identify which one is must/optional for costing. Have been reading all Sitecore documentations below on what role/service/database/index_cores etc required for this but I'm bit confused:

https://doc.sitecore.net/developers/scaling-guide/scaling-scenarios/scale-vertically/index.html https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/sitecore_on_azure/deploying/sitecore_configurations_and_topology_for_azure

We are not planning to use EXM or Marketing automation. Appreciate if someone could advice on what role and services needs to be setup in production. Here's what've got so far:

  1. Dedicated CD
  2. Dedicated CM with Processing and Reporting
  3. Dedicated xConnect

I'm not sure:

  1. Where these services below will reside. Sound like they can be bundled in to one dedicate instance.

    Marketting automation Reporting/Operation, Referece Data Service, Marketing Automation Engine.

  2. Whether we must install EXM/Marketing Automation databases or it's optional

  3. Do we also need Web Jobs, how do know whether it's required?

  4. Do we need message bus, how do know whether it's required?
  5. Do we need a separate database server for hosting 1. (web/master/core/reporting) 2. collection 3. Processing/Marketing

3 Answers 3


Azure PaaS on the Cheap

Your focus seems to be on reducing costs, so the first thing to make sure of is to reduce the number of app service plans being used. This doesn't necessarily mean merging together apps in Sitecore, but making sure your apps use the same app service plans. There are some examples of this in the standard topologies. Note how Small and Extra Small merge some apps into the same plan.

As mentioned previously, Azure Search can be a source of cost, so if you are willing to spin up the Solr piece yourself then that can save you some monthly dollars.

No matter what topology you end up with, remember that at some point you will want to log a support ticket so there is some value in having something that is not missing pieces.

No EXM or MA

This means you should not deploy a separate Dispatch Server instance, you can save on one instance there (though it's more like saving on not adding an instance). You can see how to disable the functionality here: Disable EXM and remove connection strings

If you are not using MA, then you probably don't want to deploy any dedicated instances specifically for Marketing Automation worker or APIs, but given the UI is in the product out-of-the-box, I would not recommend removing these components. Simply have them on shared app service plans with other elements.

Bundling XP Services

There are a lot of options for what to do with xConnect and the other new XP Services (Marketing Automation Worker, Operations API, etc.). You can physically merge them, as is done in XP Single where all of them run as a single app. Or you can run them all separately but on the same plan.

Ideally, you go with scaled but sharing an app service plan, or go with two app service plans as shown in the standard topologies to allow for xConnect collection to be scaled separately from the other apps. Going with the scaled version will give you the infrastructure flexibility you will need to isolate the apps as you start seeing different load distributions in your application.

Should you install EXM/MA databases?

Just from a support and making-life-easier standpoint, I would make sure the databases are there if you can find a cost-effective way (like elastic pools) to have all dbs. You don't want to be having an issue and then wondering if it's the strange changes you've made to the architecture that are causing it.

Web Jobs?

You definitely need the one for the Search Index worker as the index is what everything is looking at for contact data. The Marketing Automation Worker job makes sure that plans get processed. Again, since MA is in the tool by default, even if you don't plan on using it you probably want this job installed. It installs on an existing app.

Message bus?

In 9.0.2 the message bus (REBUS) is only being used by EXM, but in future versions more of the software will be using it for messaging between applications and services. You probably want this here to help with upgrades and enabling new functionality in the future, but you won't actually be putting any data in here most likely.

Separate databases?

I strongly recommend you to separate collection from everything else in production. It will chew your IO resources and you don't want anything going on in there impacting anything else in the system for a live site.


If you are not planning on using marketing automation, you might want to setup an XM environment. XM is sitecore CMS-only and doesn't include xDB. https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/experience_management/experience_management_an_overview

In this setup, you don't need those xDB services and only require a CM and CD server (which could be combined on one server as well) In XM0 (aka XMSingle), all CM and CD are combined on one instance. In XM1, CM and CD server are splitted.

Regarding your databases, I would recommend to put all your databases on the same server (as default) + setup an elastic database pool. When using an elastic pool, there is no cost involved when adding additional databases. It also improves your performance during startup. http://onelittlespark.bartverdonck.be/how-to-boost-your-sitecore-azure-paas-website-for-zero-dollars/


you can run all the services in one of the other roles - so minimum need without discussing what the performance requiresments of the site it should run is difficult. You can just move all webroles to the same app service plan for cost savings - it is the app service plan that has the real cost. Do not forget the infrastructure services (Redis cache and Azure Search). these are the expensive ones - and again might be cost saved uzing Solr and a smaller edition of Redis that what the ARM templates do ALso - move the database to a elastic pool - then the number of databases probably do not matter

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.