A Live Developer Journal

Five Pillars of the AWS Well-Architected Framework

The AWS Well-Architected Framework helps cloud architects build secure, high-performing, resilient and efficient infrastructure for their applications and workloads.

The five pillars are Operational Excellence, Security, Reliability, Performance Efficiency and Cost-Optimization.

Operational Excellence (automation)

Security (zero trust)

Identify and Access Management (IAM)

The IAM permission model enforces access boundaries. Every agent should only have the minimal permissions necessary to accomplish their function.

There are three fundamental components to an IAM policy:

Network Security

Amazon Virtual Private Cloud (VPC) is a core AWS network that we can define and provision resources into. Here are some of the components that make up the VPC:

To safeguard traffic in our VCPs, we can:

Resource Level Security

Individual AWS resources have configurable network security contols. The most common control is known as security group. We can use security groups to only allow traffic from specific ports and trusted resources.

Data Encryption

Data encryption is the process of encoding information in such a way that it is unintelligible to any third party that does not possess the key necessary to decypher the data. Adopting a zero trust model for data means encrypting our data everywhere, both in transit nad at rest.

Reliability (blast radius)

Performance Efficiency (cattle, not pets)

Selection

Selection is the ability to choose the service that most closely aligns with our workload. The typical workload usually requires selection across four main service categoires in AWS: Compute (service that processes data, like virtual machines), storage (static storage of data like an object store), database (organized storage of data like relational databases) and networks (how our data moves around, like a content delivery network).

Scaling

Vertical Scaling involves upgrading our underlying compute to a bigger instance type. For example, if we're running a t3.small instance, vertically scaling this instance might be upgrading it to a t3.large. Scaling vertically is simpler operationally but represents an availability risk and has lower limits.

Horizontal Scaling involves increasing the number of underlying instances. For example, if we're running a t3.small instance, horizonally scaling this instance would involve provisioning two additional t3.small instances. Scaling horizontally requires more overhead but comes with much better reliability and much higher limits.

Cost Optimization (pay as you go over one-time purchase)

Pay for use

AWS services have a pay for use model where we only pay for the capacity that we use. For common ways to optimize our cloud spend when we pay for use are:

  1. Right sizing: Picking the right instance size and family.
  2. Serverless: You only pay for what you use. When our case permits, choosing serverless can be the most cost-effective way of building our service.
  3. Reservations: Committing to paying for a certain amount of capacity in exchange for a significant discount.
  4. Spot instances: We can take advantage of unused capacity to run instances at a 90% discount, but capacity providers can reclaim the capacity at any moment.

Cost Optimization Lifecycle

The cost optimization lifecycle is the continuous process of improving our cloud spend over item. It involves a three-step workflow:

  1. Review: Before optimizing our cloud spend, we need to first understand where it's coming from. AWS Cost Explorer can help us visualize and review our cloud spend over time.
  2. Track: Once we have an overview of our overall cloud spend, we can start grouping it along dimensions that we care about (using cost allocation tags). Common tags categories: App ID, Business Unit, Resource Owner etc.
  3. Optimize: Optimize using "pay for use" techniques mentioned in the previous section.