Help with separating Dev and Prod access using IAM policies and tags

Hello.

IAM policies vary in whether they allow tag-based identification depending on the action.
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html

Tags are another consideration in this process because tags can be attached to the resource or passed in the request to services that support tagging. To control access based on tags, you provide tag information in the condition element of a policy. To learn whether an AWS service supports controlling access using tags, see AWS services that work with IAM and look for the services that have Yes in the ABAC column. Choose the name of the service to view the authorization and access control documentation for that service.

For example, the "DescribeInstances" action can display EC2 instances, but this action cannot use "aws:ResourceTag" as a condition key.
Therefore, you need to create an IAM policy while checking whether control by tags is possible for each service's actions, as described in the following document.
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html

Using tags to control access to AWS resources within a single account is a valid approach when separate accounts aren't feasible. However, there are several issues with your current implementation that need to be addressed:

1. List Operations: Your policies don't allow users to list resources before accessing them. For example, EC2 users need ec2:DescribeInstances permissions without tag conditions first, as they can't see resources to know which ones have the appropriate tags.

2. S3 Bucket Tags vs Object Tags: Your S3 policy has issues because S3 bucket operations and object operations work differently with tags. The condition s3:ExistingObjectTag only applies to object operations, not bucket operations like ListBucket. For bucket-level operations, you need aws:ResourceTag.

3. Route53 Tagging Support: Not all Route53 resources support tagging, so your Route53 policy may not work as expected.

4. Creating New Resources: Your policy doesn't address how users can create new resources with the appropriate tags. You need to use aws:RequestTag conditions to enforce tagging during resource creation.

Here's an improved approach for your DevPolicy (apply similar changes to ProdPolicy):

For EC2:

• Add a statement allowing ec2:Describe* actions without tag conditions
• Use aws:ResourceTag/Environment for existing resource operations
• Use aws:RequestTag/Environment for resource creation operations to enforce proper tagging

For S3:

• For bucket operations, use bucket policies or resource-based policies
• For object operations, continue using s3:ExistingObjectTag
• Add a condition to enforce tagging on new objects using s3:RequestObjectTag

For RDS:

• Add a statement allowing rds:Describe* actions without tag conditions
• Keep the existing conditions for other operations

Additionally, consider adding a policy that prevents users from modifying the Environment tag once it's set, to prevent Dev users from changing Dev resources to Prod and vice versa.

This approach will help ensure that Dev users can only access Dev resources and Prod users can only access Prod resources within your single AWS account.
Sources
Controlling access to and for IAM users and roles using tags - AWS Identity and Access Management
Controlling access to AWS resources using tags - AWS Identity and Access Management
Using tags with IAM policies - AWS RoboMaker
IAM tutorial: Define permissions to access AWS resources based on tags - AWS Identity and Access Management