Centralized frontend with a decentralized AWS accounts

Yes, this is possible to implement. You'll need to create:

1. An AWS Organization with member accounts
2. Identity federation for authentication
3. Proper IAM policies to enforce isolation
4. A unified web interface with dynamic permissions

1. AWS Organization Setup

• Create an AWS Organization with a management account
• Add member accounts for each department/team
• Implement Service Control Policies (SCPs) to enforce security boundaries

2. Authentication & Authorization

• Deploy Amazon Cognito in the management account
• Create separate user pools for each member account
• Configure identity federation with your corporate identity provider
• Implement attribute-based access control (ABAC) using Cognito attributes

3. Web Application Architecture

• Deploy a unified web application in the management account
• Implement API Gateway and Lambda functions to handle requests
• Use AWS SDK with assumed roles for cross-account access

4. Cross-Account Access Control

• Create IAM roles in each member account with:
  • Trust relationships limited to specific principals
  • Permission boundaries that restrict access to only that account's S3 buckets
• Implement dynamic role assumption based on user identity

5. S3 Bucket Policies

For each member account, implement S3 bucket policies that:

• Deny access from the organization's management account
• Allow access only from the member account's own IAM roles
• Include condition keys to validate the request context

Hope this helps.

Yes, what you're aiming to achieve is possible and can be designed securely with AWS Organizations while maintaining strict account-level isolation. Here's how you can approach the architecture:

Multi-Account Setup (AWS Organizations):

• Set up an AWS Organization with a management account and separate member accounts.
• Each member account owns and manages its own S3 buckets.

Federated Authentication (Cognito or External IdP):

• Use Amazon Cognito or integrate with a third-party identity provider (like Okta, Auth0, or Azure AD).
• Each user is mapped to a specific AWS account via identity claims or group mapping.

Cross-Account IAM Roles with Scoped Permissions:

• In each member account, create IAM roles with restricted permissions (e.g., s3:ListBucket, s3:GetObject) only for that account’s buckets.
• Never share these roles with the management account or other member accounts.

Frontend/API Hosted in Central Account:

• Host your UI in the management or a separate “services” account (e.g., using Amplify, CloudFront + S3 static hosting, or an EC2/Container setup).
• The frontend interacts with APIs (e.g., API Gateway + Lambda) that assume roles into the respective member account using temporary credentials (STS) based on the user’s authenticated identity.

Security Best Practices:

• Use Resource-based policies and IAM conditions to strictly control access.
• Avoid using the organization management/root account for any data access.
• Use Service Control Policies (SCPs) to ensure no accidental access escalation between accounts.

This architecture ensures centralized user experience with decentralized, isolated data access, fully aligned with AWS security best practices.