RE: AX Infra Sizing (AOS, DB and other servers)
Sizing an environment is a complex task for which the general guidelines are not too helpful. Knowing the transactions generated per a certain timefrime is fine and can be helpful for sizing the SQL Server. But correct sizing depends on the real-life workload. I.e. if you know that they will be doing bulk invoicing by a batch overnight, run heavy MRP tasks at the same time, and you would also export some transactions or master data to a data warehouse also outside of business hours, then you would need stronger batch AX AOS instance front. Or if the business runs in multiple shifts like at a 24/7/365 manufacturing company and those shift workers will be concurrent users of AX, then you would be sizing your user AOSes to be bigger. Same goes if you have to cover multiple timezones at the same time if we are talking about an enterprise-level implementation. If it is just one timezone with a regular work hour shift, then you would not need extra batch AOSes, you could just utilize the user AOSes for offloading some of the heavy batches from the dedicated batch server there.
Also you need to consider thing such as disaster recovery, and whether you want to have those resources on standby, or you use it as active/active nodes for both locations where users are distributed across the DR recovery location and your primary location, so if one goes down, only half of the business needs to migrate over the other location, etc. Or if you use some sort of cloud/hybrid disaster recovery solutions, that might require a different design as well. We are running 2 sites with each role to be duplicated (2x user AOS, 2x batch AOS, 2x AIF AOS, 4-node AlwaysOn SQL Cluster, etc.).
Sizing properly is all very contextual depending on the kind of business your customer has, what roles and which departments will be using the system at what times, how heavy are you going to customize Standard AX, what DR options are you considering, do you have a lot of automated tasks or data push to/from external systems, and so on.
The best advice I can give is to involve a system engineer/technical architect who is aware of all of the above which I briefly covered, look into your customers' operations in detail, then he/she should be able to give a correct advice for environment sizing.