AWS Architecture

AWS Account

Each AWS account has below three main functions:

  • Authentication: Each account has a root user and serves as the identity to authenticate against that account. If account credentials are leaked, the impact (blast radius) is limited to that account.
  • Authorization is controlled on a per-account basis. The root user starts with full control of the account and its resources. Additional identities can be created or external identities can be granted access. Unless defined otherwise, no identity except the account root user has access to resources.
  • Billing: Each AWS account has its own isolated billing information. This is initially in the form of an attached credit card, but established accounts can be converted to use traditional, term-based invoicing. By default, we are only billed for resources in our account. Billing or security exploits are limited to a single account.

Accounts can be linked and configured to allow consolidated billing where a master account is charged for all member account resource usage.

AWS Global Infrastructure

Regions contain multiple Availability Zones (AZs), which are separated and isolated networks. A failure in one AZ generally won't impact another.

AZs in the same region are connected with redundant, high-speed, low-latency network connections. Most AWS services run within AZs. Some services operate from AZ, while others replicate between AZs. Some services allow us to choose the AZ to use and some don't.

Edge locations (Points of Presence - POPs) are small pockets of AWS compute, storage, and networking close to major populations and are generally used for edge computing and content delivery.

Well-Architected Framework

Pillars of Well-Architected Framework


Includes the ability to protect information, systems and assets while delivering business value through risk assessments and mitigation strategies. Design Principles:

    • Implement a strong identity foundation
    • Enable traceability
    • Apply security at all layers
    • Automate security best practices
    • Protect data in transit and at rest
    • Prepare for security events


Includes the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions, such as misconfigurations or transient network issues.

Design Principles:

  • Testing recovery procedures
  • Automatically recover from failure
  • Scale horizontally to increase aggregate system availability
  • Stop guessing capacity
  • Manage change in automation

Performance Efficiency

Includes the ability to use computing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve.

Design Principles:

  • Democratize advanced technologies
  • Go global in minutes
  • User serverless architectures
  • Experiment more often
  • Mechanical sympathy

Operational Excellence

Includes the ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures

Design Principles:

  • Perform operations as code
  • Annotate documentation
  • Make frequent, small, reversible changes
  • Refine operations procedures frequently
  • Anticipate failure
  • Learn from all operational failures

Cost Optimization

Includes the ability to avoid or eliminate unneeded cost or sub-optimal resources.

Design Principles:

  • Adopt a consumption model
  • Measure overall efficiency
  • Stop spending money on data center operations
  • Analyze and attribute expenditure
  • Use managed services to reduce cost of ownership

Scaling in AWS

  • Vertical
  • Horizontal
  • Elastic

Vertical scaling is where an attempt is made to forecast demand and purchase servers ideally before the demand passes current capacity. Purchase too early and capacity is wasted. Purchase too late and performance is impacted.

Horizontal scaling is where more, smaller servers are used and capacity can be maintained closer to demand. There is less waste because servers are smaller and there is less risk of performance impact as each increase is less expensive. So it generally requires less approval. Still this will not cater for peak season or peak hour spike loads and will cause dissatisfied customer and revenue losses.

Elasticity or elastic scaling is where automation and horizontal scaling are used in conjunction to match capacity with demand. Demand is rarely so linear - it can increase or decrease, often in a rapid and sudden way. An efficient platform should scale OUT and IN, matching demands on that system. Elasticity is a best tool to achieve Performance Efficiency and Cost Optimization.

Next: AWS Product Fundamentals