Attempt 1 Flashcards
SCP is used for
SCP is used to create limited in AWS accounts. For larger account organizations.
SCPs alone are not sufficient to granting permissions to the accounts in your organization. No permissions are granted by an SCP
An SCP defines a guardrail, or sets limits, on the actions that the account’s administrator can delegate to the IAM users and roles in the affected accounts.
The administrator must still attach identity-based or resource-based policies to IAM users or roles, or to the resources in your accounts to actually grant permissions.
SCPs DON’T GIVE permission - they just control what an account CAN and CANNOT grant via identity policies.
Which accounts are affected by SCP policy
Member accounts can only be affected,
MANAGEMENT accounts cannot.
SCP are applied to
orginization OU
SCP FullAWSAccess
allows by default. need to add deny policy to restrict.
SCP Allow LIst
to implement, you will need to remove the FullAWSAccess and by doing that, only the SCP implicit default deny is in place and active. This leave room to explicitly add any allow policy.
How does SCP overlaps with Identity Policy?
SCP Limits before the Identity Policy
Terminate instance in ASG
terminate-instance-in-auto-scaling-group –instance-id
Following required option
–should-decrement-desired-capacity
–no-should-decrement-desired-capacity
ASG process - Launch
Adds instances to the Auto Scaling group when the group scales out, or when Amazon EC2 Auto Scaling chooses to launch instances for other reasons, such as when it adds instances to a warm pool
ASG process - Terminate
Removes instances from the Auto Scaling group when the group scales in, or when Amazon EC2 Auto Scaling chooses to terminate instances for other reasons, such as when an instance is terminated for exceeding its maximum lifetime duration or failing a health check.
ASG process - AddToLoadBalancer
Adds instances to the attached load balancer target group or Classic Load Balancer when they are launched. For more information, see Use Elastic Load Balancing to distribute traffic across the instances in your Auto Scaling group.
ASG process - AlarmNotification
Accepts notifications from CloudWatch alarms that are associated with dynamic scaling policies. For more information, see Dynamic scaling for Amazon EC2 Auto Scaling.
ASG process - AZRebalance
Balances the number of EC2 instances in the group evenly across all of the specified Availability Zones when the group becomes unbalanced, for example, when a previously unavailable Availability Zone returns to a healthy state. For more information, see Rebalancing activities.
ASG process - HealthCheck
Checks the health of the instances and marks an instance as unhealthy if Amazon EC2 or Elastic Load Balancing tells Amazon EC2 Auto Scaling that the instance is unhealthy. This process can override the health status of an instance that you set manually. For more information, see Health checks for Auto Scaling instances.
ASG process - InstanceRefresh
Terminates and replaces instances using the instance refresh feature. For more information, see Replace Auto Scaling instances based on an instance refresh.
ASG process - ReplaceUnhealthy
Terminates instances that are marked as unhealthy and then creates new instances to replace them. For more information, see Health checks for Auto Scaling instances.
ASG process - ScheduledActions
Performs the scheduled scaling actions that you create or that are created for you when you create an AWS Auto Scaling scaling plan and turn on predictive scaling. For more information, see Scheduled scaling for Amazon EC2 Auto Scaling.
Scenario 1: Launch is suspended
AlarmNotification is still active, but your Auto Scaling group can’t initiate scale-out activities for alarms that are in breach.
ScheduledActions is active, but your Auto Scaling group can’t initiate scale-out activities for any scheduled actions that occur.
AZRebalance stops rebalancing the group.
ReplaceUnhealthy continues to terminate unhealthy instances, but does not launch replacements. When you resume the Launch process, Amazon EC2 Auto Scaling immediately replaces any instances that it terminated during the time that Launch was suspended.
InstanceRefresh does not replace instances.
Scenario 2: Terminate is suspended
AlarmNotification is still active, but your Auto Scaling group can’t initiate scale-in activities for alarms that are in breach.
ScheduledActions is active, but your Auto Scaling group can’t initiate scale-in activities for any scheduled actions that occur.
AZRebalance is still active but does not function properly. It can launch new instances without terminating the old ones. This could cause your Auto Scaling group to grow up to 10 percent larger than its maximum size, because this is allowed temporarily during rebalancing activities.
Your Auto Scaling group could remain above its maximum size until you resume the Terminate process.
ReplaceUnhealthy is inactive but not HealthCheck. When Terminate resumes, the ReplaceUnhealthy process immediately starts running. If any instances were marked as unhealthy while Terminate was suspended, they are immediately replaced.
InstanceRefresh does not replace instances.
Scenario 3: AddToLoadBalancer is suspended
Amazon EC2 Auto Scaling launches the instances but does not add them to the load balancer target group or Classic Load Balancer. When you resume the AddToLoadBalancer process, it resumes adding instances to the load balancer when they are launched. However, it does not add the instances that were launched while this process was suspended. You must register those instances manually.
