Сервис работает на двадцати инстансах. Добавление ещё десяти не уменьшает время ответа. Как вы будете искать причину и что предпримете?

Начинать нужно с измерения, а не с гипотез: по трассировке видно, где проведено время — в процессоре приложения, в ожидании базы, во внешних вызовах или в очереди на получение соединения из пула. Если время уходит на ожидание, добавление инстансов бесполезно по определению. Дальше ищем разделяемое ограничение: полностью занятый пул соединений при низкой загрузке процессора, единственный лидер записи, глобальная блокировка или строка-счётчик, которую обновляют все, квота внешнего API. Полезно назвать и общий принцип: последовательная часть работы задаёт потолок ускорения, а координация между узлами способна дать отрицательную отдачу — тридцать инстансов открывают в полтора раза больше соединений и могут ухудшить положение базы. Дальше действуем по найденной причине: убрать запросы в цикле и добавить индексы, включить пакетную обработку, поставить кэш, развести чтения по репликам, при упоре в запись — шардировать, а число соединений ограничить пулером. И обязательно назвать метрику, по которой станет видно, что помогло: задержка на девяносто девятом перцентиле и насыщение пулов, а не средняя загрузка процессора.