Short answer: Absolutely not — using "*" for the Resource field here is a major security anti-pattern and violates AWS's core least privilege security principle. Let’s break down why this is risky, and fix your original "Access Denied" issue the right way.

Why Using "*" Is Dangerous #

• Overly Broad Permissions: Setting "Resource": "*" for s3:PutObject gives your Lambda function permission to write objects to every S3 bucket in your AWS account (and potentially cross-account buckets if other policies allow it). If this IAM role is ever compromised—say via a vulnerability in your Lambda code or accidental permission leaks—an attacker could overwrite critical data, inject malicious files, or exfiltrate sensitive information by writing to external buckets.
• Breaks Compliance: Most regulatory frameworks (like PCI-DSS, HIPAA, or GDPR) require strict adherence to least privilege. Wildcard permissions will almost certainly fail compliance audits and leave your account out of alignment with security standards.
• Masks Root Causes: Using "*" bypasses the real issue behind your "Access Denied" error, preventing you from fixing simple configuration mistakes that are usually the actual culprit.

Fixing the Original "Access Denied" Error #

Your initial policy was nearly correct—you just likely ran into one of these common misconfigurations:

1. Incorrect Bucket ARN: Double-check that you replaced __YOUR_BUCKET_NAME_HERE__ with your actual bucket name (all lowercase, no spaces). The correct format for object-level access is arn:aws:s3:::your-bucket-name/*—the /* at the end is critical, as it targets objects inside the bucket (without it, you’re granting permissions for bucket-level actions, not object writes).
2. Misattached IAM Role: Ensure the policy is attached to the exact IAM role your Lambda function is using. It’s easy to accidentally modify the wrong role in the AWS console.
3. Conflicting S3 Bucket Policy: Even if your IAM role has s3:PutObject permissions, the bucket’s own policy might explicitly deny access. Verify the bucket policy doesn’t include a Deny statement that blocks your Lambda’s role.
4. Organizational Restrictions: If your account is part of an AWS Organization, service control policies (SCPs) might restrict S3 access. Check with your account administrator if this applies.

Corrected Policy Example #

Here’s your original policy with the proper bucket ARN (replace your-actual-bucket-name with your real bucket):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-actual-bucket-name/*"
    }
  ]
}

Final Recommendation #

Always stick to the principle of least privilege: grant only the permissions your Lambda function needs, and only for the specific resources it interacts with. If you’re stuck on "Access Denied" errors, use AWS CloudTrail to look up the failed API call—it will show you the exact resource ARN being accessed and why the permission was denied.

内容的提问来源于stack exchange，提问作者sitara hussain