ОК, по поводу Foundation - оно же Основа, Фундамент, называйте, как хотите (далее Ф.).

Само понятие Foundation существовало задолго до появления и популяризации облачных вычислений.
Отличие в том, что помимо сетевой и серверной инфраструктуры, нужно было также проектировать и строить ЦОДы, продумывать в них вентиляцию, электричество, резервы и прочее. В публичных же облаках нужно “всего-лишь” правильно организовать структуру ресурсов, а так же политику управления оными.

Надо понимать, что фундаментом это все называется неспроста - ошибись вы в самом начале, вы рискуете заработать целый ворох проблем и технического долга, от которого вас спасет только катарсис.
Именно поэтому Ф. занимает львиную долю человеческих ресурсов и нуждается в доскональном проектировании. Дело тут даже не правильно организации VPC и сетевого стека - нужно обеспечить грамотное управление доступом, разбивку ресурсов по аккаунтам и взаимодействие между ними, а также “песочницу” для нужд разработчиков.

Если вы проектируете Ф. в облаке Амазона, советую ознакомиться с материалом Well Architected Framework (https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-Architected_Framework.pdf) - это поможет разобраться со структурой как будущей инфраструктуры, так и приложений.

Причем тут, спрашивается, Infra-as-Code? Когда вы создаете ресурсы через GUI консоль, Амазон под капотом создает разный набор ресурсов, о которых вы не знаете.
К примеру создавая ALB, вы создаете следующие ресурсы: сам балансировщик, listener, правила listener, target group’ы, объединяете их между собой.
Если создаются managed ресурсы (типа SQS, SNS) то с ними же создаются IAM роли, необходимые для их работы.

Делая все это через консоль, вы рискуете наплодить много мусора и не приобретаете понимания, как устроены сервисы в AWS’е и связи между ними.

Более того, допустим, вы создали Ф. через консоль. Руками прописали тэги, создали аккаунты и группы ресурсов для учета расходов и разграничения доступов. В момент когда вы захотите использовать IaC инструменты (например Cloudformation или Terraform), вам придется ссылаться на физические идентификаторы ресурсов.
И если в Terraform есть оператор data, который вытащит необходимые метаданные из существующих ресурсов, то в Cloudformation придется декларировать эти ссылки вручную, прописывая их в параметрах или вообще hardcoded (что приведет не очень неприятным последствиям, когда вы начнете дорабатывать Ф.).

Во избежание всего этого, имеет смысл задействовать IaC сразу на старте, применяя best practices в виде Pull Request’ов, Code Review и CI/CD с правилами Linter’а и каким-либо тестированием. Заодно идеально опишете, что именно вы создаете и как вы это связываете между собой.
Тут же вы ответите на много вопросов, таких как: держать ли управление конфигурацией на текущем инструменте (Salt, Ansible, Puppet, etc.) или делать инфраструктуру целиком иммутабельной и декларативной, зашивая все настройки в CFN/TF; разворачивать приложения через IaC или только ресурсы; и т.д.

Ну и помните, что организация, проектирование и разработка Ф. - задача в первую очередь ваша, отнеситесь к ней ответственно, и вы сохраните нервные клетки и волосы на голове.