Determining the appropriate use of resource policies for AWS services

Domain 1: Design Secure Architectures (30%)

📘AWS Certified Solutions Architect – (SAA-C03)

---

Understanding Resource Policies in AWS

Resource policies are a type of policy in AWS that are directly attached to AWS resources (like S3 buckets, Lambda functions, SQS queues, etc.). They control who can access the resource and what actions they can perform.

Think of it this way: there are two main types of access control in AWS:

1. Identity-based policies – attached to users, groups, or roles (IAM entities). These define what actions the user/role can do.
2. Resource-based policies – attached directly to the resource itself. These define who (user/role/account) can access this resource.

Resource policies are essential when you want cross-account access, public access, or fine-grained control for specific resources.

---

Common AWS Services Using Resource Policies

Some key AWS services that use resource policies include:

Service	Resource Policy Example
S3 (Simple Storage Service)	Bucket policies define who can read/write objects in a bucket.
SQS (Simple Queue Service)	Queue policies control which accounts or IAM roles can send/receive messages.
SNS (Simple Notification Service)	Topic policies define who can publish/subscribe to a topic.
Lambda	Function policies can allow other AWS services or accounts to invoke a Lambda function.
KMS (Key Management Service)	Key policies define who can use or manage encryption keys.

---

Components of a Resource Policy

A resource policy is written in JSON format and usually contains:

1. Version – the policy language version (e.g., "2012-10-17").
2. Statement – one or more statements defining permissions. Each statement includes:
   • Effect: "Allow" or "Deny"
   • Principal: Who is allowed or denied access (AWS account, user, role, service)
   • Action: What operations are allowed (e.g., s3:GetObject, sqs:SendMessage)
   • Resource: Which resource(s) the statement applies to
   • Condition (optional): Specific conditions for access, such as IP addresses, time, or encryption

Example: Allowing a specific AWS account to read objects from an S3 bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-secure-bucket/*"
    }
  ]
}

✅ Key point for the exam: The Principal element is required for resource policies. Without it, AWS doesn’t know who the policy applies to.

---

When to Use Resource Policies vs IAM Policies

Understanding when to use a resource policy is crucial for the exam.

Scenario	Use Resource Policy?	Notes
Grant access to users in another AWS account	✅ Yes	Useful for cross-account access.
Grant access to an external AWS service (like API Gateway calling Lambda)	✅ Yes	Needed for service-to-service access.
Restrict access to a specific S3 bucket for your own users	❌ Not necessary	Use IAM policies for simplicity.
Make an S3 bucket publicly readable	✅ Yes	Bucket policies can allow public access safely.
Fine-grained control for encryption keys in KMS	✅ Yes	Key policies are required; IAM alone is not enough.

Exam tip: AWS often tests whether you know cross-account vs same-account scenarios, public access, and service-to-service access.

---

Resource Policy Best Practices

1. Principle of Least Privilege – Only give the minimum permissions needed.
2. Use Conditions – Restrict access based on IP, time, or VPC.
3. Avoid Wildcards (*) in Principal – Don’t allow “everyone” unless necessary (like for public S3 buckets).
4. Combine with IAM Policies – Resource policies can be used together with IAM policies to create layered security.
5. Test policies – AWS IAM Policy Simulator can help test access before applying policies.

---

Key AWS Exam Points

• Resource policies are attached to the resource, not the user.
• Cross-account access usually requires a resource policy.
• IAM policies define what an identity can do; resource policies define who can access the resource.
• Some services require resource policies (KMS, S3 public access).
• Always consider conditions for extra security.
• JSON format is standard; understand Effect, Principal, Action, Resource, Condition.

---

Quick Summary for the Exam

1. What is it? A resource policy is a JSON document attached to an AWS resource controlling who can access it and how.
2. Why use it? Mainly for cross-account access, public access, and service-to-service access.
3. Where is it used? S3 buckets, SQS queues, SNS topics, Lambda functions, KMS keys.
4. Key elements: Effect, Principal, Action, Resource, Condition.
5. Best practice: Least privilege, use conditions, avoid wildcards, test before deploying.