Share an AMI With Organizations and Organizational Units

By Ashwin Venugopal -

 





About

AWS Organizations is a service for managing accounts that allows you to group various AWS accounts into an organization that you establish and oversee from one central location. You have the ability to share an AMI with an organization or a specific Organizational Unit (OU) you've created, in addition to sharing it with particular accounts.

A organization is a structure you establish to unify and manage your AWS accounts from a central location. You can arrange the accounts in a hierarchical, tree-like format, with a root node at the top and organizational units positioned beneath the organization root. Each account can either be added directly to the root or organized into one of the organizational units within the hierarchy.

When you share an AMI with an organization or an OU, all of the children accounts gain access to the AMI.

Considerations

Consider the following when sharing AMIs with specific organizations or organizational units:

  • Ownership- To share an AMI, your AWS account must own the AMI.

  • Sharing limits- The AMI owner can share an AMI with any organization or OU, including organizations and OUs that they’re not a member of.

  • Tags- You can't share user-defined tags (tags that you attach to an AMI). When you share an AMI, your user-defined tags are not available to any AWS account in an organization or OU with which the AMI is shared.

  • ARN format- When you specify an organization or OU in a command, make sure to use the correct ARN format. You'll get an error if you specify only the ID.

  • Encryption and keys- You can share AMIs that are backed by unencrypted and encrypted snapshots.

    • The encrypted snapshots must be encrypted with a customer managed key. You can’t share AMIs that are backed by snapshots that are encrypted with the default AWS managed key.

    • If you share an AMI that is backed by encrypted snapshots, you must allow the organizations or OUs to use the customer managed keys that were used to encrypt the snapshots.

  • Region- AMIs are a resource specific to a Region. When you distribute an AMI, it is accessible only within the Region where it was shared. To make an AMI accessible in another Region, you need to copy it to that Region and then share it.

  • Usage- When you share an AMI, users are permitted to launch instances based on it, but they do not have the ability to delete, share, or alter the original AMI. Nevertheless, once they have initiated an instance from your AMI, they are able to create a new AMI from that launched instance.

  • Billing- You won't incur charges when other AWS accounts utilize your AMI to start instances. Instead, the accounts that initiate instances with the AMI will be responsible for any associated costs.

Get the ARN of an Organization or Organizational Unit

The ARNs for the organization and its organizational unit include the 12-digit number associated with the management account. If you're unsure of the management account number, you can provide details about the organization and the organizational unit to obtain the ARN for each.

Allow Organizations and OUs to Use a KMS Key

To share an AMI backed by encrypted snapshots, you must grant permissions to the organizations or Organizational Units (OUs) to utilize the KMS keys that were employed to encrypt those snapshots. To manage access to the KMS key, you can implement the aws:PrincipalOrgID and aws:PrincipalOrgPaths condition keys in the key policy, allowing only specific principals to have permission for the designated actions. A principal may be a user, IAM role, federated user, or the root user of an AWS account.

The condition keys are used as follows:

  • aws:PrincipalOrgID- Allows any principal belonging to the organization represented by the specified ID.

  • aws:PrincipalOrgPaths- Allows any principal belonging to the OUs represented by the specified paths.

Conclusion

Many aspects about how to share an AMI with organizations and organizational units safely are discussed.
























































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more