Context
Software engineering has software design patterns (e.g. GoF), which describe solutions to common coding problems - usually at the code-level; similarly there are architectural patterns (e.g. Fowler) that deal with system architecture in general (whilst these deal with considerations outside of pure code, they often seem to focus more on software engineering concerns rather than infrastructure concerns).
I've also noticed platform providers like Microsoft putting out "cloud design patterns".
Infrastructure as Code (IoC) is a further complication where software/coding-level considerations start to become relevant.
Specific Question(s)
In the realm of Infrastructure, are infrastructure-orientated patterns even a thing? If so, is there any relatively definitive collection of them that is widely understood by the infrastructure community? Or do you just 'borrow' system architecture patterns?
As an aside, assuming the answer to the above is broadly "yes", are cloud infrastructure patterns seen as a part of, or extension to, these patterns - or are they seen as a separate collection?
FYI
I'm a solution architect who comes from a software development background, not an infrastructure one. When I say "infrastructure" I'm meaning stuff like networking, physical and virtual servers and their deployment architecture, capacity and volume planning, server and network security, and so on - basically anything that a "software" architect might rely on but not explicitly architect themselves.
Update - Definitions
Just for clarity for people reading this later:
"Patterns" is a broad term, which is not discipline specific...
In software engineering a software design pattern is a specific solution (much like a recipe) to a common code-level problem. These types of pattern are usually technology agnostic, but may be specific to a programming language paradigm (e.g. Object Orientated vs an alternative).
(System / Application) Architecture Patterns, cover common system-level architecture & design problems, including: internal component structure, component-level roles and responsibilities, cross-cutting aspects such as authentication and authorization, error handling and observability, data persistence.
Too long for a simple comment:
My gut feeling is that "pattern based design" is jargon that originates from software engineering (specifically the Design Patterns book) and not something commonly used outside of that field.
With as you already mentioned more and more infrastructure becoming "software defined" that jargon is getting repeated more and more often by software engineers documenting their tooling and functionality in their own jargon and that's why we're now seeing titles like "Cloud Design Patterns" IMHO.
In the realm of network design (with a lot of jargon borrowed from the mathematics field of Graph Theory) you can find classic "design patterns", called network topologies that might already sound familiar like the hub-and-spoke or star network topology, the ring network topology , mesh networking and others that are widely deployed and instantly recognisable.
Other than that nothing immediately comes to mind, other than "form follows function".
A single monolithic application will not allow nearly as many degrees of freedom with regards to a suitable infrastructure as compared to an application or service that needs to challenge and/or operate at a global scale with the numbers of concurrent users of for example Netflix, Google, Facebook and others. Learning about how those global businesses solve their similar challenges shows very few common denominators and rather that each found their own solutions, which they often built from scratch.
Much broader than even IT infrastructure and maybe not immediately what you're asking about are the bodies of best practice, frameworks and associated jargon found in for example ITIL, ASL or TOGAF and others.
As a final thought when looking for design patterns consider the trap of cargo cults :
https://en.wikipedia.org/wiki/Cargo_cult_programming
For a given off-the-shelf software product, the vendor may provide reference implementations. If you're planning on an active directory rollout, MS has guidance for dealing with complications like remote offices with bad physical security, or slow data links. Some vendors will have scaling and performance guidelines, like splitting out a 2- or 3-tier architecture and how to scale each tier (if needed).
Unfortunately the short answer is both Yes and No.
For a longer answer, starting with the Yes part:
There are many aspects of building infra that are formulaic (as with any job really). For example, it is extremely common and expected to segregate network segments (e.g. employee PCs and on-prem servers) and filter traffic between them, because it's good security practice, and it also makes network admin somewhat easier. This is a simple example, but there exist many such "patterns", if that's what you mean. In most cases, this type of pattern is simply viewed as "the best practices", especially in matters of security.
Another type of pattern is somewhat touched upon by other answers, but not quite: Hardware vendors have reference implementations of their hardware in configurations that are supposedly optimized for best performance, mainly for demonstration purposes.
As a costumer, you may simply order this reference configuration and install it. It's not exactly mainstream because a good architect will be able to see where the hardware vendor creates additionnal margin by including top-of-the-line components where they're uneeded, so it's often much more money (but not time) efficient to design the infra in-house (again, designing according to best practices).
In a similar vein, I once did support for a client that had factories all over the world. They had designed (or contracted a design, i don't know the specifics) a "standard" infra core for each factory, with the exact same hardware specs, virtualization stack and common infra software. It made training considerably easier than on custom infras, because the part we were contracted to support was always the same.
On the flipside, apart from following the best practices, which often deal in realtively minor details or are vague enough that they wouldn't qualify as a pattern, the fact is that infrastructure is not just simply about "having servers". It's evident that a large part of infra work has to do with things that are specific to that infra.
Additionally, infrastructure has by nature a lot of tech debt (hardware is expensive and takes physical space), so it's very easy to end up in a place where the best practices of the past no longer makes sense in the present, but hey, the servers work so we're not going to replace them quite yet.