Before you start#

Three things make the rest of the book easier: the shape of AWS on one page, how to read its figures, and a first sign-in that tells you exactly who and where you are.

The cloud on one page#

On its first day, MegaCorp's payments team asks what every newcomer asks: where does everything actually live? Almost always, the answer has two parts: an account and a Region.

An AWS account holds resources and is their security boundary. Nothing in one account can reach another unless someone explicitly allows it, and costs are counted per account. A Region is a geographic area, such as London, eu-west-2, made of several Availability Zones. What you create in one Region does not exist in any other unless you copy or replicate it.

A few services are global rather than Regional. IAM, which decides who may do what, and Route 53, which answers DNS queries, serve every Region, although each is managed from one Region, us-east-1.

Read more What is an AWS account? · AWS Fault Isolation Boundaries: Regions · AWS Fault Isolation Boundaries: Availability Zones · AWS Fault Isolation Boundaries: global services

How to read the figures#

Most figures in this book are architecture diagrams drawn the way AWS draws them, with the official icons. Boxes are groups: whatever sits inside a box belongs to it. The colour and line of a box say what kind of group it is.

Numbered black circles mark the steps of a flow, and the legend under the figure explains them in order. In the next figure, a customer's request arrives at a load balancer (step 1), which passes it to an instance in a private subnet (step 2).

Where Azure helps, a figure pair shows Azure on the left and AWS on the right. Every figure also has an "As text" version beneath it, which a screen reader can read and the search can find.

Read more AWS Architecture Icons · Azure architecture icons

A first sign-in#

Alex joins the payments team as a developer. MegaCorp signs its people in to AWS through IAM Identity Center, so Alex never holds a long-term password or access key for AWS. Instead, the AWS CLI asks Identity Center for short-term credentials for a role: an identity, with its own permissions, that Alex can assume for a limited time.

aws configure sso
aws sso login --profile payments-dev
aws sts get-caller-identity --profile payments-dev

aws configure sso runs once. It asks for MegaCorp's Identity Center start URL and Region, opens a browser to sign in, lists the accounts and roles Alex may use, and saves the choice as a profile. Later, aws sso login signs in again when the session has expired.

{
    "UserId": "AIDASAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevAdmin"
}

The documentation's example comes from an IAM user. Signed in through Identity Center, Alex's Arn names an assumed role instead, one that Identity Center created: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_PowerUserAccess_…/alex. Account says which account the command reached; check it before changing anything. The profile also stores a default Region. Commands go to that Region, and resources in any other Region do not appear in their results.

Read more Installing or updating the AWS CLI · Configuring IAM Identity Center authentication with the AWS CLI · AWS CLI: aws sts get-caller-identity

AWS on one page#

AWS is a long list of separate services, but they fall into a handful of categories, and each category has its own icon colour. Learn them, and a figure tells you what each box does before you read the label.

A handful of categories#

When MegaCorp's payments team first opens the AWS console, the list of services is long enough to discourage anyone. It becomes manageable once the team sees that every service belongs to one category, and that a design needs only a few services from each.

Every AWS service icon sits on a square tile in its category's colour. The first figure shows where workloads run and where data lives; the second shows how the parts connect, and how they are kept safe and visible.

The table lists every category this book teaches, with the services it covers and where. Each service is its own product, with its own API, console pages, quotas and pricing; chapter 4 explains why that matters.

Read more Overview of Amazon Web Services · AWS Architecture Icons

Colours in a design#

Once the colours are familiar, a design reads at a glance. A customer's request to MegaCorp enters through CloudFront (step 1), purple because it moves traffic, and passes a load balancer (step 2). It reaches the orange compute that runs the payments code (step 3) and ends at a magenta database (step 4).

Read more AWS Architecture Icons

How AWS got here#

AWS began in 2006 as a handful of separate services and grew one service at a time; Azure followed from 2008. That history explains why AWS feels like many products, and why older accounts look different from new ones.

Two clouds, two decades#

AWS launched in the spring of 2006 with Amazon S3, a service for storing objects, and added Amazon EC2, for renting servers, a few months later. Each was its own product with its own API. That pattern held: AWS grew by adding separate services, each launched when it was ready.

The strip below follows one thread through that history: how much of the machine you run yourself. Each step hands more of it to AWS, and each is still on sale, so designs choose among them.

Read more Overview of Amazon Web Services · Amazon VPC User Guide: document history

Eras you will meet#

History matters because accounts keep what they were given. The payments team inherits an AWS account from a company MegaCorp bought, and its age shows in three places.

• No default VPC. Accounts created after 4 December 2013 got a default VPC in every Region. An older account may have none, and its first instances ran in EC2-Classic, a flat network AWS has since retired.
• NAT instances. Before NAT gateways arrived in December 2015, private subnets reached the internet through NAT instances: ordinary instances the team had to run, patch and scale itself.
• No servers. From 2014, AWS Lambda, and later AWS Fargate, ran code and containers with no servers to manage. Newer parts of an estate lean on them.

Read more Default VPCs · NAT instances

Why AWS feels like many products#

Because each service launched on its own, each still has its own API, console pages, quotas, pricing and documentation. Services overlap: there are several ways to run a container or send a message, each from a different year and for a different need. Old features retire slowly; EC2-Classic took from 2021 to 2023 to go. chapter 44 dates what an estate contains.

Read more EC2-Classic is retiring: here's how to prepare

Six shifts in thinking#

Six ideas change how you design on AWS: accounts as boundaries, roles as identities, policies evaluated together, subnets tied to zones, services as separate products, and moving data as a cost. Each gets a chapter later; here is the map.

1. The account is the boundary#

MegaCorp gives payments three AWS accounts: development, test and production. An account holds resources, and it is also the boundary for security, cost and quotas. Nothing crosses it unless someone allows it, costs are counted per account, and quotas apply per account and Region. Many small accounts, grouped with AWS Organizations, take the place of a few large ones. chapter 7 develops this.

Read more What is an AWS account? · Terminology and concepts for AWS Organizations · Azure management groups

2. A role is an identity you assume#

Alex, from chapter 1, has no AWS password at all. Alex assumes a role, an identity with its own permissions, and receives credentials that last hours, not years. Code does the same: an instance or a Lambda function assumes a role, so no key sits in a configuration file. chapter 8 develops this.

Read more IAM roles

3. Policies are evaluated together#

Every request starts denied. It succeeds only if some policy allows it and no policy denies it: an explicit deny anywhere, in the caller's policies, the resource's policy or an organization's guardrail, always wins. A request from one account to another must be allowed on both sides. chapter 9 develops this.

Read more Policy evaluation logic

4. A subnet lives in one zone#

A subnet sits in exactly one Availability Zone, and nothing on it says public or private: its route table decides. Resilience is therefore a matter of subnet layout, with one subnet per zone for each tier. chapter 12 develops this.

Read more Subnets for your VPC

5. Every service is its own product#

Each AWS service has its own API, console pages, quotas and pricing, and nothing makes two services name or tag things alike. Tags are optional and case sensitive, so Env and env are two different keys. A naming and tagging scheme is the designer's job, decided early. chapter 31 develops this.

Read more Tagging your AWS resources · Service Quotas documentation

6. Moving data costs money#

Data moving between zones is billed as it leaves and again as it arrives. Data through a NAT gateway is billed per gigabyte processed, and data leaving AWS for the internet is billed too, while data arriving from the internet is free. The figure marks the billed paths of one payments service. chapter 31 develops this.

Read more Understanding data transfer charges · Amazon VPC pricing

False friends#

Azure and AWS use some of the same words for different things. Six cause most of the confusion in design reviews: role, policy, security group, resource group, gateway and endpoint.

Identity words#

In the payments team's first design review, an architect who knows Azure asks who holds "the Contributor role" on the payments account. On AWS the question has no answer, because the word means something else.

Read more IAM roles · Policy evaluation logic · Evaluating resources with AWS Config rules · What is Azure role-based access control? · Overview of Azure Policy

Network words#

Three network words trip people up next.

Read more Security groups · Azure network security groups · What is Azure Application Gateway? · AWS service endpoints

Organising words#

The last false friend matters most for estate design. On Azure the team would keep the payments resources in one resource group and delete them together. AWS has resource groups too, but they hold nothing.

Read more What are resource groups? · What is Azure Resource Manager?

Your first week#

Joining an AWS estate, you need four answers fast: who and where you are, what you may do, what is already there, and who changed what. Each takes one command, and AWS's refusals are more helpful than they look.

Who and where you are#

Alex's first real task is the account MegaCorp inherited when it bought a smaller payments company. Before touching anything, Alex confirms the account and Region the profile reaches, and whether the account belongs to MegaCorp's organization.

aws sts get-caller-identity --profile acquired
aws organizations describe-organization --profile acquired
aws ec2 describe-vpcs --profile acquired --query "Vpcs[].{id:VpcId,cidr:CidrBlock,default:IsDefault}"

The commands name the account and role, the organization and its management account, and the VPCs in the profile's Region, flagging any default VPC.

Read more AWS CLI: aws sts get-caller-identity · Terminology and concepts for AWS Organizations · Default VPCs

What you may do#

Nobody hands Alex a list of permissions. Alex tries the task and reads the refusal: most access denied messages name the missing action and the kind of policy that refused it.

User: arn:aws:iam::123456789012:role/HR is not authorized to perform: codecommit:ListRepositories
because no identity-based policy allows the codecommit:ListRepositories action

Read more Troubleshoot access denied error messages

What is already there#

For an inventory, AWS Resource Explorer, on by default since October 2025, searches the current Region by name, tag or ID, at no charge.

aws resource-explorer-2 search --profile acquired --query-string "tag:app=payments"

Read more What is AWS Resource Explorer?

Who changed what#

On Wednesday the settlement job stops reaching its database. Someone changed a security group on Tuesday, and CloudTrail knows who. Its event history keeps 90 days of management calls in each Region, free and with no trail needed.

aws cloudtrail lookup-events --profile acquired --region eu-west-2 \
    --lookup-attributes AttributeKey=ResourceName,AttributeValue=sg-0123456789abcdef0

Read more Working with CloudTrail event history

The same questions on each cloud#

Read more AWS CLI Command Reference

Accounts and Organizations#

On AWS the account is the boundary for security, cost and quotas, so an enterprise runs many small accounts. AWS Organizations groups them, pays for them together and caps what anyone in them may do.

The account is the unit#

MegaCorp's platform team starts with a question that shapes everything else: how many AWS accounts? The answer is more than anyone expects. Each workload gets an account per environment, and shared jobs such as logging and security get accounts of their own.

An organization of accounts#

Twenty accounts need somewhere to live. MegaCorp creates an organization, keeps its management account empty, and groups the others by how they are governed: security accounts in one organizational unit, workloads in another, experiments in a third.

Guardrails with service control policies#

Guardrails are where Organizations earns its place. The platform team attaches a policy to the Workloads OU that denies every Region except eu-west-1 and eu-west-2. A developer with full administrator rights in payments-dev still cannot start an instance in us-east-1, because every policy from the root down must allow an action, and none may deny it.

Read more Service control policies (SCPs) · Creating a member account in an organization

MegaCorp's accounts#

The payments-prod account, in the Workloads OU, becomes the outer boundary of MegaCorp's running design. Every later chapter adds something inside it.

Read more What is an AWS account?

IAM identities and roles#

Every request to AWS is signed by an identity, and the identities that matter are roles: people and code assume them and receive credentials that expire. A long-term key becomes the exception you have to justify.

Who is calling#

MegaCorp's settlement job has to write statements to Amazon S3. On a first attempt, a developer pastes an access key into the job's configuration. The platform team rejects the change: on AWS, code gets its access from a role, and a key in a file can leak and never expires.

Roles for code#

The settlement job gets a role called settlement. Its trust policy lets the compute service assume it, and its permissions policy allows one action on one bucket. The code carries no key: the AWS SDK finds the role's credentials, and they renew before they expire.

Read more Use an IAM role for applications on Amazon EC2 · IAM roles

Crossing accounts#

The settlement job must also copy each statement into the log-archive account, which it cannot reach by default. Log-archive creates a role that trusts the settlement role: the job assumes it (step 1) and writes with the new credentials (step 2).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:role/settlement" },
    "Action": "sts:AssumeRole"
  }]
}

That is statement-writer's trust policy. The settlement role also needs permission of its own to call sts:AssumeRole on statement-writer: one account trusts, and the other allows.

Read more Cross-account policy evaluation logic

IAM policies#

Permissions on AWS come from policies: JSON documents attached to identities, resources and whole accounts. Several kinds are evaluated together on every request, and knowing their order is how you design access and fix a refusal.

Nine kinds of policy#

The settlement role from chapter 8 needs one permission: to write objects to the statements bucket. The platform team writes it as an identity-based policy, the commonest kind, attached to the role.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::megacorp-statements/*"
  }]
}

That is one of nine kinds of policy AWS evaluates. Most are JSON with the same shape: an effect, actions, resources and optional conditions. The kinds an architect meets most often:

Prefer customer managed policies, which many roles can share and the team controls. AWS managed policies are quick to start with, but AWS changes them as services grow, and they rarely match least privilege.

Read more Policies and permissions in IAM · Managed policies and inline policies

How AWS decides#

When the settlement job calls PutObject, AWS gathers every policy that applies and starts from a refusal. Within one account, the request succeeds only if nothing denies it, the guardrails allow it, and the role's policy or the bucket's policy allows it.

Across accounts, as when the job writes to log-archive, AWS evaluates the request in both accounts, and each must allow it on its own.

Read more Policy evaluation logic · Cross-account policy evaluation logic

Tags as permissions#

MegaCorp soon has queues for payments, ledger and fraud, each with a developer role. Writing a policy per team per queue does not scale. Instead the team tags every role and resource with team, and one policy allows an action whenever the resource's team tag matches the caller's. This is attribute-based access control.

A new queue tagged team=payments is reachable at once, with no policy change, which is the point: permissions scale as resources are added. The risk moves to the tags, so who may set them must itself be controlled.

Read more Define permissions based on attributes with ABAC

Delegating safely#

Developers in payments-dev want to create roles for their own Lambda functions without waiting for the platform team. A permissions boundary makes that safe: developers may create roles only if they attach the developer-boundary policy, so no role they create can do more than that boundary allows, whatever its own policy says.

Read more Permissions boundaries for IAM entities

Checking policies#

Policies drift: a bucket gets shared for one migration and stays shared. MegaCorp turns on an analyzer for the whole organization before the first workload goes live.

Identity for people and code#

Three kinds of caller sign in to MegaCorp's systems: its people, its pipelines and its customers. Each has its own door: IAM Identity Center, OpenID Connect federation and Amazon Cognito.

People: one sign-in for every account#

Alex's first day on the payments team starts with a login MegaCorp already has: a Microsoft Entra ID account, used for email. Nobody creates an IAM user for Alex in each account. The platform team connected Entra ID to IAM Identity Center once, and Alex's group membership does the rest.

In 2013 IAM learned to trust a corporate identity provider over SAML, but account by account. From 2017, AWS Single Sign-On did it once for the whole organization. Renamed IAM Identity Center in 2022, it is why the CLI still says aws sso login.

Pipelines: nothing to steal#

MegaCorp deploys the payments service from GitHub Actions. The first pipeline kept an access key in a repository secret, which works until the key leaks. Now each run gets a signed OpenID Connect token from GitHub and trades it with AWS STS for credentials that expire.

The account registers GitHub as an identity provider once. The deploy role's trust policy then accepts only runs on the payments repository's main branch.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:megacorp/payments:ref:refs/heads/main"
      }
    }
  }]
}

Read more Create a role for OpenID Connect federation

Customers: a directory of their own#

Next comes a merchant portal where shops download their settlement statements. Merchants are not staff, so they belong in neither Entra ID nor IAM, but in a directory of their own.

MegaCorp's design gains its identity layer: merchants sign in through a user pool in eu-west-2, and the pipeline deploys through the deploy role.

Regions and zones#

Every resource lives somewhere: in one zone, one Region, or everywhere. Which of the three decides what a failure takes down, where data may sit, and why a Region in Virginia matters to all.

Choosing a Region#

MegaCorp's merchant data must stay in the UK, so the payments team builds in eu-west-2, London, after checking the Regional Services List for every service the design needs. Resources and data stay in their Region unless you copy them, and the console shows one Region at a time.

Regions launched after 20 March 2019, such as Europe (Spain), are opt-in: nobody can use one until it is enabled, and enabling copies the account's IAM data there, which can take hours.

Read more Enable or disable AWS Regions in your account · AWS Regional Services List

Zone names differ between accounts#

The settlement job in payments-prod reads the ledger database in another account. Both teams chose eu-west-2a to keep traffic in one zone, yet the bill shows traffic between zones: AWS maps zone names to physical zones at random for each account.

A zone ID, such as euw2-az1, names the same physical zone in every account. When accounts must agree on a zone, plan and automate with zone IDs.

Read more Availability Zone IDs for your AWS resources · What are Azure availability zones?

Global services, and us-east-1#

IAM, AWS Organizations, Amazon Route 53 and Amazon CloudFront are global: they answer everywhere, but their control planes sit in us-east-1, in northern Virginia.

So keep changes to global services out of recovery plans, as chapter 8 said of IAM, and manage CloudFront certificates in us-east-1.

Read more AWS Fault Isolation Boundaries: global services

Closer than a Region#

Read more Regions and Zones · How AWS Local Zones work

VPC fundamentals#

A VPC is your private network in one AWS Region. Three decisions shape every VPC: how to divide its addresses, which zone each subnet lives in, and how traffic leaves for the internet and for AWS services.

A network in one Region#

MegaCorp's payments team is moving its platform to AWS, into the London Region, eu-west-2. First it needs a network to put the platform in. MegaCorp's address plan, drawn up for the whole estate so that no two networks overlap, gives payments the range 10.20.0.0/16.

A subnet lives in one zone#

Next come the subnets, and the first rule that shapes every AWS network: a subnet sits in exactly one Availability Zone and cannot span zones. To survive the loss of a zone, the team creates matching subnets in two zones and spreads each tier across them.

Read more Subnets for your VPC · Azure Virtual Network FAQ

Routing makes a subnet public or private#

The team wants public subnets for the load balancer and the NAT gateways, and private ones for everything else. Nothing on a subnet says "public", though: a public subnet is one whose route table has a direct route to an internet gateway.

Read more Configure route tables · Internet gateways

Getting out: NAT gateways#

The settlement job is the first to need the internet. The figure shows the team's layout.

Reaching Amazon S3 without the internet#

The ledger service has a different need. It never talks to the internet, only to Amazon S3, where it writes the day's statements every night.

Security groups and network ACLs#

Two firewalls filter traffic inside a VPC. Security groups are the primary control; network ACLs add a coarse, stateless layer across a whole subnet.

The same subnets in Terraform#

One Terraform comparison shows the zone rule in code. Every aws_subnet names its Availability Zone, so resilient AWS subnets come in sets; an azurerm_subnet has no zone to name.

resource "azurerm_subnet" "gateway" {
  name                 = "snet-gateway"
  resource_group_name  = azurerm_resource_group.payments.name
  virtual_network_name = azurerm_virtual_network.payments.name
  address_prefixes     = ["10.20.0.0/24"]
}

resource "azurerm_subnet" "app" {
  name                            = "snet-app"
  resource_group_name             = azurerm_resource_group.payments.name
  virtual_network_name            = azurerm_virtual_network.payments.name
  address_prefixes                = ["10.20.10.0/24"]
  default_outbound_access_enabled = false
}

data "aws_availability_zones" "available" {
  state = "available"
}

# 10.20.0.0/24 and 10.20.1.0/24: one public subnet in each of two zones
resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.payments.id
  cidr_block        = cidrsubnet(aws_vpc.payments.cidr_block, 8, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = { Name = "payments-public-${count.index}" }
}

# 10.20.10.0/24 and 10.20.11.0/24: one private subnet in each of the same zones
resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.payments.id
  cidr_block        = cidrsubnet(aws_vpc.payments.cidr_block, 8, count.index + 10)
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = { Name = "payments-private-${count.index}" }
}

Read more Terraform: aws_subnet · Terraform: azurerm_subnet · Default outbound access in Azure

How the VPC got here#

Amazon VPC began in 2009 as a VPN bridge to company networks. The flat network that came before it, EC2-Classic, shared with other customers, is now retired.

Read more Amazon VPC User Guide: document history · EC2-Classic is retiring: here's how to prepare

MegaCorp's network#

The figure adds the payments network to MegaCorp's running design.

Read more What is IPAM?

Connecting networks#

MegaCorp's VPCs multiply with its accounts. Each must reach a few others, the data centre and shared services, but never everything.

Two VPCs: peering#

The settlement job in payments-prod must reach the ledger database in another account. A peering connection joins the two VPCs once both owners agree and add routes. Ranges must not overlap, and peering is not transitive: ledger cannot reach a third VPC through it, nor use payments-prod's NAT gateway or VPN.

Read more How VPC peering connections work · Azure virtual network peering

Many VPCs: a transit gateway#

With fourteen VPCs, every pair would need 91 peering connections. The network team builds one transit gateway in the network account, shares it through AWS RAM, and each VPC attaches once.

One VPC, many accounts#

For a dozen small tools, the network team shares one VPC's subnets with their accounts through AWS RAM, and alone changes the routes.

Offering one service privately#

Twenty VPCs call the fraud team's scoring API. Instead of routing them all into its VPC, fraud publishes an endpoint service, and each consumer adds an interface endpoint.

Reaching the data centre#

Settlement files still go to a mainframe in MegaCorp's data centre. Site-to-Site VPN links the hub to it first; Direct Connect follows when volumes grow, with the VPN as backup.

Inspecting traffic#

Payment data brings auditors, who want traffic from the data centre inspected and outbound traffic limited to known domains. Security groups cannot filter by domain, so MegaCorp adds AWS Network Firewall to the hub.

MegaCorp's design gains its connectivity layer.

DNS#

Names on AWS come from Amazon Route 53: public names for the internet, private names inside VPCs, and a resolver in every VPC that forwards to and from the data centre.

Public and private names#

The merchant portal needs portal.megacorp.com on the internet; the settlement job needs ledger.internal.megacorp.com inside MegaCorp's VPCs only. The first lives in a public hosted zone, the second in a private hosted zone associated with those VPCs.

Names across the data centre#

The mainframe's name lives in the data centre's DNS, which must also resolve internal.megacorp.com. The network team adds an outbound endpoint with a forwarding rule for corp.megacorp.com, and an inbound endpoint the data centre forwards to, and shares the rule through AWS RAM.

Read more What is Route 53 VPC Resolver? · Choosing between alias and non-alias records

MegaCorp's design gains its DNS layer.

Landing zones#

MegaCorp's accounts were set up one at a time. A landing zone gives every account the same logging, access and controls from birth, and keeps them there.

From accounts to a landing zone#

By its second year MegaCorp has thirty hand-built accounts, and nobody can promise the auditors that every one logs every API call where its own administrators cannot change it. The platform team adopts AWS Control Tower.

Read more What is AWS Control Tower? · What is an Azure landing zone?

Vending accounts#

New accounts come from Account Factory: a staging account requested in the Workloads OU arrives with the baseline and the OU's controls in force. Terraform teams use Account Factory for Terraform instead.

Read more Provision and manage accounts with Account Factory · Overview of Account Factory for Terraform (AFT)

MegaCorp's design gains its governance layer.

Choosing compute#

AWS runs code on servers you manage, in containers it schedules, or as functions it runs per event. The less you manage, the less you control: choose the most managed option each workload can live with.

Three ways to run code#

MegaCorp's payments team has three workloads. The payments API is a Java service that runs all day, the nightly settlement job takes about 40 minutes, and a handler takes bursts of small webhook calls from the card schemes. Each could run in any of three models, which differ in who does the work of running it.

Read more Choosing an AWS compute service

Deciding, workload by workload#

The team asks the same questions of each workload, in order, and stops at the first yes.

The webhook handler is short, event-driven work, so it goes to Lambda. The API runs all day and the settlement job runs for 40 minutes, too long for one Lambda invocation as of September 2026, so both go to ECS on Fargate. Only the fraud team's scoring model, which needs GPUs, lands on EC2.

Read more Choosing an AWS container service · Lambda quotas

How AWS got here#

Each step in AWS's compute history hid more of the server. Simpler platforms remain: AWS Elastic Beanstalk runs your code on EC2 that it manages, and Amazon Lightsail bundles servers, databases and networking at a predictable monthly price. AWS App Runner, the simplest path for web apps, is closed to new customers, and AWS points new applications to Amazon ECS Express Mode instead.

Read more AWS App Runner availability change · What is Amazon Lightsail?

EC2 and Auto Scaling#

Amazon EC2 rents virtual servers by the second, and EC2 Auto Scaling keeps a healthy number of them running. Use them when a workload needs the server itself, and put even one inside a group.

One instance#

The fraud team's scoring model needs GPUs and a driver installed on the host, so it runs on EC2. An instance boots from an Amazon Machine Image, which holds its operating system and software, and its instance type fixes the CPU, memory and accelerators. In c7gn.xlarge, c means compute optimized, 7 the generation, g Graviton, n extra networking, and xlarge the size.

A fleet: Auto Scaling groups#

One instance is one failure away from an outage, and scoring load triples on sale days. The team runs the instances in an Auto Scaling group across two zones, behind a load balancer: at least two, at most eight, and replaced when a health check fails.

Paying for instances#

The scoring fleet runs all year, while the nightly retraining job can stop and restart. The team pays for each differently.

Retraining goes to Spot. A Savings Plan covers the fleet's two steady instances, and the sale-day bursts run On-Demand.

Read more Amazon EC2 billing and purchasing options · Spot Instance interruption notices · Use the Instance Metadata Service to access instance metadata · AWS Systems Manager Session Manager

How EC2 grew#

Read more Amazon EC2 documentation

Containers#

A container image is built once and runs anywhere. On AWS, Amazon ECR stores the images, Amazon ECS or Amazon EKS runs them, and AWS Fargate supplies the capacity.

Images, and where they live#

The pipeline builds the payments API into a container image on every merge and pushes it to a private Amazon ECR repository; the same image then runs in development and in production.

Running containers with ECS#

The API runs as an ECS service of at least two tasks on Fargate behind a load balancer; the settlement job is a task that runs nightly and stops.

ECS or EKS#

The risk team already runs Kubernetes in the data centre, so its model platform moves to Amazon EKS; the payments team, new to containers, stays on ECS.

Read more Choosing an AWS container service

How AWS got here#

MegaCorp's design gains its compute layer.

Read more Amazon ECS documentation

Serverless#

AWS Lambda runs a function for each event and bills by the millisecond; AWS Step Functions joins functions and services into workflows that retry, wait and remember. Both remove servers, not the limits you design around.

Functions that run per event#

Card-scheme webhooks land on an Amazon SQS queue, and a Java function settles each message. Lambda reads the queue, hands the function batches of messages, and runs as many copies as the queue needs, up to the account's concurrency.

public class SettlementHandler implements RequestHandler<SQSEvent, SQSBatchResponse> {

    private final Settlements settlements;

    public SettlementHandler() {
        this(new Settlements());
    }

    SettlementHandler(Settlements settlements) {
        this.settlements = settlements;
    }

    @Override
    public SQSBatchResponse handleRequest(SQSEvent event, Context context) {
        List<SQSBatchResponse.BatchItemFailure> failures = new ArrayList<>();
        for (SQSEvent.SQSMessage message : event.getRecords()) {
            try {
                settlements.settle(message.getMessageId(), message.getBody());
            } catch (IllegalArgumentException e) {
                failures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
            }
        }
        return new SQSBatchResponse(failures);
    }
}

The handler reports only the messages that failed, so only those are retried. The team reserves concurrency for it, so no other function can starve it and it cannot flood the ledger database.

When a statement file lands in Amazon S3, S3 invokes an indexing function asynchronously, and Lambda owns the retries.

Read more How Lambda handles errors and retries with asynchronous invocation

Java and cold starts#

A Java function initializes slowly: the JVM starts and frameworks load before the first request. SnapStart snapshots the initialized function when a version is published and resumes new environments from it, at no extra cost for Java. Provisioned concurrency keeps environments warm, for a fee.

Read more Improving startup performance with Lambda SnapStart · Building Lambda functions with Java

Workflows#

Settling a merchant's day takes several steps: validate the file, post to the ledger, notify the merchant, and undo if a step fails. The team models it as a Step Functions state machine instead of functions that call each other.

Read more Lambda durable functions · Lambda Managed Instances

Object and file storage#

Amazon S3 keeps objects, Amazon EBS gives one instance a disk, and Amazon EFS and Amazon FSx share files. Choose by how data is reached, not how much there is.

Read more Choosing an AWS storage service

Objects: Amazon S3#

Every merchant statement is a PDF in an S3 bucket, kept for seven years because the regulator says so.

Disks: Amazon EBS#

The fraud team's GPU instances boot from EBS volumes and keep model files on a second gp3 volume.

Shared files: EFS and FSx#

Settlement tasks in both zones share a directory of bank files on EFS.

The risk team's Windows reports read an SMB share on Amazon FSx for Windows File Server. FSx also runs NetApp ONTAP, OpenZFS and Lustre file systems. You provision storage, IOPS and throughput; a Windows file system is Single-AZ or Multi-AZ, and joins Active Directory when you create it.

Read more What is FSx for Windows File Server?

Relational databases#

Amazon RDS runs six familiar database engines for you; Amazon Aurora rebuilds MySQL and PostgreSQL on storage shared across three zones. Either way, the schema, the queries and their tuning stay yours.

The ledger is the payments team's most precious data: every posting, in PostgreSQL. It moves to Aurora PostgreSQL. The risk team's reports run on SQL Server, which Aurora does not offer, so that database moves to RDS for SQL Server.

Read more Choosing an AWS database service

Amazon RDS#

Amazon Aurora#

MegaCorp's design gains its data layer: the ledger's writer and reader sit in the private subnets of both zones.

Read more Using Amazon Aurora Global Database · Amazon RDS Proxy

NoSQL and caching#

Amazon DynamoDB trades joins for predictable speed at any size, and Amazon ElastiCache keeps hot data in memory. Both reward knowing how data will be read before you store it.

In the 2004 holiday season, outages at Amazon were traced to commercial technology pushed past its limits. Amazon built Dynamo, described it in a 2007 paper, and found it still hard to run. DynamoDB, launched in 2012, put Dynamo's scaling behind a service AWS operates.

Read more Choosing an AWS database service

Amazon DynamoDB#

Card schemes sometimes send a webhook twice. The settlement function writes each event ID to a DynamoDB table only if it is absent, so a repeat fails the condition and is skipped. Time to Live removes old IDs.

Read more DynamoDB on-demand capacity mode

Amazon ElastiCache#

The merchant portal reads each merchant's settings on every page. The team caches them in Valkey, the open-source fork of Redis made in 2024: read the cache first, fall back to Aurora on a miss, and store the answer for five minutes.

MegaCorp's design gains a NoSQL layer.

Messaging and events#

Queues hold work, topics copy messages, event buses route events, and streams keep an ordered record to replay. Choose by who needs a message, and for how long.

When a payment settles, the merchant wants a notice, statements need a line, and fraud wants every card event. The payments service publishes what happened, and each consumer subscribes.

Read more Amazon SQS, Amazon SNS, or Amazon EventBridge?

Queues: Amazon SQS#

Topics and buses: SNS and EventBridge#

Streams: Kinesis Data Streams#

Teams already running Apache Kafka can use Amazon MSK instead: the same Kafka APIs and tools, with AWS running the brokers.

MegaCorp's design gains its messaging layer.

Read more Welcome to the Amazon MSK Developer Guide

APIs and the edge#

Every outside request meets a front door: a load balancer, an API gateway or a content delivery network, with a firewall in front. Choose by what comes through.

Read more What is Elastic Load Balancing?

Load balancers#

APIs: Amazon API Gateway#

The edge: CloudFront and AWS WAF#

AWS Shield Standard guards every AWS customer against common DDoS attacks at no extra charge; Shield Advanced is paid.

MegaCorp's design gains its front door.