Core AWS Services Best Practices

This is the checklist to run before and after standing up a new project on the ten core services.

Each item is a rule stated positively, with a one-line rationale. Work top to bottom - the groups run in dependency order, from identity and network outward to cost.

How to Use This List

Treat each box as an audit question against your own project.
The groups run roughly in order of foundation: identity and network first, then data, compute, messaging, and observability.
Most rules apply whether you provision from the SDK or from IaC.
Revisit the list whenever you add a new service or move to a new environment.

A - Identity & Access (IAM)

Give each workload its own least-privilege role. Scope actions and resource ARNs to exactly what the code calls, so a leak stays contained.
Use roles, not access keys, for applications. On EC2, ECS, Lambda, and EKS, attach a role and let the SDK pick up rotating temporary credentials.
Separate trust from permissions. Set the trust policy to the exact principal that assumes the role, and keep permission policies narrow.
Verify policies before relying on them. Use SimulatePrincipalPolicy to confirm a role allows what you expect and nothing more.

Let the default credential chain resolve a role rather than passing keys by hand.

# --- Python (boto3) ---
import boto3
 
# No keys in code: the SDK resolves the attached role's temporary credentials.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// No keys in code: the provider chain resolves the attached role.
const s3 = new S3Client({ region: "us-east-1" });

B - Networking (VPC)

Keep databases and internal services in private subnets. Only expose what must be public; RDS and ElastiCache should never be internet-facing.
Default-deny security groups, then add narrow ingress. Open specific ports to specific sources, not 0.0.0.0/0 on sensitive ports.
Reference security groups, not IP ranges, for internal traffic. "Web tier may reach database tier" by group keeps working as IPs change.
Spread across Availability Zones. Create a subnet per AZ so a single-AZ failure does not take the system down.
Tear down networks in reverse order. Delete security groups and subnets before the VPC, or deletion fails on dependencies.

C - Data & Storage (S3, RDS/Aurora, DynamoDB)

Keep S3 buckets private and share via presigned URLs. Avoid public ACLs; grant temporary, scoped access instead.
Handle the S3 us-east-1 LocationConstraint correctly. Omit the constraint in us-east-1, include it everywhere else.
Model DynamoDB around access patterns. Choose keys so hot reads become Query on one partition; prefer Query over Scan.
Use the DynamoDB document interface. Plain objects via boto3.resource / lib-dynamodb beat hand-writing typed attribute values.
Never hardcode database passwords. Use ManageMasterUserPassword (Secrets Manager) or IAM database authentication.
Keep the two RDS planes distinct. Provision with the SDK; run SQL with a normal driver over the instance endpoint.

D - Compute (EC2, Lambda)

Resolve AMIs at runtime. Read the latest image from an SSM public parameter instead of hardcoding a region-specific ID.
Prefer waiters over polling loops. Use instance_running, function_active_v2, and friends rather than hand-rolled sleep loops.
Attach least-privilege execution roles to functions. One role per function, granting only the actions that function makes.
Initialize clients outside the Lambda handler. Module-scope clients are reused across warm invocations, cutting latency.
Always clean up test compute. Terminate instances and delete throwaway functions so they stop billing.

Follow the SQS receive-process-delete contract. Delete only after successful processing, using the receipt handle.
Enable long polling. Set WaitTimeSeconds to cut empty receives, lower cost, and reduce latency.
Size visibility timeouts above worst-case processing. Or extend with ChangeMessageVisibility so messages are not reprocessed early.
Attach a dead-letter queue. A redrive policy stops poison messages from retrying forever.
Use SNS to fan out, SQS to buffer. Combine them (SNS to multiple SQS queues) for durable, multi-consumer delivery.
Make processing idempotent. Standard queues are at-least-once, so design for possible duplicates.

F - Observability & Cost (CloudWatch + cross-cutting)

Alarm on rates, not raw counts. Use metric math for error percentages and percentiles to avoid flapping alerts.
Wire alarms to an SNS topic. An alarm with no action changes state silently; route it to people or automation.
Tag every resource. Consistent tags make cost attribution, cleanup, and discovery possible.
Set budgets and billing alarms. Surface runaway loops before the invoice does.
Log the request id on failures. Capture RequestId / $metadata.requestId so AWS support can trace calls.
Prefer events over polling. Let SNS, SQS, and EventBridge notify your code instead of tight polling loops.

FAQs

Where should I start when standing up a new project?

With identity and network. Set up least-privilege roles and a VPC with private subnets first, because almost everything else depends on them being right.

Why roles instead of access keys?

Roles hand your code rotating temporary credentials with no stored secret to leak. Access keys are long-lived, hard to rotate, and a common breach source, so reserve them for cases with no role path.

What is the single most common cost mistake?

Tight polling and unbounded loops. They turn one logical action into thousands of billed requests. Use waiters, long polling, batching, and event-driven patterns instead.

How do I avoid processing an SQS message twice?

Delete a message only after it is fully processed, size the visibility timeout above your processing time, and make the work idempotent. Use a FIFO queue if you need exactly-once.

Why keep databases in private subnets?

An internet-facing database is a large attack surface. Placing RDS and ElastiCache in private subnets, reachable only from your application's security group, drastically reduces exposure.

Why alarm on rates rather than counts?

Raw counts scale with traffic and cause noisy, flapping alarms. A rate or percentage stays meaningful across traffic levels, so the alarm fires on real problems, not on growth.

How should I model a DynamoDB table?

Start from your access patterns, not your entities. Choose keys so your most frequent reads become single-partition Query calls, and add indexes for secondary patterns. Avoid Scan on hot paths.

What order do I tear resources down in?

Reverse of creation. For networking, delete security groups and subnets before the VPC. For IAM, detach policies before deleting them and the role. Dependencies must go first.

Why resolve AMIs at runtime?

AMI IDs are region-specific and are republished over time. Reading the latest ID from an SSM public parameter keeps launches working across regions and as images update.

Do these rules apply to IaC too?

Mostly yes. Least privilege, private networking, tagging, dead-letter queues, and rate-based alarms are architectural habits that apply whether you provision from the SDK or from CloudFormation, CDK, or Terraform.

Why These 10 Services Come First - the map these practices apply to.
AWS IAM via SDK: Users, Roles & Policies - the least-privilege habits in group A.
Amazon VPC via SDK: Your First Network - the private-network habits in group B.
Amazon SQS via SDK: Your First Queue - the receive-process-delete rules in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Core AWS Services Best Practices

This is the checklist to run before and after standing up a new project on the ten core services.

Each item is a rule stated positively, with a one-line rationale. Work top to bottom - the groups run in dependency order, from identity and network outward to cost.

How to Use This List

Treat each box as an audit question against your own project.
The groups run roughly in order of foundation: identity and network first, then data, compute, messaging, and observability.
Most rules apply whether you provision from the SDK or from IaC.
Revisit the list whenever you add a new service or move to a new environment.

A - Identity & Access (IAM)

Give each workload its own least-privilege role. Scope actions and resource ARNs to exactly what the code calls, so a leak stays contained.
Use roles, not access keys, for applications. On EC2, ECS, Lambda, and EKS, attach a role and let the SDK pick up rotating temporary credentials.
Separate trust from permissions. Set the trust policy to the exact principal that assumes the role, and keep permission policies narrow.
Verify policies before relying on them. Use SimulatePrincipalPolicy to confirm a role allows what you expect and nothing more.

Let the default credential chain resolve a role rather than passing keys by hand.

# --- Python (boto3) ---
import boto3
 
# No keys in code: the SDK resolves the attached role's temporary credentials.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// No keys in code: the provider chain resolves the attached role.
const s3 = new S3Client({ region: "us-east-1" });

B - Networking (VPC)

Keep databases and internal services in private subnets. Only expose what must be public; RDS and ElastiCache should never be internet-facing.
Default-deny security groups, then add narrow ingress. Open specific ports to specific sources, not 0.0.0.0/0 on sensitive ports.
Reference security groups, not IP ranges, for internal traffic. "Web tier may reach database tier" by group keeps working as IPs change.
Spread across Availability Zones. Create a subnet per AZ so a single-AZ failure does not take the system down.
Tear down networks in reverse order. Delete security groups and subnets before the VPC, or deletion fails on dependencies.

C - Data & Storage (S3, RDS/Aurora, DynamoDB)

Keep S3 buckets private and share via presigned URLs. Avoid public ACLs; grant temporary, scoped access instead.
Handle the S3 us-east-1 LocationConstraint correctly. Omit the constraint in us-east-1, include it everywhere else.
Model DynamoDB around access patterns. Choose keys so hot reads become Query on one partition; prefer Query over Scan.
Use the DynamoDB document interface. Plain objects via boto3.resource / lib-dynamodb beat hand-writing typed attribute values.
Never hardcode database passwords. Use ManageMasterUserPassword (Secrets Manager) or IAM database authentication.
Keep the two RDS planes distinct. Provision with the SDK; run SQL with a normal driver over the instance endpoint.

D - Compute (EC2, Lambda)

Resolve AMIs at runtime. Read the latest image from an SSM public parameter instead of hardcoding a region-specific ID.
Prefer waiters over polling loops. Use instance_running, function_active_v2, and friends rather than hand-rolled sleep loops.
Attach least-privilege execution roles to functions. One role per function, granting only the actions that function makes.
Initialize clients outside the Lambda handler. Module-scope clients are reused across warm invocations, cutting latency.
Always clean up test compute. Terminate instances and delete throwaway functions so they stop billing.

Follow the SQS receive-process-delete contract. Delete only after successful processing, using the receipt handle.
Enable long polling. Set WaitTimeSeconds to cut empty receives, lower cost, and reduce latency.
Size visibility timeouts above worst-case processing. Or extend with ChangeMessageVisibility so messages are not reprocessed early.
Attach a dead-letter queue. A redrive policy stops poison messages from retrying forever.
Use SNS to fan out, SQS to buffer. Combine them (SNS to multiple SQS queues) for durable, multi-consumer delivery.
Make processing idempotent. Standard queues are at-least-once, so design for possible duplicates.

F - Observability & Cost (CloudWatch + cross-cutting)

Alarm on rates, not raw counts. Use metric math for error percentages and percentiles to avoid flapping alerts.
Wire alarms to an SNS topic. An alarm with no action changes state silently; route it to people or automation.
Tag every resource. Consistent tags make cost attribution, cleanup, and discovery possible.
Set budgets and billing alarms. Surface runaway loops before the invoice does.
Log the request id on failures. Capture RequestId / $metadata.requestId so AWS support can trace calls.
Prefer events over polling. Let SNS, SQS, and EventBridge notify your code instead of tight polling loops.

FAQs

Where should I start when standing up a new project?

With identity and network. Set up least-privilege roles and a VPC with private subnets first, because almost everything else depends on them being right.

Why roles instead of access keys?

Roles hand your code rotating temporary credentials with no stored secret to leak. Access keys are long-lived, hard to rotate, and a common breach source, so reserve them for cases with no role path.

What is the single most common cost mistake?

Tight polling and unbounded loops. They turn one logical action into thousands of billed requests. Use waiters, long polling, batching, and event-driven patterns instead.

How do I avoid processing an SQS message twice?

Delete a message only after it is fully processed, size the visibility timeout above your processing time, and make the work idempotent. Use a FIFO queue if you need exactly-once.

Why keep databases in private subnets?

An internet-facing database is a large attack surface. Placing RDS and ElastiCache in private subnets, reachable only from your application's security group, drastically reduces exposure.

Why alarm on rates rather than counts?

Raw counts scale with traffic and cause noisy, flapping alarms. A rate or percentage stays meaningful across traffic levels, so the alarm fires on real problems, not on growth.

How should I model a DynamoDB table?

Start from your access patterns, not your entities. Choose keys so your most frequent reads become single-partition Query calls, and add indexes for secondary patterns. Avoid Scan on hot paths.

What order do I tear resources down in?

Reverse of creation. For networking, delete security groups and subnets before the VPC. For IAM, detach policies before deleting them and the role. Dependencies must go first.

Why resolve AMIs at runtime?

AMI IDs are region-specific and are republished over time. Reading the latest ID from an SSM public parameter keeps launches working across regions and as images update.

Do these rules apply to IaC too?

Why These 10 Services Come First - the map these practices apply to.
AWS IAM via SDK: Users, Roles & Policies - the least-privilege habits in group A.
Amazon VPC via SDK: Your First Network - the private-network habits in group B.
Amazon SQS via SDK: Your First Queue - the receive-process-delete rules in group E.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Core AWS Services Best Practices

Buscar en la documentación

Core AWS Services Best Practices