Hi Veeam R&D team,
We understood from the tech support that the guideline at https://bp.veeam.com/vbcloud/guide/aws/ ... iance.html provided best practices as guidelines that might not fit to all cases in actual environment.
We had a client in which their environment needed higher spec than what were provided as guidelines there.
In general, good guidelines, the recommended spec should not be deviate too far from what are advertised in the sizing documentation.
If it needs 2x or 3x higher, they still can justify it.
However, the actual case we got on that particular client, is that they needed 5x to 10x more resources in which it is far from what is stated in the guidelines
This gives indication to them that the software does not work as per advertised or it may have some bug or configuration issue that makes the Veeam not working optimally.
This client had got system hang/frozen few times and from the load average we saw during the time of occurrence, we saw there were 7 subprocesses on postgres in high resource demand in which t3.medium that only has 2 vCPUs were able to handle the load average >11

The tech support (case ID: 06026284) also provided same highlight that more vCPUs are needed for the VBAws appliance.
As Veeam partner, we tried to convince this specific user about their resource demand with the case update info, however, we'd like the guideline at https://bp.veeam.com/vbcloud/guide/aws/ ... iance.html to be updated with more detailed calculation on the vCPUs and some disclaimer to prevent doubt from our users who may not have chance to read the ticket case 06026284 from us.
This is because any users can use google to find the page https://bp.veeam.com/vbcloud/guide/aws/ ... iance.html and that info had misled some of them to think that the VBA t3.medium could handle workload up to 1000, while our finding on this client environment, they have 200+ workloads and the system is indicating to require 12 vCPUs during the failure.
- Number of policies: 15
- Total workload: 209
- t3.medium = 2 vCPUs, 4 GB RAM (general recommendation based on the "Advised number of workloads" on the sizing page)
- t3.large = 2 vCPUs, 8 GB RAM (general calculation based on sizing page: (200 * 15) + (3 * 209) = 3627 = ~3.7 GiB)
- c5.2xlarge = 8 vCPUs, 16 GB RAM (actual compute demand we found during the system/backup failure that showed high load average >11)
In further troubleshooting, we saw the postgresql log (/var/lib/postgresql/12/main/log) had been generating error "Broken pipe" in every seconds or minutes regardless the backup activities were busy or idling.

Would you also please help to advice/check if those "Broken pipe" errors are also seen on your side and if those errors are caused by lack of vCPUs or due to some configuration issues?
Thank you.