Design secure architectures

Shared responsibility and global infrastructure

• AWS is responsible for security of the cloud: facilities, hardware, the hypervisor, and the managed-service software. You are responsible for security in the cloud: IAM, data, network configuration, guest OS and patching on EC2.
• The split moves with the service. On EC2 you patch the OS. On RDS, AWS patches the engine and OS, but you still control security groups, parameter settings and who can connect. On Lambda and S3, AWS runs the platform, and you own the code, the permissions and the data.
• A Region is a separate geographic area with its own resources and data. Data stays in a Region unless you move it, which matters for data residency. An Availability Zone is one or more data centres in a Region. Deploying across at least two AZs is the baseline for any production design. Edge locations serve CloudFront, Route 53 and Global Accelerator, and are not Regions.
• AWS Artifact gives you AWS’s compliance reports (SOC, PCI, ISO) and lets you accept agreements. It answers “how do I get AWS’s audit report”.

Identity and access management

How IAM decides

AWS evaluates every request against every policy that applies:

1. An explicit deny anywhere wins, always.
2. Otherwise the request needs an explicit allow in a policy that is not blocked by a guardrail.
3. With no allow, the default is an implicit deny.

Several policy types can apply to one request:

For access within one account, an identity policy or a resource policy that allows is enough. For cross-account access, both sides must allow: the resource policy (or role trust policy) in the owning account, and an identity policy in the calling account.

Users, groups, roles and best practice

• A user is a long-lived identity with a password and optional access keys. A group is a set of users (groups can’t be nested and can’t be principals). A role has no credentials of its own. Something assumes it and receives temporary credentials from STS.
• Least privilege: start from nothing and add. Use IAM Access Analyzer to find resources shared outside your account or organization, to generate policies from CloudTrail activity, and to find unused permissions. Use the credential report and “last used” data to retire stale keys.
• Root user: turn on MFA, don’t create access keys for it, lock it away, and use it only for the few tasks that need it (changing the account’s support plan, closing the account, restoring IAM permissions, some billing settings). Organizations can centralise root access management for member accounts.
• MFA options are virtual authenticator apps, FIDO2 security keys and hardware tokens. A policy condition aws:MultiFactorAuthPresent can require MFA for sensitive actions.
• Policy elements: Effect, Principal (resource policies only), Action, Resource, Condition. Useful conditions: aws:SourceIp, aws:SourceVpce, aws:SecureTransport, aws:PrincipalOrgID (allow anyone in my organization, without listing accounts), aws:RequestedRegion and aws:PrincipalTag for attribute-based access control.
• Roles for compute: EC2 gets credentials from a role through an instance profile (read from the instance metadata service, rotated automatically). Lambda uses an execution role. ECS tasks use a task role. Never put long-term access keys on a server or in code.
• IMDSv2 (session-token based) protects instance credentials from SSRF attacks. Require it on new instances.

Cross-account access and role switching

• The standard pattern: Account B creates a role with permissions and a trust policy naming Account A. A user in A (with permission to call sts:AssumeRole) assumes it and gets temporary credentials, which expire (15 minutes to 12 hours, one hour by default).
• Role switching in the console is the same thing for a person.
• For a third-party vendor, add an external ID to the trust policy so the vendor can’t be tricked into acting on your behalf for another customer (the confused deputy problem).
• Resource policies (S3, SQS, SNS, KMS, Lambda) can grant access cross-account directly with no role. The caller then keeps its own permissions, whereas assuming a role means giving up the original permissions for the session. That matters when a job must read from a bucket in another account and write to one in its own.
• AWS Resource Access Manager (RAM) shares resources such as subnets, Transit Gateways, Route 53 Resolver rules and License Manager configurations with other accounts or an organization, instead of duplicating them. VPC sharing lets many accounts run workloads in subnets owned by one central networking account.

Multi-account strategy

• AWS Organizations groups accounts into OUs, gives consolidated billing (one invoice, pooled volume discounts, shared Reserved Instance and Savings Plans benefit) and applies SCPs.
• SCPs are guardrails. They don’t apply to the management account, they limit even the root user of a member account, and they don’t grant anything. “Prevent every account from leaving the organization, disabling CloudTrail or using Regions other than eu-west-1, even for administrators” is an SCP. Use a deny list (allow everything, deny specific actions) or an allow list.
• AWS Control Tower builds a landing zone: a multi-account environment with a management account, log archive and audit accounts, preventive controls (SCPs), detective controls (Config rules) and Account Factory for vending new accounts. “Set up a secure multi-account environment with best-practice guardrails quickly” is Control Tower.
• Separate accounts by workload, environment and function. An account is the strongest isolation boundary in AWS, so one account for security tooling and one for logs is standard.
• AWS Firewall Manager applies WAF rules, Shield Advanced protections, security group policies and Network Firewall policies across an organization from one place.

Federation and sign-in

Use federation, not IAM users, when you have more than a handful of people or a corporate directory. “Employees use their existing corporate credentials” means federation.

Workloads, applications and network security

VPC building blocks

• A VPC spans a Region. A subnet lives in one AZ. AWS reserves 5 IP addresses in every subnet. A VPC CIDR is between /16 and /28, and you can add secondary CIDRs.
• A public subnet has a route to an internet gateway (and its instances have public or Elastic IPs). A private subnet has no such route. The classic three-tier layout: load balancer in public subnets, app tier in private subnets, database in private (or isolated) subnets, each tier spread across at least two AZs.
• A NAT gateway sits in a public subnet and lets private instances start outbound connections to the internet while blocking inbound. It lives in one AZ, so deploy one per AZ for availability (a single shared one is cheaper but is a single point of failure and incurs cross-AZ charges). IPv6 outbound-only uses an egress-only internet gateway. A NAT instance is the old self-managed option.
• Route tables decide where traffic goes. Most specific route wins. Traffic to peering, Transit Gateway, VPN and endpoints all needs a route.
• VPC Flow Logs record accepted and rejected traffic metadata to CloudWatch Logs, S3 or Firehose. They don’t capture payloads. Traffic Mirroring copies packets for inspection.

Security groups vs network ACLs

To block one malicious IP use a NACL deny because security groups can’t deny. For “the database accepts traffic only from the app tier”, reference the app tier’s security group as the source, and it keeps working as instances come and go.

Reaching AWS services without the internet

• Endpoint policies limit what can be done through the endpoint, and bucket policies can require aws:SourceVpce so data is only reachable from your VPC.
• A gateway endpoint also removes NAT gateway data processing charges for S3 and DynamoDB traffic, so it is both the secure and the cheap answer.
• AWS PrivateLink lets you expose your own service (behind a Network Load Balancer) to other VPCs and accounts one-way, with no peering and no CIDR overlap problems. Consumers can’t reach anything else in your VPC.

Edge protection

Typical DDoS-resilient design: CloudFront and Route 53 in front, ALB behind with WAF, Auto Scaling for the app tier, and the origin locked so only CloudFront can reach it (an AWS managed prefix list for CloudFront in the ALB’s security group, or a secret header).

Securing connections to on-premises

• Site-to-Site VPN: IPsec over the internet, two tunnels per connection (two endpoints in different AZs), about 1.25 Gbps per tunnel, set up in minutes. Needs a virtual private gateway or Transit Gateway on the AWS side and a customer gateway device.
• Direct Connect: dedicated private network link (1, 10 or 100 Gbps dedicated; smaller hosted connections through partners). Consistent latency, but not encrypted by default, and takes weeks to provision. For encryption use a VPN over a public VIF, a VPN over Direct Connect, or MACsec on supported dedicated connections.
• Direct Connect + VPN backup is the usual resilient hybrid design. Client VPN is for remote users to reach a VPC.

Secrets and application configuration

Both encrypt with KMS and are read at runtime through the instance or task role, so nothing is hard-coded or stored in plain environment variables or user data. Lambda, ECS and CloudFormation can reference both.

Cognito, GuardDuty, Macie and the other security services

Threat vectors outside AWS: DDoS (Shield, CloudFront, Route 53, Auto Scaling), SQL injection and XSS (WAF), brute-force and credential stuffing (WAF rate limits, Cognito, MFA), port scans and unwanted ports (security groups, NACLs, Network Firewall).

Data security controls

Encryption at rest with KMS

• AWS managed keys (aws/s3, aws/ebs) are created for you. You can view them but not edit their policies, and they rotate every year automatically. Customer managed keys let you set the key policy, enable rotation (yearly by default, or custom period), disable, delete (7 to 30 day waiting period) and share cross-account.
• The key policy is the primary access control for a KMS key. IAM policies only work if the key policy allows IAM to control access. Cross-account use needs the key policy in the owner account and an IAM policy in the caller’s account.
• Envelope encryption: KMS encrypts small data keys, and the data keys encrypt the data (KMS directly encrypts at most 4 KB). Services do this for you.
• Multi-Region keys share key material across Regions so ciphertext from one can be decrypted in another. Imported key material and external key stores are for strict key-origin requirements.
• CloudHSM is a single-tenant, dedicated hardware module (FIPS 140-2 level 3) where you control the keys and AWS cannot see them. Pick it when a rule demands dedicated HSMs or customer-held key custody. KMS is the default otherwise.
• Symmetric KMS keys are the default. Use asymmetric keys for signing or when public-key encryption must happen outside AWS.

Service defaults to know:

An encrypted EBS snapshot can only be shared with another account if it uses a customer managed key that the other account may use. Snapshots with the AWS managed key can’t be shared. The recipient should copy and re-encrypt with their own key.

Encryption in transit and certificates

• Use TLS everywhere. AWS Certificate Manager (ACM) provisions public certificates for free, installs them on ELB, CloudFront and API Gateway, and renews them automatically (DNS validation renews cleanly). You can’t export public ACM certificates to put on an EC2 instance’s web server. ACM certificates are Regional. A certificate for CloudFront must be in us-east-1. ACM Private CA issues internal certificates (paid).
• ALB and NLB can terminate TLS (offload), or pass encrypted traffic through to targets for end-to-end encryption. Enforce HTTPS with a redirect rule, aws:SecureTransport in S3 bucket policies, rds.force_ssl for PostgreSQL, and require TLS on Redis.
• CloudFront can enforce viewer HTTPS and talk HTTPS to the origin. Field-level encryption protects specific form fields all the way to the application.

S3 access control and protection

• Block Public Access at account and bucket level stops accidental exposure. New buckets have it on by default. ACLs are disabled by default through Object Ownership set to bucket owner enforced, so use policies, not ACLs.
• Bucket policies grant or deny, including across accounts and with conditions (aws:SourceVpce, aws:PrincipalOrgID, aws:SecureTransport). Access Points give each application its own policy and network origin on a shared bucket. S3 Access Grants map directory identities to data.
• Presigned URLs give time-limited access to one object using the signer’s permissions. CloudFront signed URLs and cookies do the same for private content behind a distribution. Origin access control (OAC) keeps the bucket private so only your distribution reads it (replaces the older origin access identity).
• Versioning keeps every version and protects against overwrite and accidental delete (a delete adds a delete marker). MFA Delete requires MFA to permanently delete a version.
• Object Lock (needs versioning) gives write-once-read-many (WORM):
  • Governance mode: users with special permission can override or delete.
  • Compliance mode: nobody can delete or shorten retention before the date, including root.
  • Legal hold: indefinite lock without a date, independent of retention.
• S3 Glacier Vault Lock does the same job for a Glacier vault with an immutable policy. AWS Backup Vault Lock locks backups.
• Replication (needs versioning on both buckets): CRR across Regions for compliance, latency or DR; SRR in the same Region for log aggregation or copies to another account. It applies to new objects. Batch Replication copies existing ones. Replication Time Control targets 15 minutes.

Data governance, classification and retention

• Macie discovers and classifies sensitive data in S3. Tags, S3 Storage Lens and Inventory report on what you hold.
• Lake Formation gives column, row and cell-level permissions on data lakes, centrally.
• Retention: S3 lifecycle rules expire or archive data, DynamoDB TTL deletes expired items, CloudWatch Logs has a retention setting, Backup plans have retention periods. Compliance needs (retain 7 years, can’t delete) point to Object Lock, Vault Lock and Backup Vault Lock.
• Data recovery and backups: AWS Backup centralises policy-based backups of EBS, EFS, RDS, DynamoDB, FSx, S3, EC2 and more, with cross-Region and cross-account copies, Organizations-wide policies and vault lock. RDS has automated backups (0–35 days, point-in-time restore) and manual snapshots. EBS has incremental snapshots (Data Lifecycle Manager automates them, Recycle Bin recovers deleted ones). DynamoDB has point-in-time recovery for 35 days and on-demand backups.
• Key rotation and certificates: KMS customer managed keys rotate yearly with the option to change the period; Secrets Manager rotates credentials on a schedule; ACM renews certificates; rotate IAM user keys or, better, remove them.

Mapping compliance requirements