# AWS Organizations AWS Organizations is an Amazon Web Services service for centrally governing and managing AWS resources across multiple accounts and services. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Introducing self-managed Amazon S3 buckets for AWS Lambda function code DevFeed: [Introducing self-managed Amazon S3 buckets for AWS Lambda function code]() Original publisher: [Read original article]() Author: Doug Perkes Published: 2026-07-17T10:49:14Z Content type: release Language: en Sources: [AWS Compute Blog]() Topics: [AWS Lambda](), [Amazon S3](), [Deployment](), [Security](), [Replication](), [CI/CD](), [AWS Organizations]() Tags: [amazon-s3](), [amazon-simple-storage-service-s3](), [audit-trail](), [aws](), [aws-lambda](), [aws-organizations](), [ci-cd](), [compliance](), [deployment](), [disaster-recovery](), [encryption](), [replication](), [security](), [uncategorized]() ### AI overview AWS Lambda now supports self-managed Amazon S3 buckets for function deployment packages. Lambda reads code directly from the customer-controlled bucket, removing deployment-package copies from the Lambda code storage quota and giving teams control over encryption, access policies, compliance, lifecycle management, audit trails, and cross-Region replication. ### Source excerpt If you manage Lambda functions at scale, you've likely hit the 75 GB code storage limit or explained to your security team why deployment artifacts live in an S3 bucket you don't control. Today, we're announcing self-managed Amazon S3 buckets for AWS Lambda deployment packages. Lambda reads your code directly from your bucket, eliminating quota [...] ## A Story of Delayed AWS Pipelines DevFeed: [A Story of Delayed AWS Pipelines]() Original publisher: [Read original article]() Author: Vladimir Romashov Published: 2026-05-08T14:23:22Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [Amazon Web Services](), [Terraform](), [AWS Organizations](), [Infrastructure as code](), [CI/CD](), [Security]() Tags: [aws](), [aws-organizations](), [booking](), [ci-cd](), [ci-cd-pipeline](), [infrastructure-as-code](), [pii](), [terraform]() ### AI overview The article investigates delays in Terraform CI/CD pipelines caused by repeated use of the aws_organizations_organization data source and interactions with the AWS Organizations API. Testing found that roughly 1 in 10 Terraform pipelines were affected, with delays ranging from 1 to 15 minutes, while comparable CDK pipelines were not delayed. ### Source excerpt How a seemingly simple AWS API call can silently slow down your CI/CD pipelines Review/co-researcher: Gonzalo Ulla The Mystery It started with a line in one of our team's CI/CD logs that nobody expected: module.project.module.user_buckets.module.s3_bucket.data.aws_organizations_organization.current: Still reading... [15m10s elapsed] 15 minutes and 10 seconds -- just to read organization data. A value that should return in milliseconds was holding up entire pipelines. After digging deeper, we discovered this wasn't a one-off issue. During testing, roughly 1 in 10 pipelines containing Terraform were affected, with delays ranging from 1 to 15 minutes each. At Booking.com, we deploy and manage our AWS infrastructure using two primary Infrastructure as Code (IaC) technologies: Terraform and AWS Cloud Development Kit (CDK). To standardize and enforce our compliance and security controls, we maintain a set of internal Terraform and CDK modules to provision resources that handle personally identifiable information (PII). Interestingly, only Terraform pipelines were affected by this issue -- CDK ones running in the same accounts and against the same AWS Organization were completed without any delays. [spoiler alert/] CDK uses CloudFormation under the hood, which doesn't make additional Organizations API calls directly. [/spoiler alert]. This ruled out a general AWS-side outage or account-level throttling and pointed us toward something specific to how Terraform interacts with the Organizations API. This is the story of how we tracked down the root cause -- and why the fix isn't as simple as you'd think. What is aws_organizations_organization? Terraform's aws_organizations_organization data source retrieves information about, guess what, your AWS Organization. On the surface, it maps to the AWS DescribeOrganization API call -- a flat request. No iteration. No pagination. Simple... Or so we thought. The First Clue: Reproducing the Issue The references to the Organizations API mostly c ## Automating Multi-Account Permission Management with AWS IAM Identity Center (previously AWS SSO) DevFeed: [Automating Multi-Account Permission Management with AWS IAM Identity Center (previously AWS SSO)]() Original publisher: [Read original article]() Author: Niko Jernejsek Published: 2022-12-22T10:32:09Z Content type: article Language: en Sources: [Homegate Engineering Blog - Medium]() Topics: [AWS IAM Identity Center](), [AWS Organizations](), [Single sign-on (SSO)](), [Authorization](), [IAM](), [CI/CD]() Tags: [aws](), [aws-eventbridge](), [aws-iam](), [aws-iam-identity-center](), [aws-organizations](), [cicd](), [cloudformation](), [iam-identity-center](), [least-privilege](), [saml](), [security](), [sso]() ### AI overview This article describes Homegate's multi-account AWS strategy and its use of AWS IAM Identity Center, formerly AWS SSO, to centrally manage permissions for engineers across AWS accounts. It explains the use of permission matrices, least-privilege access, AWS Organizations, external identity providers through SAML 2.0, and SCIM. ### Source excerpt Background Homegate was founded in 2001 and is now the leading property marketplace in Switzerland. Few years ago we decided to re-architect our monolithic real estate platform towards micro services on top of AWS cloud. At the moment, Homegate workloads are running almost exclusively on server-less compute model with teams organised around micro services. We are utilising so called multi-account strategy where we structure our AWS accounts around individual micro services further breaking them down into different accounts according to software lifecycle, and organising them into the AWS Organizational Units. We've structured our AWS Organizations Units & AWS accounts according to the recommendations provided by AWS (https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html#basic-organization-with-cicd-as-a-separate-function). Apart from having product workload accounts we also have accounts which are necessary to operate security, governance and platform related workloads. Access to accounts is governed by a permission matrix which is based on least privilege principles. The permission matrix classifies who (internally defined personas, e.g.: engineers/managers/security officers, etc) has what type of access (e.g. read-only or admin), and to what category of AWS accounts (e.g. production workloads, shared infra accounts, etc). Group of accounts in our Permission Matrix are at the same time AWS Organisational Units that we implement. As we have to manage permissions for hundreds of engineers to about hundred of AWS accounts accordingly, this way of grouping makes it easier for us to manage it at scale. IAM Identity Center PrimerIAM Identity Center Intro Note that I will be using AWS IAM Identity Center and AWS SSO interchangeably as even some services (such as CloudFormation) are still using the previous name AWS SSO. AWS IAM Identity Center is a single sign-on (SSO) service that allows AWS users to centrally manage acces