Designing Secure Architectures

AWS security starts with a simple rule: give every identity only the permissions it needs to do its job, and no more. This is the principle of least privilege, and in AWS it is enforced through AWS Identity and Access Management (IAM). An IAM user is a long-term identity for a person or application. An IAM group is a named collection of users that share the same permissions. An IAM role is an identity with no long-term credentials of its own — instead, a trusted identity assumes the role and receives temporary credentials.

Permissions are attached through policies: JSON documents that list which actions are allowed or denied on which resources. A policy can be attached to a user, a group, or a role, and one identity can have several policies attached at once.

Security in AWS is a shared job. Under the AWS shared responsibility model, AWS secures the infrastructure of the cloud — the hardware, the data centers, the host operating system — while you are responsible for security in the cloud: how you configure IAM, encrypt your data, and control network access. Nothing in this module removes that second half of the job from you.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::data-team-reports",
        "arn:aws:s3:::data-team-reports/*"
      ]
    }
  ]
}

When AWS decides whether to allow a request, it starts from implicit deny: nothing is allowed unless a policy says so. If any applicable policy contains an explicit Deny for that action, AWS denies the request no matter how many other policies allow it — an explicit deny always wins. This is why a permissions boundary or a service control policy (SCP) can only take permissions away, never grant them: they set the maximum an identity can do, and the identity's own policies still have to grant the action inside that ceiling.

Sharing access across AWS accounts works the same way, through a role rather than a shared password. The account that owns the resource creates a role with a trust policy naming which accounts (or which specific roles) are allowed to assume it. A user in the trusted account calls AWS Security Token Service (sts:AssumeRole) and receives temporary credentials scoped to that role's permissions — never the user's own permissions, and never a long-lived secret to leak.

For a whole organization's workforce, repeating this per account does not scale. AWS IAM Identity Center centralizes that: your engineers sign in once, and Identity Center hands out temporary, role-based access to every AWS account they are permitted to reach, based on group membership in your existing directory.

A VPC is your own isolated network inside AWS, split into subnets. A public subnet has a route to an internet gateway; a private subnet does not. Two independent controls filter traffic inside that network.

A security group is stateful and operates at the resource level (an EC2 instance, an RDS database, a load balancer). It only supports allow rules — if you send a request out, the response is let back in automatically, regardless of your inbound rules. A network ACL (NACL) is stateless and operates at the subnet level, covering every resource in that subnet whether you meant it to or not. NACLs support both allow and deny rules, and they evaluate their numbered rules in order — lowest number first — stopping at the first match. Because a NACL is stateless, allowing inbound traffic on a port does not automatically allow the outbound response; you have to write that rule yourself.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 443 \
  --source-group sg-0fedcba9876543210

Two AWS services add protection above the network layer. AWS WAF is a web application firewall: it inspects the content of HTTP(S) requests reaching a CloudFront distribution, an Application Load Balancer, an API Gateway REST API, and a few other resource types, and it can allow, block, count, or challenge (CAPTCHA) requests based on rules you write — an IP address, a country, a string in the request, or a request rate.

AWS Shield defends against distributed denial-of-service (DDoS) floods instead. Shield Standard is automatic and included at no extra charge for every AWS customer, and it already covers common network- and transport-layer (layer 3/4) attacks on resources like an ALB, CloudFront, or Route 53. Shield Advanced is a paid subscription that adds application-layer (layer 7) DDoS mitigation, near-real-time attack visibility, and access to the AWS DDoS Response Team — worth it for a high-visibility site that's a frequent target, not for every workload by default.

Two more pieces close the gap between "traffic reached the instance" and "the application is actually secure." First, application credentials: hardcoding a database password in source code means anyone with read access to that code has the password. AWS Secrets Manager stores it instead, and can rotate it automatically on a schedule using a small Lambda function — the application always asks Secrets Manager for the current value rather than embedding one.

Second, how private instances reach other AWS services without touching the public internet. A gateway VPC endpoint (for Amazon S3 and DynamoDB only) adds a route to those services through your subnet's route table, at no extra charge. A VPC interface endpoint, built on AWS PrivateLink, gives a private IP address inside your VPC for most other AWS services, so a private subnet can reach them without a NAT gateway or any route to the internet.

Encrypting data at scale creates a chicken-and-egg problem: encrypting a large object directly with a KMS key is slow, but a symmetric key stored in plaintext next to the data it protects isn't really protecting anything. AWS KMS solves this with envelope encryption: KMS generates a short-lived, random data key, uses your KMS key to encrypt just that data key, and hands both back to you. You encrypt the actual data locally with the plaintext data key, discard the plaintext copy, and store the encrypted data alongside the encrypted data key. The KMS key itself never leaves AWS KMS unencrypted — decrypting always means asking KMS to decrypt the small data key, not the bulk data.

A KMS key can be an AWS managed key (created and rotated automatically by an integrated service, and you can't edit its key policy) or a customer managed key (you control its key policy, its rotation schedule, and whether it can ever be deleted). Access to a KMS key is governed by its key policy — a resource policy attached to the key itself — working alongside any IAM identity policies, the same way an S3 bucket policy works alongside IAM.

{
  "Sid": "AllowReportingRoleToDecrypt",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/ReportingRole"
  },
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "*"
}

Protecting data in transit means terminating TLS with a certificate AWS trusts. AWS Certificate Manager (ACM) issues public TLS certificates and, when you use them with an integrated service such as Elastic Load Balancing, Amazon CloudFront, or Amazon API Gateway, renews them automatically before they expire — no manual certificate rotation to schedule. ACM certificates are trusted by all major browsers because they chain up to Amazon's public certificate authority.

One regional detail matters for a common architecture: if you want to attach an ACM certificate to a CloudFront distribution, you must request or import that certificate in the US East (N. Virginia) Region, regardless of which Region your origin servers run in. A certificate requested in any other Region simply won't show up as an option when you configure CloudFront.

ACM also lets you import a certificate issued by a third-party certificate authority, which is the option to reach for when a compliance requirement mandates a specific external CA rather than Amazon's own.

Encryption protects data from being read; it does nothing to protect data from being lost. That's a separate control: data recovery. Amazon S3 versioning keeps every version of an object so an accidental overwrite or delete isn't the last word, and cross-Region replication keeps a second copy in another Region for resilience or compliance. Amazon RDS takes automated daily snapshots plus continuous transaction logs, giving you point-in-time restore within your configured retention window, in addition to manual snapshots you keep as long as you like.

Data classification is the step before any of this: deciding which datasets are sensitive enough to need customer managed KMS keys, tighter key policies, and stricter retention, versus which can use simpler AWS managed defaults. Get the classification right first, and the encryption and backup choices that follow become much easier to justify to an auditor.