DEV Community: Shuichi Takahashi

Using Permission Boundaries for IAM Role Creation in AWS Organizations Management Account

Shuichi Takahashi — Tue, 30 Sep 2025 14:18:06 +0000

In AWS Organizations, the "management account" is a special account.
It owns all organizational settings and has powerful permissions.
By default, it can register and remove accounts from the organization, handle billing, and manage organization-wide settings.

Reference: AWS Organizations Management Account

Therefore, it is a best practice to limit management account access to a small number of people and delegate functions and operations whenever possible.
The functions that can be delegated are listed in the AWS Services integrated with Organizations documentation.
Functions with "Supports delegated administrator" set to "Yes" can be delegated to specified member accounts.

Reference: AWS Services Integrated with Organizations

Additionally, the management account is not subject to control policies such as SCPs, making it difficult to restrict.

Reference: Service Control Policies (SCP)

For cases where you cannot delegate everything and need to give access to the management account, you can use methods like assigning roles with limited permissions through IAM Identity Center.

Reference: AWS IAM Identity Center

The problem occurs when developers need to create IAM roles.
For example, they want to deploy a Lambda function or setup serverless infrastructure.
There are several ways to handle this. This article explains one approach: Permission Boundaries.

The Challenge: When Allowing iam:CreateRole

When you give someone iam:CreateRole permission, it looks reasonable.
However, there is a problem: they can create roles with much more permissions than they have.

When these IAM roles are used, the intended permission control becomes ineffective.

Why Permission Boundary Matters in Management Account

Management account has a difficult situation. Developers need to create IAM roles for their applications, but SCPs cannot help - they don't work on management accounts.

Here is an example: a development team wants to deploy a Lambda that reads from S3. They request iam:CreateRole permission.

The escalation pattern:

Developer creates role with s3:GetObject (intended behavior)
Developer needs CloudWatch logs, adds logs:CreateLogGroup
Still getting errors, changes to logs:*
More problems occur, adds *:* temporarily
Six months later, that temporary role with full permissions is still in production

This escalation pattern happens frequently. Developers focus on making their application work rather than security boundaries.

Permission Boundary acts like a chain that restricts IAM entities. No matter what permissions you try to attach, you cannot break free from the boundary's constraints.

Important point: Setting the boundary is not enough. If users can remove it, the security is gone. You must block iam:DeleteRolePermissionsBoundary and iam:PutRolePermissionsBoundary actions.

Operational Reality: Developers initially resist the additional complexity. However, when they understand it enables self-service IAM role creation without security team approval, adoption improves. Self-service approach is more efficient than ticket-based processes.

Debugging Complexity: When permissions fail, troubleshooting becomes harder because you must check both identity-based policies AND Permission Boundaries. Invest in logging and documentation upfront.

Reference: IAM Permissions Boundaries

Implementing Permission Boundary Control

When you want to grant IAM role creation permissions but prevent users from creating roles with excessive permissions, you can use Permission Boundaries for control. By setting a policy that explicitly denies unwanted operations as a Permission Boundary and forcing the application of this Permission Boundary when creating IAM roles, you can control the upper limit of permissions.

Enforcing Permission Boundary Inheritance

A critical challenge emerges when roles create other roles: how do you ensure that "child" and "grandchild" roles maintain the same constraints? Permission Boundaries don't automatically inherit, but you can enforce inheritance through policy design.

The Solution: Self-Referencing Permission Boundary

The key insight is to make the Permission Boundary policy reference itself. Include this condition in your baseline_policy Permission Boundary:

{
  "Effect": "Deny",
  "Action": [
    "iam:CreateUser",
    "iam:CreateRole"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT-ID:policy/baseline_policy"
    }
  }
}

Why Self-Reference Works:

The baseline_policy enforces that new roles must have the same Permission Boundary attached. This creates a chain where all created roles inherit the same constraints.

How Self-Reference Creates the Chain:

Parent Role has baseline_policy as its Permission Boundary
Parent Role attempts to create a new role
The baseline_policy denies the creation unless the new role also gets baseline_policy as its Permission Boundary
Child Role is created with the identical Permission Boundary (baseline_policy)
When Child Role creates another role, the same self-referencing constraint applies
Grandchild Role and all subsequent generations must also have baseline_policy as their Permission Boundary

Chain of Enforcement:

Parent Role (Boundary: baseline_policy)
  ↓ iam:CreateRole (must specify same boundary)
Child Role (Boundary: baseline_policy)
  ↓ iam:CreateRole (must specify same boundary)
Grandchild Role (Boundary: baseline_policy)

Additional Protection:

To prevent boundary removal, also deny these actions:

{
  "Effect": "Deny",
  "Action": [
    "iam:DeleteRolePermissionsBoundary",
    "iam:PutRolePermissionsBoundary"
  ],
  "Resource": "*"
}

This approach ensures that regardless of how many generations of roles are created, they all maintain the same constraints. This prevents privilege escalation problems.

Alternative Approaches

For permission control in management account, there are other methods besides Permission Boundary:

Data Migration: When data in the management account is needed, share or copy only the necessary parts of that data to member accounts and build solutions in the member accounts
Work Separation: Have administrators or CI/CD pipelines handle IAM role creation and deployment work, and give general users only execution permissions

Considerations for Permission Boundary Usage

Permission Boundaries can be used not only in management account but also in member accounts. However, they add operational complexity. Before implementation, evaluate whether the security benefits justify the operational overhead:

Operational Complexity: Permission Boundaries add an additional layer of policy evaluation, which can make troubleshooting permission issues more complex
Development Velocity: Strict boundaries may slow down development workflows, especially in environments requiring frequent role modifications
Maintenance Overhead: Permission Boundary policies need to be maintained and updated as business requirements evolve
User Experience: Developers may encounter unexpected permission denials, requiring additional training and documentation

Before implementing Permission Boundaries, ensure your team can manage the additional complexity and that the security benefits are significant for your use case.

Reference Links

AWS Organizations and IAM Related

AWS Well-Architected Related

SEC03-BP02: Grant Least Privilege Access
- >For example, you can allow your workload teams to create their own IAM policies for systems they build, but only if they apply a Permission Boundary to limit the maximum permissions they can grant.
SEC01-BP01: Separate Workloads Using Accounts
Security Pillar - AWS Well-Architected Framework

AWS Cost Categories with OU Structure

Shuichi Takahashi — Sat, 29 Mar 2025 20:48:31 +0000

Introduction

AWS Cost Categories help organize cloud spending by mapping costs to your business structure using rules. You can define rules based on accounts, tags, services, and more. See the official documentation for details.

This article explores an approach to automatically align AWS Cost Categories with your AWS Organizations Organizational Unit (OU) structure. We'll look at the reasoning behind this method and demonstrate how to implement it using a sample Python script.

Also available in Japanese: An enhanced Japanese version of this article with additional content is available here.

Considerations

Important Security Note

This script is a sample. Test thoroughly before use in production.
It requires execution in the Management Account to access necessary Organizations and Cost Explorer APIs.
Use Least Privilege: The Management Account is critical. Do not run scripts with administrative privileges. Create a dedicated IAM role with only the minimum required permissions (see README) and use that role for execution (e.g., in CloudShell, EC2, Lambda).

Approach Details

Automation Need: OU structures change. Manual Cost Category updates are impractical. This script automates synchronization.
Implementation: Cost Category rules cannot directly target OUs. This script uses the following logic:
1. List all accounts via ListAccounts.
2. For each account, find its OU path using ListParents.
3. Assign the account to a category name derived from its OU path up to a specified depth (e.g., OU1-OU1A). Each account belongs only to its deepest relevant category.
4. Generate Cost Category rules mapping the category name (Value) to the list of associated account IDs (Dimensions).
Execution: Uses Python3.x/Boto3 Assumes execution from an environment like AWS CloudShell. Can be adapted for scheduled Lambda execution (requires changes for parameter input and considering execution limits).

Script Features

Hierarchical Categories: Creates names like Level1OU-Level2OU-....
Depth Control: A depth argument sets the granularity.

The Script

The complete Python script is available on GitHub.

Repository:
https://github.com/shu85t/PutOuCostCategory

Prerequisites

Python: Version 3.9 or later.
Boto3: AWS SDK for Python (pip install boto3). Ensure you are using a recent version.
AWS Account: Access to the Management Account of your AWS Organization.

Execution Environment

This script needs to run in an environment with credentials for the Management Account of your AWS Organization, possessing the necessary IAM permissions (see below).
A primary intended environment is AWS CloudShell accessed while logged into the Management Account.
It can also run on an EC2 instance or in an AWS Lambda function within the Management Account, provided the execution role has the required permissions.

Usage

Command Line Execution

python3 put_ou_cost_category.py <CostCategoryName> <EffectiveStartMonth> <Depth>

Arguments

<CostCategoryName> (Required): The name of the Cost Category to create or update (e.g., OrganizationStructure, OUHierarchy).
<EffectiveStartMonth> (Required): The effective start month in YYYY-MM format (e.g., 2025-04). The script uses the first day of this month (UTC midnight) for the API call.
<Depth> (Required): An integer (1 or greater) specifying the maximum depth of the OU hierarchy to create categories for.
- 1: Creates categories for Root and first-level OUs.
- 2: Creates categories for Root, first-level OUs, and second-level OUs (e.g., OU1-OU1A).
- Accounts are always assigned to their deepest category up to the specified depth.

Log Level Configuration

Control logging verbosity using the LOG_LEVEL environment variable. Default is INFO.

# Example: Run with DEBUG logs
export LOG_LEVEL=DEBUG
python3 put_ou_cost_category.py MyOUCategory 2025-04 2

# Or temporarily for one command
LOG_LEVEL=DEBUG python3 put_ou_cost_category.py MyOUCategory 2025-04 2

IAM Permissions

The IAM principal (user or role) running this script needs the following permissions:

Required Actions:

organizations:ListAccounts
organizations:ListParents
organizations:DescribeOrganizationalUnit
organizations:ListRoots
ce:ListCostCategoryDefinitions
ce:CreateCostCategoryDefinition
ce:UpdateCostCategoryDefinition

Example Results

Here's how it works with a sample OU structure.

Sample OU Structure

Root
├── Management Account
│
├── Management OU
│   ├── Management Tool Account1
│   └── Management Tool Account2
│
├── Sandbox OU (No direct accounts)
│
├── Security OU
│   ├── Audit Account
│   └── Log Archive Account
│
└── SDLC OU
    ├── Dev OU
    │   └── Workload Dev Account
    └── Stg OU
        └── Workload Staging Account

Result with `depth=1`

Command:

python3 put_ou_cost_category.py OUStructure 2025-01 1

Result:

Result with `depth=2`

Command:

python3 put_ou_cost_category.py OUStructure 2025-01 2

Result:

How the Script Works

Get organization structure

https://github.com/shu85t/PutOuCostCategory/blob/1d1189ddf8db469ecc4ac99a24c5ae31b88a9464/put_ou_cost_category.py#L82-L136

# --- Core Functions ---
def get_organization_structure(max_depth):
    """ Retrieves Org structure assigning accounts to deepest category up to max_depth. Returns dict or None. Propagates exceptions. """
    logger.info(f"Fetching organization structure (assigning accounts to deepest path up to depth {max_depth})...")
...

It starts by listing all accounts using list_accounts.
For each account, it traces the full path of parent OUs back to the Root using the list_parents API.
It retrieves OU names using describe_organizational_unit (names are cached locally via get_ou_name to improve efficiency).
Based on the OU path and the provided max_depth, it constructs the final category name (e.g., L1OU-L2OU).
Crucially, each account is assigned uniquely to the single category representing its deepest OU placement within the depth limit.
Finally, it returns a Python dictionary where keys are the generated category names and values are lists of the corresponding account IDs.

Build cost category rules

https://github.com/shu85t/PutOuCostCategory/blob/1d1189ddf8db469ecc4ac99a24c5ae31b88a9464/put_ou_cost_category.py#L138-L155

def build_cost_category_rules(org_structure):
    """ Builds rule list. Skips categories with empty accounts. Propagates exceptions. """
    logger.info("Building Cost Category rules...")
...

It takes the input dictionary (mapping category names to account lists) and translates each category with accounts into a rule object formatted for the API.
Returns a list containing only the rules generated for categories that actually have assigned accounts.

Put cost category

https://github.com/shu85t/PutOuCostCategory/blob/1d1189ddf8db469ecc4ac99a24c5ae31b88a9464/put_ou_cost_category.py#L181-L227

def put_cost_category(cost_category_name, rules, default_value, effective_start_iso_str):
    """ Creates/Updates Cost Category. Returns True on success. Raises exceptions on failure. Logs raw parameters. """

It first checks if a Cost Category with the specified cost_category_name already exists using find_cost_category_arn. Based on the result, it prepares the necessary parameters for either the create_cost_category_definition or update_cost_category_definition API call.
Before calling the API, it performs pre-checks on the number of rules and accounts per rule against documented limits.
If validation passes, it executes the appropriate API call (create or update) to apply the changes in AWS.

Refelence

This time, I wrote the code in Python and am using boto3. Since APIs are defined for each service [within boto3], I'm including a link to the SDK documentation for reference.

Boto3(Python SDK)
- Organizations Client
- CostExplorer Client

As a side note, taking the time to carefully read through the API's defined arguments and responses – even the ones you don't end up using – is very helpful for understanding the AWS service itself, its behavior, and its various options.

Conclusion

This script offers a method to automatically align AWS Cost Categories with your AWS Organizations OU structure.

This provides a useful perspective for cost analysis, allowing you to understand costs based on the OU level categorization of accounts.

Using this OU structure categorization, I noticed some unexpected costs in one area. After investigating, I identified an OpenSearch instance that could likely be optimized to reduce costs.

Sharing an AWS Well-Architected workload

Shuichi Takahashi — Mon, 30 Sep 2024 14:23:56 +0000

The Well-Architected Tool provides a feature to share resources.
You can share "Workloads," "Lenses," "Profiles," and "Templates."
You can specify "IAM users," "AWS accounts," "Organizations," or "Organizational Units (OUs)" as the recipients of the share.

This post will examine the behavior and limitations of sharing workloads.

Can you share with a different organization? Can you restrict permissions for sharing? Let's investigate these questions.

How to Share

Management Console

You can share from the Workloads tab by selecting "Create" under the Shares section.

AWS CLI

You can share using the wellarchitected create-workload-share.
API specifications are here.

aws wellarchitected create-workload-share \
--workload-id <value> \
--shared-with <value> \
--permission-type <value>

Share Recipients

Sharing with IAM Users

The shared workload can be accessed, and the invitation is accepted only when the specified user is logged in. The specified user can belong to a different organization from the sharing source.

Sharing via Management Console

Enter the IAM user ARN in the Principal field.

Sharing via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with arn:aws:iam::123456789012:user/username  \
--permission-type READONLY

Specify the workload-id as the 32-character ID following workload/ in the workload's ARN.

Sharing with an AWS Account

Users with the appropriate permissions in the specified account can accept the invitation and access the shared workload. The specified account can belong to a different organization from the sharing source.

Sharing via Management Console

Enter the 12-digit AWS account ID.

Sharing via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with 123456789012  \
--permission-type READONLY

Sharing with an Organization

You can share within the Organization to which the sharing source belongs.
No invitation approval is required. Once shared, workloads can be accessed from accounts within the Organization.

Sharing via Management Console

The ID of the Organization to which the sharing source belongs is pre-filled and cannot be changed.

Sharing via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with o-123456789a  \
--permission-type READONLY

Suppose you specify an Organization ID other than the one you belong to. In that case, the operation will fail with the error message: "The shared with principal can only be shared to an organization that you belong to."

Sharing with an Organizational Unit (OU)

You can share with an Organizational Unit (OU) within the Organization to which the sharing source belongs.
No invitation approval is required. Once shared, workloads can be accessed from accounts within the specified OU.

Sharing via Management Console

Enter the ID of the OU.

If you enter the ID of an OU that belongs to a different Organization, the share will fail with the message: "Failed: Unable to fetch organization details."

Sharing via AWS CLI

aws wellarchitected create-workload-share  \
--workload-id 0123456789abcdef0123456789abcdef  \
--shared-with ou-1234-abcdefgh  \
--permission-type READONLY

Permissions

The permission required to share a workload is "wellarchitected:CreateWorkloadShare".

Workloads may contain sensitive information such as the workload name, description, and review notes. In certain scenarios, you may not want to accidentally share this information outside the organization, or even within the organization to unintended OUs or accounts.

Can you restrict the recipients of the share?

No, you cannot. The Principal refers to the requester, so conditions such as aws:PrincipalOrgID or aws:PrincipalOrgPaths cannot restrict recipients. To implement such a control, you may need to create custom rules in AWS Config to detect these settings.

Use Case

Establishing mechanisms, standardization, culture, and rules at the organizational level, not just for individual projects, is often necessary to adhere to AWS Well-Architected best practices. By viewing, aggregating, and analyzing workload review reports across the Organization, you can identify areas where standardization and mechanisms are lacking and weaknesses in the Organization.

Check Include workloads shared with me on the dashboard to include shared workloads in the analysis.

Our Approach to AWS Well-Architected Best Practices

Shuichi Takahashi — Sun, 30 Jun 2024 14:08:37 +0000

What is Well-Architected?

The Well-Architected framework, a comprehensive compilation of 'best practices' for cloud architecture, is created by AWS.
https://aws.amazon.com/architecture/well-architected

Based on this review, you can identify risks that are not in line with best practices.

Impressions from Conducting Reviews

Meeting best practices involves not only workload-specific design, implementation, and operation but also organizational structure, rules, and training.

We have been working with a cross-departmental team called the "Well-Architected Working Group" for several years, and I have compiled a rough diagram of our activities.

Diagram of AWS Well-Architected Utilization Status Across Our Company

I will pick a few examples from the diagram and introduce them.

Well-Architected Working Group

The working group comprises one or more members selected from each target department.

Having members from various departments helps us understand the different circumstances and situations during our meetings.

Reading and Discussing Best Practices

The descriptions of best practices become more transparent and easier to understand each year. Still, some items are difficult to interpret in concrete terms. Establish internal guidelines to determine the acceptable extent and interpretation of best practices.

These discussions also provide feedback on cheat sheets, internal standards and templates, internal training, and internal systems as necessary.

Mini BootCamp

The Well-Architected BootCamp is a workshop where you can learn to apply best practices.

Teams will discuss and present their results on applying best practices to virtual systems and business situations.

The Mini BootCamp is our in-house version of this workshop. Below is a participation report from one of these sessions.
https://iret.media/tag/aws-well-architected-mini-bootcamp

Motivation

If reviewing becomes the main objective, it can distract from the essence. Therefore, I would like to use the AWS best practices positively to ensure quality and improve efficiency!

Easy Chaos Engineering with AWS Organizations SCP

Shuichi Takahashi — Thu, 28 Mar 2024 04:16:15 +0000

I have attached a permission-robbing SCP to an experiment OU, moved the target account to that OU, and observed its behavior.

What is AWS Organizations?

AWS Organizations is an account management service that enables you to consolidate multiple AWS accounts into an "organization."AWS Organizations makes it very useful for managing multiple accounts.
You can integrate and control supported AWS services to accounts that are members of an organization.

Chaos with SCP

Simulate the behavior of AWS services failure on a target workload.
Attach a permission-robbing SCP to an experimental OU, move accounts into it, and observe workload behavior.

Target workload

I set the In-house email notification integrated system as the target workload this time.

The rough architecture.

permission-robbing SCP

Set the following policies for SCP

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Deny",
      "Action": [
        "SNS:*",
        "SES:*",
        "S3:*",
        "Lambda:*",
        "Dynamodb:*",
        "SQS:*"
      ],
      "Resource": "*"
    }
  ]
}

Let's take a guess

What would be the behavior if I moved a workload account to an OU with a permission-robbing SCP attached?

What part of the architecture would fail?

Experimental outcome

I sent an email that this workload should notify Slack.
However, the email has not been sent to Slack.

I found that the (3)Converter failed when it was going to read the email data.

[ERROR] ClientError: An error occurred (AccessDenied) when calling the GetObject operation: Access Denied Traceback (most recent call last):

(1) SES -> (2) SNS -> (3) Lambda calls are connected by events and do not use IAM role access, so they worked correctly.

After that, the Lambda in (3) read email data from S3 using IAM role access, so it failed here. (Got failed by Deny "S3:*")

Incidentally, I checked the Lambda function from the management console, but it displayed "~with an explicit deny in a service control policy," I could not see the function. It is because "Lambda:*" is denied.

It reminded me that if the service fails, I may not be able to check the status of that service resource either.

Conclusion

I have tried easy chaos engineering with AWS Organizations SCP.

Good points of this method

Easy to start, easy to clean up

If it is through an IAM role, you can simulate, to some extent, the failure to be able to access a specific service.

Bad points of this method

SCP with strong restrictions will be attached, and a mistake can cause an accident.
However, limiting the account IDs allowed by the "Organizations:MoveAccount" permission may reduce the incident risk.

Only IAM users and IAM roles can be deny by SCP, so the situations that can be simulated are limited.

At the end

Can I detect the failure? Can I identify the cause?
I thought "Easy Chaos Engineering with AWS Organizations SCP" would be a good starting point for checking.

This post is an English rewrite of a post I wrote in Japanese.

Visualize CloudWatch Logs ingestion lag with Logs Insights

Shuichi Takahashi — Sun, 25 Jun 2023 18:35:14 +0000

I have visualized the lag time it takes to ingest logs to CloudWatch Logs and compared it by source service!

0. "timestamp" and "ingestionTime"

CloudWatch Logs event includes the following two times.

(i) timestamp = The time the event occurred
(ii) ingestionTime =The time the event was ingested into CloudWatch Logs

There is a lag between "timestamp" and "ingestionTime".

The "timestamp" (=event occurrence time) is passed by the parameter InputLogEvent of PutLogEvents.
This is something we're rarely aware of if we're using an integrated service or CloudWatch agent

1. Visualize CloudWatch Logs ingestion lag

We can get both from the log data in Logs Insights, so we will aggregate them using the stats command.

1-1. Query the "timestamp" and "ingestionTime"

The initial query of Logs Insights only displays timestamp, but let's display ingestionTime as well

fields @timestamp, @ingestionTime, @message, @logStream, @log
| sort @timestamp desc

Result

You can see that there is a time lag of several seconds.

1-2. Query the time difference(=lag)

fields @timestamp, @ingestionTime, toMillis(@ingestionTime) - toMillis(@timestamp) as diff
| sort @timestamp desc

Result

toMillis(@ingestionTime) - toMillis(@timestamp) as diff

"toMillis" function converts the timestamp found in the named field into a number representing the milliseconds.

1-3. Visualize the time difference(=lag) with stats

fields @timestamp, @ingestionTime, toMillis(@ingestionTime) - toMillis(@timestamp) as diff
| sort @timestamp desc
| stats max(diff), pct(diff,50), avg(diff) by bin(30min)

The maximum, median (50th percentile), and mean of the difference are output at 30-minute intervals. The period is specified as 2 weeks.
The maximum number of log fields that Logs Insights can output is 1,000, so the interval and period must be adjusted accordingly.

Results

2 Comparison of lag by source service

Let's run a visualization query to see if the time difference differs depending on the log source!

2-1. AWS Lambda

AWS Lambda is integrated with CloudWatch and automatically outputs logs with appropriate permissions, so we query the group. (/aws/lambda/{function name})

The median time is about less than 9 seconds.

2-2. EC2 + CloudWatch Agent

Query the log group that EC2 is outputting via CloudWatch Agent.

The median is a little over 5 seconds, but the maximum is around 16 seconds.
It may depend on the contents of the agent configuration file (per force_flush_interval?)

2-3. API Gateway

Query the log group that is output when log output is enabled on API Gateway.
(API-Gateway-Execution-Logs_{stage ID})

The median time is over 20 seconds, the longest among those compared.

Conclusion

There were differences in lagging tendencies among the services. It would be fun to try to guess the cause.

I used Logs Insights to visualize the data, and found it easy and useful.

This post is an English rewrite of an post I wrote in Japanese.

Python script to list unused IP addresses in AWS VPC Subnet

Shuichi Takahashi — Thu, 31 Mar 2022 14:19:23 +0000

I wrote a Python script to list unused IP addresses (IPv4) in a subnet.

I have used Henry's post as a reference, thanks.

Mechanism

Get the CIDR of specified subnet by DescribeSubnets
Get the used private IP addresses in specified subnet by DescribeNetworkInterfaces = Used IP addresses
Calculate the Unused IP addresses = "CIDR IP addresses" - "Used IP addresses" - "Reserved IP Addresses"

note

I used ipaddress module to calculate IP addresses within the CIDR.
I used "PrivateIpAddresses array" instead of "PrivateIpAddress" to extract both primary and secondary addresses from the NetworkInterface response.
Reserved IP addresses are described in official documentation

For example, if you create a VPC with CIDR block 10.0.0.0/24, it supports 256 IP addresses. You can break this CIDR block into two subnets, each supporting 128 IP addresses. One subnet uses CIDR block 10.0.0.0/25 (for addresses 10.0.0.0 - 10.0.0.127) and the other uses CIDR block 10.0.0.128/25 (for addresses 10.0.0.128 - 10.0.0.255).

Python script

https://github.com/shu85t/aws_describe_unused_ips

Requirements

>Python3.8
boto3
AWS Permissions
- ec2:DescribeSubnets
- ec2:DescribeNetworkInterfaces

Usage

export AWS_DEFAULT_REGION={region name}
export AWS_DEFAULT_PROFILE={aws profile name}
python describe_unused_ips.py {subnet-id}

export AWS_DEFAULT_REGION=ap-northeast-1
export AWS_DEFAULT_PROFILE=my_aws_account
python describe_unused_ips.py subnet-000000000000

output

subnet_id='subnet-000000000000' mode='normal'
cidr='10.1.0.0/24'
cidr_ips=['10.1.0.0', '10.1.0.1', '10.1.0.2', '10.1.0.3', '10.1.0.4', ...]
-----------
reserved_ips=['10.1.0.0', '10.1.0.1', '10.1.0.2', '10.1.0.3', '10.1.0.255']
-----------
used_ips=['10.1.0.39']
-----------
unused_ips=['10.1.0.4', '10.1.0.5', '10.1.0.6', ...]
-----------
cidr=10.1.0.0/24 cidr_ips=256 reserved=5 used=1 unused=250

This post is an English rewrite of an post I wrote in Japanese.

How long is your Maximum Line Length for PEP 8?

Shuichi Takahashi — Mon, 06 Sep 2021 01:52:33 +0000

Style Guide

PEP 8 Maximum Line Length

Limit all lines to a maximum of 79 characters.

I used to follow this guide and set the default value to 79 characters in Lint.
However, the readability was sometimes compromised to comply with this, so I decided to reread the guide and tune the setting values.

Some teams strongly prefer a longer line length. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters, provided that comments and docstrings are still wrapped at 72 characters.

The rationale for the 79 characters is described as follows.

Limiting the required editor window width makes it possible to have several files open side by side, and works well when using code review tools that present the two versions in adjacent columns.
The default wrapping in most tools disrupts the visual structure of the code, making it more difficult to understand. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines. Some web based tools may not offer dynamic line wrapping at all.

I see.

Also, in A Foolish Consistency is the Hobgoblin of Little Minds there is a section that says

However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

Note

IDE defaults

VisualStudioCode and PyCharm defaulted to 120 characters per line.

Other Languages

Characters per line - Wikipedia has a good summary.
There are many languages with 80 characters.

Interestingly, they seem to be derived from typewriters and punch cards.

How long is my Maximum Line Length for PEP 8?

So, I changed the Maximum Line Length to 90 for the time being because, in our team's standard editors, about 90 characters can be displayed in the one tree tab + two editor tabs.

It's been a couple of months now, and I'm glad I changed it.

I'm thinking of changing it to 99 characters after seeing how it goes.

Listing of AWS Lambda Python 2.7 functions that will be EOL(across all regions)

Shuichi Takahashi — Mon, 19 Apr 2021 11:29:08 +0000

The official AWS blog posted An announcement titled Announcing end of support for Python 2.7 in AWS Lambda.

In the post, there is an AWS CLI command that lists Python 2.7 Lambda functions.

aws lambda list-functions --function-version ALL --output text --query "Functions[?Runtime=='python2.7'].FunctionArn"

Across all regions

Here is a shell to run its command across all regions.

Script(list-py27functions.sh)

for region in `aws ec2 describe-regions --query "Regions[].RegionName" --region us-west-1 --output text`
do
    echo "[${region}]"
    aws lambda list-functions --region ${region} --output text --query "Functions[?Runtime=='python2.7'].{ARN:FunctionArn, Runtime:Runtime}"
done
echo "finished"

Usage

export AWS_PROFILE=xxxx # Not necessary if you always set the default profile.
sh list-py27functions.sh

Output

[eu-north-1]
[ap-south-1]
[eu-west-3]
[eu-west-2]
[eu-west-1]
[ap-northeast-3]
[ap-northeast-2]
[ap-northeast-1]
arn:aws:lambda:ap-northeast-1:111111111111:function:xxxxx   python2.7
arn:aws:lambda:ap-northeast-1:111111111111:function:yyyyy   python2.7
[ca-central-1]
[ap-east-1]
[ap-southeast-1]
[ap-southeast-2]
[eu-central-1]
[us-east-1]
arn:aws:lambda:us-east-1:111111111111:function:test python2.7
[us-east-2]
[us-west-1]
[us-west-2]
arn:aws:lambda:us-west-2:111111111111:function:zzzz python2.7
finished

You can also run it from within CloudShell without specifying a profile.

Reference

Announcing end of support for Python 2.7 in AWS Lambda
AWS CLI::list-functions
AWS CLI::describe-regions
AWS CLI::Filtering

Search for a keyword across all AWS Lambda functions with zipgrep

Shuichi Takahashi — Wed, 30 Dec 2020 18:09:51 +0000

Liquid syntax error: 'raw' tag was never closed

Listing of all resources in all AWS regions (shell script)

Shuichi Takahashi — Tue, 20 Oct 2020 10:39:42 +0000

This allows you to see the overall resources without having to check for each region and each service.

When you close your AWS Account, it also helps you to see if there are any active resources left over.

if you have any active resources and terminate them before you close your account

Script

get-resources.sh

for region in `aws ec2 describe-regions --query 'Regions[].RegionName' --region us-west-1 --output text`
do
    echo "region = ${region}"
    aws resourcegroupstaggingapi get-resources --region ${region} --query 'ResourceTagMappingList[].ResourceARN';
done

For each region fetched by describe-regions, I use resourcegroupstaggingapi get-resources.
It's OK to do describe-regions at any region, so I've set it to us-west-1.

Prerequisites

aws cli is installed.

Usage

Run

export AWS_PROFILE=xxxx # Not necessary if you always set the default profile.
sh get-resources.sh

Output

region = eu-north-1
[]
region = ap-south-1
[]
region = eu-west-3
[]
region = eu-west-2
[]
region = eu-west-1
[]
region = ap-northeast-2
[]
region = ap-northeast-1
[
    "arn:aws:apigateway:ap-northeast-1::/restapis/〜/stages/devA",
    "arn:aws:apigateway:ap-northeast-1::/restapis/〜/stages/devB",
〜
    "arn:aws:ec2:ap-northeast-1:111111111111:vpc/vpc-1111111a",
    "arn:aws:ec2:ap-northeast-1:111111111111:vpc/vpc-1111111b",
〜
    "arn:aws:lambda:ap-northeast-1:111111111111:function:xxxx-checker",
    "arn:aws:lambda:ap-northeast-1:111111111111:function:xxxx-deleter",
〜
...

Notes

If there is a service that is not supported by the resourcegroupstaggingapi, it will not be listed.

Reference

ec2/describe-regions

https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-regions.html
Used for listing regions

resourcegroupstaggingapi/get-resources

https://docs.aws.amazon.com/cli/latest/reference/resourcegroupstaggingapi/get-resources.html
Used for listing resources

How do I close my AWS account?

https://aws.amazon.com/premiumsupport/knowledge-center/close-aws-account/?nc1=h_ls

Using Secrets Manager or SSM Parameters by both ECS and local machine

Shuichi Takahashi — Wed, 05 Feb 2020 11:34:54 +0000

Goal

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html

Amazon ECS enables you to inject sensitive data into your containers by storing your sensitive data in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store parameters and then referencing them in your container definition. This feature is supported by tasks using both the EC2 and Fargate launch types.

It is useful to inject parameters into containers on ECS.
I also want to use this method for containers on a local machine too.
Because I am often running containers on a local machine when debugging.

How to

Example

Inject parameter named ServiceSettings Into a container on a local machine from Secret Manager or SSM Parameter Store.

Precondition

AWS CLI is installed.

Shell

When using Secret Manager.

setting=`aws secretsmanager get-secret-value --secret-id ServiceSetting --output text --query 'SecretString'`

docker run -it \
    -e  SERVICE_SETTING=$setting \
  ...

The point is to use the "--output text" option.

When using SSM Parameter Store

setting=`aws ssm get-parameter --name ServiceSetting --with-decryption --output text --query Parameter.Value | tr -d ' \n'`

docker run -it \
    -e  SERVICE_SETTING=$setting \
  ...

The point is to use the "tr" to delete spaces and newlines.
And use the "--with-decryption" option when parameters are encrypted.

Result

ECS and a local machine no longer need to change the way environment variables are captured in the application code.

DEV Community: Shuichi Takahashi

Using Permission Boundaries for IAM Role Creation in AWS Organizations Management Account

The Challenge: When Allowing iam:CreateRole

Why Permission Boundary Matters in Management Account

Implementing Permission Boundary Control

Enforcing Permission Boundary Inheritance

Alternative Approaches

Considerations for Permission Boundary Usage

Reference Links

AWS Organizations and IAM Related

AWS Well-Architected Related

AWS Cost Categories with OU Structure

Introduction

Considerations

Important Security Note

Approach Details

Script Features

The Script

Prerequisites

Execution Environment

Usage

Command Line Execution

Arguments

Log Level Configuration

IAM Permissions

Example Results

Sample OU Structure

Result with depth=1

Result with depth=2

How the Script Works

Get organization structure

Build cost category rules

Put cost category

Refelence

Conclusion

Sharing an AWS Well-Architected workload

How to Share

Management Console

AWS CLI

Share Recipients

Sharing with IAM Users

Sharing via Management Console

Sharing via AWS CLI

Sharing with an AWS Account

Sharing via Management Console

Sharing via AWS CLI

Sharing with an Organization

Sharing via Management Console

Sharing via AWS CLI

Sharing with an Organizational Unit (OU)

Sharing via Management Console

Sharing via AWS CLI

Permissions

Can you restrict the recipients of the share?

Use Case

Our Approach to AWS Well-Architected Best Practices

What is Well-Architected?

Impressions from Conducting Reviews

Diagram of AWS Well-Architected Utilization Status Across Our Company

Well-Architected Working Group

Reading and Discussing Best Practices

Mini BootCamp

Motivation

Easy Chaos Engineering with AWS Organizations SCP

What is AWS Organizations?

Chaos with SCP

Target workload

permission-robbing SCP

Let's take a guess

Experimental outcome

Conclusion

Good points of this method

Bad points of this method

At the end

Visualize CloudWatch Logs ingestion lag with Logs Insights

0. "timestamp" and "ingestionTime"

1. Visualize CloudWatch Logs ingestion lag

1-1. Query the "timestamp" and "ingestionTime"

Result

1-2. Query the time difference(=lag)

Result with `depth=1`

Result with `depth=2`