Issue link: https://read.uberflip.com/i/1187300
Amazon Web Services – HPC Lens AWS Well-Architected Framework Page 2 Throughout this paper we make the crucial distinction between loosely coupled (or high-throughput) and tightly coupled (or high-performance) workloads. We will also cover server-based and serverless designs. Refer to the Scenarios section for a detailed discussion of these distinctions. Some vocabulary of the AWS Cloud may differ from common HPC terminology. For example, HPC users may refer to a server as a "node" while AWS refers to a virtual server as an "instance." When HPC users commonly speak of "jobs," AWS refers to them as "workloads." AWS documentation generally uses the term "vCPU" somewhat synonymously with a "thread" or a hyperthread (or, if you will, half of a physical core). Don't miss this factor of 2 when quantifying the performance or cost of an HPC application on AWS. Placement groups are an AWS method of grouping your compute instances for applications with the highest network requirements. A placement group is not a physical hardware element but simply a logical rule keeping all nodes within a low latency radius of the network. This is a crucial requirement of a tightly-coupled HPC architecture. Placement groups are not recommended for loosely coupled applications, where they would just introduce an unnecessary constraint. The AWS Cloud infrastructure is built around Regions and Availability Zones. A Region is a physical location in the world where we have multiple Availability Zones. Availability Zones consist of one or more discrete data centers, each with redundant power, networking, and connectivity, housed in separate facilities. Depending on the characteristics of your HPC workload, you may want your cluster to span Availability Zones (increasing reliability) or stay within a single Availability Zone (decreasing latency). General Design Principles In traditional computing environments, architectural decisions are often implemented as static, one-time events, sometimes with no major software or hardware upgrades during a computing system's lifetime. As a project and its context evolve, these initial decisions may hinder the system's ability to meet changing business requirements.