Soru

Zorluk: OrtaMulti-Account Governance and Organizational Structure

An enterprise manages its multi-account environment using AWS Organizations. The solutions architect needs to restrict member accounts in the 'Workloads' Organizational Unit (OU) so they can only launch EC2 instances of type `t3.micro` or `t3.small`. Developers in these member accounts already have the `AdministratorAccess` managed IAM policy attached to their roles. The solutions architect wants to implement this restriction with minimal administrative overhead. Which of the following approaches should the solutions architect implement?

  1. Attach a Service Control Policy (SCP) to the 'Workloads' OU that denies the `ec2:RunInstances` action if the instance type is neither `t3.micro` nor `t3.small`, and rely on the existing local IAM policies to grant the launch permissions.Cevap
  2. B
    Replace the default `FullAWSAccess` SCP on the 'Workloads' OU with a custom SCP that explicitly allows the `ec2:RunInstances` action for `t3.micro` and `t3.small` instance types, then remove local IAM permissions.
  3. C
    Attach an SCP to the 'Workloads' OU that allows `ec2:RunInstances`, and share the AWS-managed KMS key `aws/ebs` from the management account to encrypt the EC2 volumes in the member accounts.
  4. D
    Configure an SCP to deny non-compliant instances, and configure a centralized S3 bucket policy in a logging account with a wildcard principal to collect CloudTrail logs from the member accounts.

Cevap

Attach a Service Control Policy (SCP) to the 'Workloads' OU that denies the `ec2:RunInstances` action if the instance type is neither `t3.micro` nor `t3.small`, and rely on the existing local IAM policies to grant the launch permissions.
The correct approach uses an SCP with an explicit deny for all instance types except the permitted ones. Because SCPs serve as permission filters rather than direct permission providers, they do not grant access on their own. Since the member account developers already possess the AdministratorAccess IAM policy, they already have local authorization to run instances. The deny SCP restricts this local capability only for non-compliant instance types, accomplishing the goal with zero modification of local IAM policies.

Adım Adım Çözüm

1
Analyze how SCPs and IAM policies interact in AWS Organizations.
SCPs act as filters and define the maximum allowable permissions, but they do not grant permissions. Local IAM policies must still grant the permission for an action to succeed.
To ensure developers can run the permitted instances, they need both an SCP that does not deny the action and a local IAM policy that explicitly allows it.
2
Determine the most operationally efficient way to enforce the restriction.
Creating an SCP with an explicit Deny for all instance types except the allowed ones, while keeping the default FullAWSAccess SCP, blocks the non-compliant types without affecting other allowed services.
An explicit Deny overrides any Allow. Using a Deny SCP ensures non-compliant instances cannot be run, regardless of the admin permissions locally.
3
Verify if local IAM changes are required.
Since developers already have the AdministratorAccess policy, they already have permissions to run EC2 instances. No changes to member accounts are needed.
This minimizes administrative overhead by keeping the policy changes centralized at the OU level.

Anahtar Kavram

SCPs define permission boundaries (filters) and do not grant permissions directly. The effective permission is the intersection of the SCP and local IAM policies.
Tahmini Süre:2m 0s
Bu soruyu puanla