Forem: Masaki Okuda

Testing AWS DevOps Agent with Multi-Account

Masaki Okuda — Sun, 01 Mar 2026 13:50:15 +0000

One of the key features of AWS DevOps Agent is multi-account support. In this hands-on article, we'll verify the multi-account functionality and discuss practical considerations for real-world implementation.

Disclaimer

This blog content is based on testing during the preview phase.
The information may change as updates are released.

Target Audience

Those who want to explore AWS DevOps Agent's multi-account functionality
Those who want to understand considerations when testing multi-account setups

Key Takeaways

Fault detection in multi-account configurations is achievable
Multi-account setup itself is straightforward, but practical implementation requires careful consideration
IAM role names and permission management need to be determined before implementing DevOps Agent

About the Test Environment

We'll conduct verification using the test sample code from the AWS DevOps Agent official documentation. (The sample code allows you to test EC2 stress tests and Lambda processing performance)

Creating a Test Environment

The implementation steps are described in the guide, so we'll omit them from this blog.

Note: Since AWS DevOps Agent is in preview, please create resources in the US East (N. Virginia) region

Note: Indentation corrections are required for Test A/Test B YAML files

Test A

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS DevOps Agent EC2 CPU Test Stack'
Parameters:
  MyIP:
    Type: String
    Description: Your current IP address for SSH access (find at https://whatismyipaddress.com)
    Default: '0.0.0.0/0'
Resources:
  # Security Group for SSH access
  TestSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: AWS-DevOpsAgent-test-sg
      GroupDescription: AWS DevOps Agent beta testing security group
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 22
          ToPort: 22
          CidrIp: !Ref MyIP
          Description: SSH access from your IP
      Tags:
        - Key: Name
          Value: AWS-DevOpsAgent-Test-SG
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing
  # Key Pair for SSH access
  TestKeyPair:
    Type: AWS::EC2::KeyPair
    Properties:
      KeyName: AWS-DevOpsAgent-test-key
      KeyType: rsa
      Tags:
        - Key: Name
          Value: AWS-DevOpsAgent-Test-Key
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing
  # EC2 Instance for CPU testing
  TestInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: '{{resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.1-x86_64}}'
      KeyName: !Ref TestKeyPair
      SecurityGroupIds:
        - !Ref TestSecurityGroup
      UserData:
        Fn::Base64:
          !Sub |
          #!/bin/bash
          yum update -y
          yum install -y htop

          # Create the CPU stress test script
          cat > /home/ec2-user/cpu-stress-test.sh << 'EOF'
          #!/bin/bash
          echo "Starting AWS DevOpsAgent CPU Stress Test"
          echo "Time: $(date)"
          echo "Instance: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)"
          echo ""

          # Get number of CPU cores
          CORES=$(nproc)
          echo "CPU Cores: $CORES"
          echo ""

          echo "Starting stress test (5 minutes)..."
          echo "This will generate >70% CPU usage to trigger CloudWatch alarm"
          echo ""

          # Create CPU load using yes command
          echo "Starting CPU load processes..."
          for i in $(seq 1 $CORES); do
              (yes > /dev/null) &
              CPU_PID=$!
              echo "Started CPU load process $i (PID: $CPU_PID)"
              echo $CPU_PID >> /tmp/cpu_test_pids
          done

          # Auto-cleanup after 5 minutes
          (sleep 300 && echo "Stopping CPU load processes..." && kill $(cat /tmp/cpu_test_pids 2>/dev/null) 2>/dev/null && rm -f /tmp/cpu_test_pids) &

          echo ""
          echo "CPU load processes started for 5 minutes"
          echo "Check CloudWatch for alarm trigger in 3-5 minutes"
          EOF

          chmod +x /home/ec2-user/cpu-stress-test.sh
          chown ec2-user:ec2-user /home/ec2-user/cpu-stress-test.sh

          # Create auto-shutdown script (safety mechanism)
          cat > /home/ec2-user/auto-shutdown.sh << 'SHUTDOWN_EOF'
          #!/bin/bash
          echo "Auto-shutdown scheduled for 2 hours from now: $(date)"
          sleep 7200
          echo "Auto-shutdown executing at: $(date)"
          sudo shutdown -h now
          SHUTDOWN_EOF

          chmod +x /home/ec2-user/auto-shutdown.sh
          nohup /home/ec2-user/auto-shutdown.sh > /home/ec2-user/auto-shutdown.log 2>&1 &

          echo "AWS DevOpsAgent test setup completed at $(date)" > /home/ec2-user/setup-complete.txt
      Tags:
        - Key: Name
          Value: AWS-DevOpsAgent-Test-Instance
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing
  # CloudWatch Alarm for CPU utilization
  CPUAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: AWS-DevOpsAgent-EC2-CPU-Test
      AlarmDescription: AWS-DevOpsAgent beta test - EC2 CPU utilization alarm
      MetricName: CPUUtilization
      Namespace: AWS/EC2
      Statistic: Average
      Period: 60
      EvaluationPeriods: 1
      Threshold: 70
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: InstanceId
          Value: !Ref TestInstance
      TreatMissingData: notBreaching
Outputs:
  InstanceId:
    Description: EC2 Instance ID for testing
    Value: !Ref TestInstance

  SecurityGroupId:
    Description: Security Group ID
    Value: !Ref TestSecurityGroup

  AlarmName:
    Description: CloudWatch Alarm Name
    Value: !Ref CPUAlarm

  SSHCommand:
    Description: SSH command to connect to instance
    Value: !Sub 'ssh -i "AWS-DevOpsAgent-test-key.pem" ec2-user@${TestInstance.PublicDnsName}'

Test B

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS DevOpsAgent Lambda Error Test Stack'
Resources:
  # IAM Role for Lambda function
  LambdaExecutionRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: AWS-DevOpsAgentLambdaTestRole
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Tags:
        - Key: Name
          Value: AWS-DevOpsAgent-Lambda-Test-Role
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing
  # Lambda function that generates errors
  TestLambdaFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: AWS-DevOpsAgent-test-lambda
      Runtime: python3.12
      Handler: index.lambda_handler
      Role: !GetAtt LambdaExecutionRole.Arn
      Code:
        ZipFile: |
          import json
          import random
          import time
          from datetime import datetime
          def lambda_handler(event, context):
              print(f"AWS DevOpsAgent Test Lambda - {datetime.now()}")
              print(f"Event: {json.dumps(event)}")

              # Intentionally generate errors for testing
              error_scenarios = [
                  "Simulated database connection timeout",
                  "Test API rate limit exceeded",
                  "Intentional validation error for AWS DevOpsAgent testing"
              ]

              # Always throw an error for testing purposes
              error_message = random.choice(error_scenarios)
              print(f"Generating test error: {error_message}")

              # This will create a Lambda error that CloudWatch will detect
              raise Exception(f"AWS DevOpsAgent Test Error: {error_message}")
      Description: AWS DevOpsAgent beta test function - intentionally generates errors
      Timeout: 30
      Tags:
        - Key: Name
          Value: AWS-DevOpsAgent-Test-Lambda
        - Key: Purpose
          Value: AWS-DevOpsAgent-Testing
  # CloudWatch Alarm for Lambda errors
  LambdaErrorAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: AWS-DevOpsAgent-Lambda-Error-Test
      AlarmDescription: AWS-DevOpsAgent beta test - Lambda error rate alarm
      MetricName: Errors
      Namespace: AWS/Lambda
      Statistic: Sum
      Period: 60
      EvaluationPeriods: 1
      Threshold: 0
      ComparisonOperator: GreaterThanThreshold
      Dimensions:
        - Name: FunctionName
          Value: !Ref TestLambdaFunction
      TreatMissingData: notBreaching
Outputs:
  LambdaFunctionName:
    Description: Lambda Function Name for testing
    Value: !Ref TestLambdaFunction

  LambdaFunctionArn:
    Description: Lambda Function ARN
    Value: !GetAtt TestLambdaFunction.Arn

  AlarmName:
    Description: CloudWatch Alarm Name
    Value: !Ref LambdaErrorAlarm

  TestCommand:
    Description: AWS CLI command to test the function
    Value: !Sub 'aws lambda invoke --function-name ${TestLambdaFunction} --payload "{\"test\":\"AWS DevOpsAgent validation\"}" response.json'

Once the CloudFormation processing completes successfully, the test environment is ready.
Since it takes time for error conditions to occur, let's configure AWS DevOps Agent in the meantime.

AWS DevOps Agent Multi-Account Configuration

First, create an AWS DevOps Agent for multi-account integration.
By the way, the top screen when creating an Agentspace has changed.
Since it's a preview version, breaking changes are likely occurring.

Link the target AWS account to the Secondary Source.
Click the Add button.

After clicking, IAM role information to be created in the target account is displayed. Navigate to the target AWS account and create the IAM role.

Let's try creating the role with a name different from the initially instructed name

The IAM role has been created, but don't forget to configure the inline policy.

Looking at the inline policy configuration, only minimal resource settings are permitted. For example, if you have needs like storing logs in S3 or wanting to monitor Control Tower, you'll need to tune the inline policy configuration.

The IAM role for AWS DevOps Agent should follow these rules:

You should see alarms displayed, so let's check them.
The Lambda alarm went into alarm state, but no alarm occurred for EC2. The script itself didn't seem to be running either, so it might be better to create your own verification resources.

Return to the AWS console on the AWS DevOps Agent side and configure multi-account settings. Configure the following:

Once configuration is complete, the AWS account for multi-account setup will be displayed in the Secondary Source.

An error will occur if the IAM role name doesn't match

By correcting the IAM role name, it becomes Valid.

Testing with AWS DevOps Agent

Now let's verify whether AWS DevOps Agent can detect Lambda failures.

The test alarm name is appearing, so multi-account is functioning properly.

The following was output as the investigation result.
The cause was identified as intentional Lambda code designed to output test errors, confirming that detection is working properly.

The Lambda function AWS-DevOpsAgent-test-lambda, intentionally designed to generate test errors, experienced a 100% error rate (4 errors out of 4 invocations) between 13:40:00 and 13:41:00 UTC. This function was deployed via CloudFormation at 13:15:04 UTC with the description "AWS DevOpsAgent beta test function - intentionally generates errors". Log analysis revealed that the function code (index.py, line 21) intentionally raises exceptions with three different test scenarios: "Test API rate limit exceeded", "Intentional validation error for AWS DevOpsAgent testing", and "Simulated database connection timeout". All errors follow the pattern "AWS DevOpsAgent Test Error: {error_message}". Metrics confirmed these were immediate failures (5-19 millisecond durations) without throttling or timeout issues, consistent with intentional error generation. The CloudWatch alarm "AWS-DevOpsAgent-Lambda-Error-Test" triggered as designed when detecting these errors. This is expected behavior for this test function and not an incident requiring remediation in production.

Insights Gained Through Verification

Through multi-account configuration verification, we gained several insights.

Insight 1: Configuration itself is not difficult with the guide

Since the AWS DevOps Agent multi-account configuration screen provides guidance on what policies and roles to configure, even beginners can handle the setup. However, the default policy permissions are minimal, so customization may be necessary depending on the project.

Insight 2: There are risks with current specifications when configuring for user environments

When performing operational support or monitoring configuration, settings are likely needed for both the vendor's AWS account (where DevOps Agent is set up) and the user's AWS account (where IAM roles are configured). In such cases, if IAM role names and permission settings are not discussed in advance, there's a possibility that the desired troubleshooting cannot be achieved.

Insight 3: Introducing multi-account makes DevOps Agent operations more complex

In this case, we're targeting one AWS account, so management isn't too complex, but when managing multiple AWS accounts with a single DevOps Agent, it becomes difficult to track which AgentSpace manages which AWS account. (You need to check each AgentSpace's accounts one by one)

Future Outlook

Writing this blog has raised the need to consider the following:

Permission management considering multi-account configuration (IAM Identity Center)
DevOps Agent management itself considering IaC
Accuracy verification when registering multiple multi-accounts + same failure occurs simultaneously

Additionally, we'd like to conduct verification from these perspectives:

Integration with unsupported observability tools
Implementation ideas for enterprise environments

Adding Cognito authentication to AWS DevOps Agent

Masaki Okuda — Sun, 18 Jan 2026 07:24:44 +0000

Original Blogs

AWS DevOps AgentにCognito認証を追加する

One of the benefits of AWS DevOps Agent is that it allows you to separate the AWS console from the console for AWS DevOps Agent. This eliminates the need for operations personnel to log in to the AWS console, preventing unexpected resource deletion.

However, there are security concerns when sharing the console URL for AWS DevOps Agent. Although it is difficult to guess because the domain name contains random characters, it is recommended to add at least some authentication functionality as a security measure.

In this article, we will implement a method to control access to the console for AWS DevOps Agent using Cognito authentication.

Notes

The official documentation recommends using the IAM Identity Center for authentication. If you cannot use the IAM Identity Center in the US (Northern Virginia) region, please use this procedure.

Target Audience

Those using the AWS DevOps Agent
Those who want to implement an authentication mechanism for practical use

Leaning Outcome

Cognito can be used instead if IAM Identity Center is not available.
Because Cognito makes it difficult to provide fine-grained permission control, we recommend using IAM Identity Center.

Preparation for implementation

Have an AWS account

Open AWS DevOps Agent Space

Open the AWS Management Console
Make sure your region is set to US (N. Virginia)
Type AWS DevOps Agent in the search box
Click AWS DevOps Agent in the search results

The AWS DevOps Agent menu screen will appear.
Click the "Create Agent Space" button in the upper right corner of the screen.

Enter a name for your Agent Space in the Name and Description fields.
Leave all other fields as default.
Scroll to the bottom and click the Create button.

After a few minutes, the AWS DevOps Agent will be created.
Click the Operator Access button.

The AWS DevOps Agent console screen will be displayed.
Copy and paste the URL into a text file.

Prepare Cognito for AWS DevOps Agent

Return to the AWS console screen
Type Cognito in the search box
Click Cognito in the search results

Click the hamburger menu on the left to display the menu.
Click User Pool.

Click the Create User Pool button

Enter a name for the application

Set the following options:
Sign-in Identifier Option: Email Address
Self-Registration: Unchecked
Required Sign-in Attribute: Email Address

Paste the AWS DevOps Agent URL you copied earlier into the return URL.
Click the button to create a user directory.

Click User Pools in the left menu.
Click the user pool you just created.

Click on Users in the left menu

Click the "Create User" button
Enter the following information:
Email Address: Your preferred email address
Temporary Password: Your preferred password
Password: Your preferred password
After entering the information, click the "Create User" button.

Login test

Click "Application Client" in the left menu.
Click the application you created.

Click the "Login Page" tab
Click the "Show Login Page" button

Enter the email address of the user you just created

If a password is required, enter it

You will be asked to change your password, so enter a suitable password.

After logging in, you will be redirected to the AWS DevOps Agent screen.

Impressions

I was able to add authentication functionality to AWS DevOps Agent with Cognito without using IAM Identity Center. However, since accounts are managed by Cognito, user management can become complicated.

It's sufficient if you require minimal authentication functionality, but if you want to control permissions more precisely for each operator, we recommend using the IAM Identity Center. Currently, AWS DevOps Agent is a preview service, so it only supports the IAM Identity Center in the US (Northern Virginia) region. We expect support for other regions will follow when it becomes generally available.

The implementation itself is relatively simple, so if you are considering strengthening the security of your AWS DevOps Agent, give it a try.

Additional Note

If you are using IAM Identity Center management, you will lose access to the AWS DevOps Agent if your session expires. Session management is a topic for future consideration.

[Tips] [Podman] What to do if you get an "insufficient space" error when loading an image

Masaki Okuda — Wed, 08 Oct 2025 23:13:48 +0000

Thank you for reading this article.
This is Mob Engineer (@mob-engineer).

When building a container using Podman, I encountered an error due to insufficient space in the default image storage directory. I found a workaround, so I'm posting it here for future reference.

Use case

When temporarily saving images to a directory with a large capacity

work around

By executing it with the --root option, it will be saved to the option specified destination.

$ podman load -i <image path> --root <destination>

Points to note

If you load using the above command, the loaded image will not be displayed unless you add the --root option.

# Image information not displayed
$ podman images

# Image displayed
$ podman images --root

Warnig

This is just a workaround, so it should only be used temporarily (delete the image stored locally after pushing it to any repository). If you want to permanently change the storage folder, change the settings in "~/.config/containers/storage.conf".

Summary

Podman itself is easy to use, so I will continue to output any tips I find about podman.

Docs

podman-system-prune (Removing Unnecessary Resources)

podman-system-df (Checking Disk Usage)

podman (Main Page - Storage Settings)

podman-system-reset (Full Storage Reset)

Troubleshooting

Deep Dive into AWS Cloud WAN Core Network Policy: Configuration, Examples, and Strategy

Masaki Okuda — Sun, 05 Oct 2025 13:29:06 +0000

Deep Dive into AWS Cloud WAN Core Network Policy: Configuration, Examples, and Strategy

Thank you for reading this article.
I'm mob-engineer (@mob-engineer).

The core network policy is the heart of the Cloud WAN service, but configuring it can seem daunting for network beginners. In this article, I'll organize and summarize the policy structure, configuration examples, and strategies for Cloud WAN core networks.

Target Audience

This article is written for readers facing the following challenges:

Those using Cloud WAN in practice but lacking deep understanding
Those wanting to develop strategies for core network policies

Core Network Policy Structure

The core network policy structure is well documented in the official AWS documentation.

Official Documentation

The core network policy consists of the following components:

Core network configuration (IP addresses, AS numbers, etc.)
Segments (filtering settings, etc.)
Network function groups (used when configuring firewalls, etc.)
Segment actions (specifying what processing to perform for each segment)
Attachment policies (rules for attaching network resources)

That said, correctly understanding and configuring these rules can be challenging.
(Segment actions in particular seem to be a major hurdle)

Core Network Policy Samples

AWS provides several official samples.

1 Segment + 1 Region

AWS Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            }
        ]
    },
    "segments": [
        {
            "name": "mynetwork",
            "require-attachment-acceptance": false
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 100,
            "condition-logic": "and",
            "conditions": [
                {
                    "type": "any"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "mynetwork"
            }
        }
    ]
}

This is a very simple core network policy that should be easy to understand.
For those touching Cloud WAN for the first time, starting with this policy is the quickest way to learn.

2 Segments + Multiple Regions

Official Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "us-east-2"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "secured"
        },
        {
            "name": "nonSecured"
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 100,
            "conditions": [
                {
                    "type": "tag-value",
                    "key": "Network",
                    "value": "Secured",
                    "operator": "equals"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "secured"
            }
        },
        {
            "rule-number": 200,
            "conditions": [
                {
                    "type": "tag-value",
                    "key": "Network",
                    "value": "Non-Secured",
                    "operator": "equals"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "non-secured"
            }
        }
    ]
}

This is more complex than the previous example, but it becomes easier to understand if you imagine "completely separating networks for Tokyo and Osaka locations."
(Secured = Tokyo location, Non-Secured = Osaka location)

When Including Specific Segment Settings

Official Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "development",
            "isolate-attachments": true,
            "require-attachment-acceptance": false
        },
        {
            "name": "hybrid"
        }
    ],
    "segment-actions": [
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "development",
            "share-with": [
                "hybrid"
            ]
        },
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "development",
            "destinations": [
                "attachment-12355678901234567",
                "attachment-23456789012345678"
            ]
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 10,
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "vpc"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "development"
            }
        },
        {
            "rule-number": 20,
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "vpn"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "hybrid"
            }
        }
    ]
}

This configuration is slightly different from the previous ones. It's used when you want to "restrict connections even within networks designated for development." (This is the kind of setting you'd use when multiple products are developing in the same environment)

Network Configuration Considering Development Process

Official Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "us-west-2"
            }
        ]
    },
    "segments": [
        {
            "name": "development",
            "isolate-attachments": true,
            "require-attachment-acceptance": false
        },
        {
            "name": "testing",
            "isolate-attachments": true,
            "require-attachment-acceptance": false
        },
        {
            "name": "production",
            "isolate-attachments": true,
            "require-attachment-acceptance": true
        },
        {
            "name": "sharedServices"
        }
    ],
    "segment-actions": [
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "sharedservices",
            "share-with": "*"
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 1000,
            "conditions": [
                {
                    "type": "tag-exists",
                    "key": "Stage"
                }
            ],
            "action": {
                "association-method": "tag",
                "tag-value-of-key": "Stage"
            }
        },
        {
            "rule-number": 1500,
            "conditions": [
                {
                    "type": "resource-id",
                    "operator": "equals",
                    "value": "vpc-1234567890123456"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "sharedservices"
            }
        },
        {
            "rule-number": 1600,
            "conditions": [
                {
                    "type": "resource-id",
                    "operator": "equals",
                    "value": "vpn-1234567890123456"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "sharedservices"
            }
        }
    ]
}

This is probably the most common use case for Cloud WAN. It's used when separating development, staging, and production environments by tag name. (You can also do tricky things like specifying only relatively inexpensive regions for the development environment)

For Environments Not Using VPC

Official Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "inside-cidr-blocks": [
            "100.65.0.0/16"
        ],
        "edge-locations": [
            {
                "location": "eu-central-1"
            },
            {
                "location": "us-west-2"
            },
            {
                "location": "us-east-1"
            },
            {
                "location": "eu-west-1"
            }
        ]
    },
    "segments": [
        {
            "name": "sales"
        },
        {
            "name": "testing"
        },
        {
            "name": "iot",
            "isolate-attachments": true
        },
        {
            "name": "internet"
        },
        {
            "name": "engineering"
        }
    ],
    "segment-actions": [
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "internet",
            "share-with": [
                "sales"
            ]
        },
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "iot",
            "share-with": [
                "engineering"
            ]
        },
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "sales",
            "destinations": [
                "attachment-12355678901234567",
                "attachment-23456789012345678",
                "attachment-35567890123456790",
                "attachment-4567890123456789a"
            ]
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 1000,
            "conditions": [
                {
                    "type": "tag-exists",
                    "key": "Assign-to"
                }
            ],
            "action": {
                "association-method": "tag",
                "tag-value-of-key": "Assign-to"
            }
        }
    ]
}

This is used when configuring connectivity between departments in each region. When complexity reaches this level, it's advisable to establish a dedicated organization to manage it. (Complex configurations are possible, but management becomes more challenging)

Placing a Firewall Between Networks

Official Documentation

{
    "version": "2021.12",
    "core-network-configuration": {
        "asn-ranges": [
            "64512-65534"
        ],
        "edge-locations": [
            {
                "location": "us-east-1"
            },
            {
                "location": "us-west-2"
            }
        ]
    },
    "segments": [
        {
            "name": "internalApps"
        },
        {
            "name": "firewall"
        },
        {
            "name": "onPremises"
        }
    ],
    "segment-actions": [
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "internalApps",
            "destinations": [
                "attachment-deadbeef901234567",
                "attachment-eeeeee00000000000"
            ],
            "description": "Send all internet headed on-premises through the firewall"
        },
        {
            "action": "create-route",
            "destination-cidr-blocks": [
                "0.0.0.0/0"
            ],
            "segment": "onPremises",
            "destinations": [
                "attachment-deadbeef901234567",
                "attachment-eeeeee00000000000"
            ],
            "description": "Send all traffic received from the VPN through the firewall"
        },
        {
            "action": "share",
            "mode": "attachment-route",
            "segment": "firewall",
            "share-with": [
                "internalAapps",
                "onPremises"
            ]
        }
    ],
    "attachment-policies": [
        {
            "rule-number": 500,
            "description": "We'll do our specific policies before we do attachment types.",
            "conditions": [
                {
                    "type": "tag-value",
                    "key": "core-network",
                    "operator": "equals",
                    "value": "firewall"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "firewall"
            }
        },
        {
            "rule-number": 1000,
            "description": "Let's assume all VPCs are internal apps",
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "vpc"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "internalApps"
            }
        },
        {
            "rule-number": 1500,
            "description": "Let's also assume all VPNs are from on-premises",
            "conditions": [
                {
                    "type": "attachment-type",
                    "operator": "equals",
                    "value": "site-to-site-vpn"
                }
            ],
            "action": {
                "association-method": "constant",
                "segment": "onPremises"
            }
        }
    ]
}

While the configuration is tedious, it's essentially used when "configuring a firewall between networks." However, with recent updates to Transit Gateway and Firewall integration, it's hard to imagine cases where you'd specifically configure a firewall with Cloud WAN.

Policy Strategy Considerations

The more complex the network becomes, the more complex the configuration gets. Here are some points to keep in mind:

Keep policy descriptions simple and representative of the configuration content
1. This may seem obvious, but if descriptions are simple, even first-time viewers can understand what the policy means
Establish and document policy management rules
1. (It would be easier if there were GitHub integration features) By establishing policy management rules, you can prevent inadvertent changes
Use meaningful segment names
1. Consider referencing naming conventions from "Readable Code"
Prepare an environment identical to production
1. If you mistakenly modify the core network policy, some communication impact will occur
2. It's a matter of cost, but if possible, it's recommended to prepare an environment identical to production for testing

Summary

Personally, I think it's safer to establish a strategy for segment naming during the design phase. For those who have some experience with SD-WAN services, Cloud WAN should be an approachable service.

PS

Even looking at the Government Cloud Usage Guide, there's no mention of Cloud WAN, so it's unlikely to be used. (While it's convenient if mastered, there are few domestic cases and the difficulty level is high...)

Network Connection Methods (AWS Edition)

[RHEL]Supports upgrading from RHEL9 to RHEL10 on AWS EC2 instances

Masaki Okuda — Thu, 31 Jul 2025 08:14:23 +0000

I previously wrote an article about installing RHEL10,
but this time I'll be leaving it here as an article about verifying an upgrade from RHEL9 to RHEL10 on an AWS EC2 instance.

Purpose of this Article
Target Audience
Prerequisites
Upgrade
Preliminary Verification
Workflow
Postmortem Verification
Impressions

Purpose of this article

This article aims to help solve the following problems:

Verifying the upgrade from RHEL9 to RHEL10 in an AWS environment (EC2 instance)
Verifying behavior before and after the upgrade in an environment simulating a real user environment
Identifying current anticipated issues during the upgrade

Target audience

I would appreciate it if this article could be of use to people facing the following challenges:

Those verifying an upgrade from RHEL9 to RHEL10
Those who want to understand the points that need to be considered when conducting the verification

These are the results of testing in a personal environment.
If you are upgrading in a production environment, please test and confirm that there are no issues before proceeding. Please note that the procedure performed here is not recommended by Red Hat, so please use it at your own risk.

Upgrading from RHEL9 to RHEL10 is not supported in an EC2 instance environment.
(This is because in-place upgrades in the RHUI environment are not supported.)

Implementation flow

The process will be "Pre-verification" ⇒ "Upgrade support" ⇒ "Post-verification". After that, we will set up the EC2 instance for the actual environment.

Part 0: Setup

The configuration of the EC2 instance we created is as follows:

Before setting up, please Downloads the materials from the following GitHub:

https://github.com/MASAKIOKUDA-eng/RHEL10_aws_upgrade

First, log in to your EC2 instance.

Transfer the materials downloaded from GitHub using SCP.

Run the command [ls -la /tmp]
Verify that [check.sh] and [setup.sh] exist

ls -la /tmp

Currently, the file does not have execution permissions, so you need to grant it permission.

Run the command [chmod +x /tmp/*.sh]

chmod +x /tmp/*.sh

Run the command [ls -la /tmp] again.
Make sure that [check.sh] and [setup.sh] are displayed in green.

ls -la /tmp

Currently when I run the script I get a line break error.

Run [sed -i 's/\r$//' /tmp/*.sh] to fix the line breaks in the script.

sed -i 's/\r$//' /tmp/*.sh

After execution, run setup.sh with sudo privileges

If you do not run it with sudo privileges, the following error will occur:

After a certain amount of time has passed, the package installation will be completed.

Preliminary verification

There is no problem if you run check.sh for preliminary verification.

sudo /tmp/check.sh

You can perform post-mortem verification by downloading the file created using SCP.

Work details

Since this cannot be handled using normal upgrade methods, we will use the Blue-Green deployment method (creating a new RHEL10 instance and deleting the old instance) to handle the upgrade.

This procedure is not recommended by Red Hat or AWS.
If you are performing this in a production environment, please verify that there are no issues before proceeding.

Click the checkbox to the left of the instance you want to upgrade.
Click Actions > Images and Templates > Launch Similar at the top of the screen.

The EC2 instance launch screen will be displayed.
Click the Quick Start tab

The following pop-up will appear, so click [Confirm changes].

Since custom volumes will be deleted or changed, you must back up your data beforehand.

Click the Red Hat icon
Make sure the Amazon Machine Image is set to Red Hat Enterprise Linux 10.
Click the [Launch Instance] button

Now you can build a RHEL10 instance with the same settings.

Post-mortem verification

As with the pre-verification, check the settings using check.sh.
After executing, check using a Diff tool or similar.

Impressions

As a premise, upgrade procedures specialized for RHEL used in AWS services (EC2 instances, etc.) have not been officially announced, so when implementing, it is necessary to conduct verification using support, etc.

Furthermore, since upgrade operations can only be performed using a Blue-Green deployment method (building multiple instances ⇒ deleting method), it is recommended to store data in services such as EFS in advance before performing upgrade operations for data stored in EBS.

Additionally, when creating verification scripts this time, I used Claude for creation, and since it can generate the desired output, I think there are scenes where it can be utilized in script creation for infrastructure verification as well.

I think upgrade procedures for AWS environments will also be officially published in the future, so if you want to proceed with migration, it would be better to put it on hold.

I hope this article will be helpful for upgrade operations.

Reference Sites

https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/10/html-single/upgrading_from_rhel_9_to_rhel_10/index

https://qiita.com/duelist2020jp/items/90df38bfdad62591423f

https://openstandia.jp/oss_info/redhatenterpriselinux/version/

[AWS]We have summarized the domain costs that can be purchased through AWS Route53 (as of July 5, 2025)

Masaki Okuda — Sun, 06 Jul 2025 00:11:58 +0000

*This article is an English translation of the following article:
https://qiita.com/mob_engineer/items/3e6804d86b88a401a8cd

you for always reading our articles!
My name is Mob-engineer！！

During my new graduate training, I had to research Route53 domain costs, but I realized that there was no comprehensive information on the costs per domain, so I put together a quick summary.

This is just a little tidbit of information, but I hope you'll enjoy reading it.

(Reference) How to buy a domain on Route 53

Many of you may already know this, but I'll give a brief summary.

Enter [Route53] in the search box at the top of the console screen.
Click [Route53] from the search results.

The Route53 menu screen will be displayed. Click [Registered Domains] on the left Menu.

A screen listing domains managed on AWS will be displayed. Click [Register Domain] at the top of the screen.

A list of domains will be displayed
Enter any name and search to display available domain names.
Click on "Selected" and then on the "Proceed to Checkout" button

You can specify whether to turn automatic updates on or off, so change it according to your requirements.
Click the Next button

The Contact Information will be displayed.
Configure any information and privacy protection settings and click the [Next] button.

[Good Point👍]
It's nice to see privacy protection enabled by default.

Check the box for the terms of use and click the [Submit] button to create a domain that can be managed by Route53.

[Notice📝]
If you need to change your registration information due to organizational restructuring, you can do so through Route53.

domain cost

Now I would like to summarize the main domain costs.
To make it easier to understand, I will summarize them in table format, ranking them in order of cheapest annual cost.

Rank	Domain Name	Cost (USD)
1	.click	$3
2	.link	$5
3	.co.za	$8
3	.eu	$8
3	.fyi	$8
3	.in	$8
3	.me.uk	$8
8	.casa	$9
8	.co.uk	$9
8	.de	$9
8	.org.uk	$9
8	.uk	$9
13	.es	$10
13	.name	$10
13	.nl	$10
16	.be	$11
16	.cz	$11
16	.it	$11
16	.us	$11
20	.cc	$12
20	.fr	$12
20	.work	$12
23	.academy	$13
23	.boutique	$13
23	.consulting	$13
23	.life	$13
23	.live	$13
23	.media	$13
23	.news	$13
23	.services	$13
23	.social	$13
23	.solutions	$13
23	.studio	$13
23	.world	$13
35	.ca	$14
35	.ch	$14
37	.com	$15
37	.org	$15
37	.pictures	$15
37	.pw	$15
37	.uno	$15
42	.contact	$16
42	.help	$16
42	.lol	$16
42	.photo	$16
42	.pics	$16
42	.tattoo	$16
48	.fi	$17
48	.net	$17
50	.business	$18
50	.company	$18
50	.xyz	$18
53	.club	$19
53	.futbol	$19
53	.shiksha	$19
53	.vip	$19
57	.co.nz	$20
57	.gift	$20
57	.im	$20
57	.net.nz	$20
57	.org.nz	$20
57	.reisen	$20
57	.space	$20
57	.website	$20
65	.au	$21
65	.com.au	$21
65	.net.au	$21
68	.exposed	$22
68	.irish	$22
68	.kim	$22
68	.place	$22
68	.rocks	$22
73	.biz	$23
73	.gratis	$23
73	.jetzt	$23
73	.red	$23
73	.rip	$23
78	.blue	$25
78	.equipment	$25
78	.fun	$25
78	.online	$25
78	.pink	$25
78	.report	$25
78	.site	$25
78	.soccer	$25
78	.supplies	$25
87	.bet	$26
87	.city	$26
87	.cloud	$26
87	.directory	$26
87	.football	$26
87	.graphics	$26
87	.group	$26
87	.lighting	$26
87	.management	$26
87	.onl	$26
87	.run	$26
87	.supply	$26
99	.dance	$28
99	.gallery	$28
99	.info	$28
99	.institute	$28
99	.photos	$28
99	.pro	$28
99	.support	$28
106	.bid	$29
106	.com.mx	$29
106	.ink	$29
106	.loan	$29
106	.property	$29
106	.qpon	$29
106	.schule	$29
106	.stream	$29
106	.technology	$29
106	.today	$29
106	.trade	$29
117	.agency	$30
117	.email	$30
117	.ltd	$30
117	.ninja	$30
117	.tips	$30
117	.wiki	$30
123	.foundation	$31
123	.gives	$31
123	.me	$31
126	.band	$32
126	.center	$32
126	.international	$32
126	.se	$32
130	.bargains	$33
130	.cab	$33
130	.contractors	$33
130	.democrat	$33
130	.discount	$33
130	.games	$33
130	.gifts	$33
130	.gripe	$33
130	.haus	$33
130	.kaufen	$33
130	.kiwi	$33
130	.sarl	$33
130	.shopping	$33
130	.singles	$33
144	.beer	$35
144	.education	$35
144	.fashion	$35
144	.garden	$35
144	.immo	$35
144	.network	$35
144	.ruhr	$35
144	.systems	$35
144	.wedding	$35
144	.yoga	$35
154	.airforce	$36
154	.auction	$36
154	.cash	$36
154	.cheap	$36
154	.clothing	$36
154	.fail	$36
154	.florist	$36
154	.forsale	$36
154	.limited	$36
154	.photography	$36
154	.rehab	$36
154	.repair	$36
154	.republican	$36
154	.software	$36
154	.tools	$36
154	.tv	$36
154	.video	$36
154	.wtf	$36
172	.buzz	$37
173	.co	$38
173	.immobilien	$38
173	.team	$38
173	.town	$38
177	.army	$39
177	.bike	$39
177	.builders	$39
177	.cards	$39
177	.catering	$39
177	.chat	$39
177	.coffee	$39
177	.computer	$39
177	.construction	$39
177	.cool	$39
177	.deals	$39
177	.direct	$39
177	.engineer	$39
177	.enterprises	$39
177	.estate	$39
177	.exchange	$39
177	.express	$39
177	.family	$39
177	.farm	$39
177	.mba	$39
177	.money	$39
177	.properties	$39
177	.sale	$39
177	.school	$39
177	.style	$39
177	.vacations	$39
177	.vision	$39
177	.works	$39
177	.zone	$39
205	.associates	$40
205	.community	$40
205	.fitness	$40
205	.gmbh	$40
205	.land	$40
205	.marketing	$40
205	.moda	$40
205	.navy	$40
205	.parts	$40
205	.productions	$40
205	.pub	$40
205	.store	$40
205	.tech	$40
205	.training	$40
219	.digital	$42
219	.guide	$42
219	.guru	$42
219	.llc	$42
219	.vc	$42
219	.vet	$42
219	.vg	$42
226	.care	$43
226	.christmas	$43
226	.domains	$43
226	.events	$43
226	.fish	$43
226	.mobi	$43
226	.show	$43
226	.watch	$43
234	.actor	$45
234	.church	$45
234	.house	$45
234	.rentals	$45
238	.cafe	$46
238	.industries	$46
238	.market	$46
238	.plus	$46
242	.degree	$49
242	.press	$49
244	.viajes	$50
244	.wien	$50
246	.memorial	$51
247	.jp	$54
248	.coupons	$55
248	.diamonds	$55
248	.fan	$55
248	.lease	$55
248	.limo	$55
248	.surgery	$55
254	.apartments	$58
254	.camera	$58
254	.condos	$58
254	.design	$58
254	.financial	$58
254	.flights	$58
254	.vegas	$58
261	.bingo	$59
261	.camp	$59
261	.delivery	$59
261	.hockey	$59
261	.maison	$59
261	.tienda	$59
261	.ventures	$59
261	.vin	$59
261	.voyage	$59
261	.wine	$59
271	.expert	$60
272	.villas	$61
273	.attorney	$62
273	.cruises	$62
273	.lawyer	$62
273	.mortgage	$62
273	.reviews	$62
273	.university	$62
279	.dog	$63
279	.glass	$63
279	.holiday	$63
279	.hospital	$63
279	.restaurant	$63
279	.salon	$63
279	.shoes	$63
279	.solar	$63
279	.theater	$63
279	.tours	$63
289	.clinic	$65
289	.dating	$65
289	.finance	$65
289	.golf	$65
289	.holdings	$65
289	.host	$65
289	.jewelry	$65
289	.kitchen	$65
289	.pizza	$65
289	.taxi	$65
289	.toys	$65
300	.black	$66
300	.claims	$66
300	.codes	$66
300	.engineering	$66
300	.poker	$66
300	.ski	$66
300	.tennis	$66
307	.mx	$67
308	.capital	$70
308	.coach	$70
308	.fund	$70
308	.legal	$70
308	.partners	$70
308	.tax	$70
314	.io	$71
315	.careers	$72
315	.college	$72
315	.dental	$72
315	.dentist	$72
315	.insure	$72
315	.plumbing	$72
321	.cleaning	$75
322	.berlin	$76
322	.bio	$76
322	.sh	$76
325	.recipes	$79
326	.lgbt	$80
327	.green	$82
328	.gg	$83
329	.healthcare	$86
330	.global	$92
330	.vote	$92
332	.reise	$95
333	.ac	$99
334	.tires	$100
335	.credit	$108
335	.gold	$108
337	.doctor	$115
337	.furniture	$115
337	.law	$115
337	.loans	$115
341	.accountants	$116
341	.energy	$116
343	.adult	$122
343	.ceo	$122
343	.fm	$122
343	.porn	$122
343	.sex	$122
343	.xxx	$122
349	.investments	$129
350	.casino	$169
351	.creditcard	$179
352	.hiv	$256
353	.sucks	$285
354	.movie	$329

Conclusion

I summarized the domain costs related to Route53, and I got the impression that it was cheaper than I expected. On top of that, since it can be managed centrally on AWS, it is easy to combine it with other services, so I thought that transferring existing domains to Route53 would be a good option.

This is just a small article, but thank you for reading to the end!

Reference site

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/best-practices.html

https://business.ntt-east.co.jp/content/cloudsolution/column-122.html

[AWS]Building an AWS Security Learning Tetris Puzzle Game with Amazon Q Developer CLI

Masaki Okuda — Mon, 23 Jun 2025 23:48:03 +0000

Introduction

Thank you for always reading my articles! I'm a mob engineer who previously created simple games through Amazon Q Developer for CLI projects. This time, I wanted to implement a game that could be used for educational activities both inside and outside the company, so I decided to create a second iteration.

Basic Development Approach

I implemented this project primarily using instructions to Amazon Q Developer for CLI. The concept I had in mind during implementation was:

AWS Security Learning Tetris Puzzle
Including security elements from Government Cloud
Supporting both Japanese and English languages

Game Overview

I've published the implemented game on GitHub.io. You can play it at the following URL:

Game URL: [https://masakiokuda-eng.github.io/cloud-guardian-puzzle]

Key Features:

English Support (Some Japanese text remains and needs tuning)
Tutorial Screen (Placement examples are animated)
Gameplay Screen

Tutorial screen with animated placement examples

Main gameplay interface

The game is implemented so that you can achieve high scores by considering security countermeasures in your gameplay strategy.

Development Architecture & Approach

You can check the repository at the following URL:
Repository: [https://github.com/MASAKIOKUDA-eng/cloud-guardian-puzzle]

Directory Structure

I created the following directory structure:

├── assets/                    # Static assets
│   ├── images/               # Image files
│   │   └── aws/             # AWS service icons
│   ├── sounds/              # Audio files
│   └── styles/              # CSS stylesheets
├── dist/                     # Build artifacts
├── public/                   # Public files
│   ├── assets/              # Public assets
│   └── index.html           # Main HTML file
├── src/                      # Source code
│   ├── components/          # React components
│   │   ├── common/          # Common components
│   │   ├── game/            # Game-related components
│   │   └── pages/           # Page components
│   ├── core/                # Core functionality
│   ├── i18n/                # Internationalization
│   ├── levels/              # Level definitions
│   ├── models/              # Data models
│   ├── puzzles/             # Puzzle definitions
│   ├── tetris/              # 2D Tetris implementation
│   │   ├── components/      # Tetris components
│   │   ├── engine/          # Game engine
│   │   └── models/          # Tetris models
│   ├── tetris3d/            # 3D Tetris implementation
│   │   ├── components/      # 3D Tetris components
│   │   ├── engine/          # 3D Game engine
│   │   └── models/          # 3D Tetris models
│   └── utils/               # Utility functions
└── tests/                    # Test files

Deployment Strategy

Since this implementation uses Node.js, I needed a build → deploy process using npm commands. While playing locally would simply require setting up a server, I aimed to publish on GitHub.io, which took considerable implementation time.

I adopted a deployment strategy using GitHub Actions to place build artifacts on a deployment branch. The Deploy.yml I created is as follows:

name: Deploy to GitHub Pages

on:
  push:
    branches:
      - main

permissions:
  contents: write

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout 🛎️
        uses: actions/checkout@v3

      - name: Setup Node.js ⚙️
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'

      - name: Install dependencies 📦
        run: npm ci

      - name: Copy assets to public directory
        run: |
          mkdir -p public/assets/images/aws
          cp -r assets/images/aws/*.png public/assets/images/aws/

      - name: Build 🔧
        run: npm run build

      - name: Create .nojekyll file
        run: touch dist/.nojekyll

      - name: Deploy 🚀
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: dist
          branch: gh-pages
          clean: true

Package Configuration

The package.json generation also required careful consideration and took implementation time:

{
  "name": "cloud-guardian-puzzle",
  "version": "0.1.0",
  "description": "AWS GovCloud security and compliance themed Tetris game",
  "main": "src/index.js",
  "scripts": {
    "start": "webpack serve --mode development --port 3001",
    "build": "webpack --mode production",
    "test": "jest",
    "predeploy": "npm run build",
    "deploy": "gh-pages -d dist"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/MASAKIOKUDA-eng/cloud-guardian-puzzle.git"
  },
  "keywords": [
    "aws",
    "govcloud", 
    "security",
    "puzzle",
    "game",
    "tetris"
  ],
  "author": "",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/MASAKIOKUDA-eng/cloud-guardian-puzzle/issues"
  },
  "homepage": "https://MASAKIOKUDA-eng.github.io/cloud-guardian-puzzle",
  "dependencies": {
    "phaser": "^3.55.2",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-router-dom": "^6.10.0"
  },
  "devDependencies": {
    "@babel/core": "^7.21.4",
    "@babel/preset-env": "^7.21.4",
    "@babel/preset-react": "^7.18.6",
    "babel-loader": "^9.1.2",
    "copy-webpack-plugin": "^13.0.0",
    "css-loader": "^6.7.3",
    "file-loader": "^6.2.0",
    "gh-pages": "^6.3.0",
    "html-webpack-plugin": "^5.5.1",
    "jest": "^29.5.0",
    "style-loader": "^3.3.2",
    "webpack": "^5.80.0",
    "webpack-cli": "^5.0.2",
    "webpack-dev-server": "^4.13.3"
  }
}

Implementation Challenges

While games that complete with HTML only can be implemented quickly, I found that there are many elements to consider when creating dynamic games using Node.js that can be published via GitHub.io. Additionally, I felt there's a risk of generating code that deviates from requirements if you don't properly check the diff.

Therefore, I think minimal understanding of the programming language is necessary to properly use Amazon Q Developer for CLI. (If the requirement was just to play on a local server, the implementation difficulty wouldn't be that high.)

Areas for Improvement

Through gameplay, I identified several improvement points:

Current Issues:

Language Switching: Some strings don't reflect when switching between English ↔ Japanese
Performance: Screen stutters during gameplay
Gameplay Mechanics: It's a simple Tetris game, so I'd like to enable player characters
Development Flexibility: The specification only starts on port 3001, lacking flexibility

Future Prospects

I want to continue utilizing Amazon Q Developer for CLI not only for game creation but also for hands-on tutorial creation and practical business applications. I'm also interested in jsii (a library that converts TypeScript to other development languages), so I'm thinking of making a "pseudo-jsii" as my next target.

Key Takeaways

AI-Assisted Development: Amazon Q Developer for CLI can significantly accelerate game development
Deployment Complexity: Publishing Node.js applications to GitHub Pages requires careful build pipeline configuration
Educational Value: Combining gaming with technical education creates engaging learning experiences
Iterative Improvement: AI-generated code requires human oversight and iterative refinement

Technical Stack

Frontend: React, Phaser.js for game engine
Build Tools: Webpack, Babel
Deployment: GitHub Actions, GitHub Pages
Development: Amazon Q Developer for CLI
Languages: JavaScript/TypeScript with internationalization support

Learning Outcomes

This project demonstrated the potential of AI-assisted development while highlighting the importance of:

Understanding the underlying technology stack
Proper code review and validation
Incremental development and testing
Balancing automation with human expertise

This was a rough overview, but thank you for reading to the end! I hope this inspires others to explore AI-assisted development for educational gaming projects.

Related Resources

Campaign Information Page (until 6/20)
Amazon Q Developer Documentation
Amazon Q CLI Related Articles

I personally think it could also be useful for OSS maintenance.

[AWS]Hands-on: Building a Simple Web Server with CodeBuild + CodeDeploy (Sphinx)

Masaki Okuda — Mon, 23 Jun 2025 22:47:01 +0000

Introduction

Thank you for reading my articles! I'm a mob engineer who has been working on understanding CodeBuild → CodeDeploy pipeline construction in my work. Since I was having some difficulties with this, I decided to create a hands-on article to improve my skills and share the knowledge.

I've written this article in simple terms so that even first-time readers can easily follow along. I hope you find it helpful!

Target Audience
Completion Image
Hands-on Tutorial
- Step 0: Prerequisites
- Step 1: IAM Roles & S3 Setup
- Step 2: EC2 Construction (RHEL10)
- Step 3: CodeBuild Configuration
- Step 4: CodeDeploy Configuration
- Step 5: Execution Results
Insights

Target Audience

This article is intended for those who have the following challenges:

Those who feel intimidated by AWS pipelines
Those who want to strengthen their pipeline-related skills
Those who want to deepen their understanding of pipelines through hands-on experience

Completion Image

The completed architecture will look like this:

GitHub: Frontend code management (Sphinx)
CodeBuild: Build process (Sphinx generation)
CodeDeploy: Deployment (deploy build artifacts to EC2)
S3: Store build artifacts

Hands-on Tutorial

Step 0: Prerequisites

https://github.com/MASAKIOKUDA-eng/sphinx-aws-demo/blob/main/buildspec.yml

Please fork the sample code to your own GitHub account.

Step 1: IAM Roles & S3 Setup

First, let's create an S3 bucket:

Enter "S3" in the search box
Click S3 from the search results
Click the "Create bucket" button in the center of the screen
Enter an arbitrary name for the bucket name
Scroll to the bottom and click the "Create bucket" button
Confirm that the created bucket is displayed

The S3 bucket creation is now complete.

Next, let's create IAM roles and policies:

Enter "IAM" in the search box
Click IAM from the search results
Click "Policies" in the left pane
Click "Create policy" on the right side of the screen
Create the following policies from the policy creation screen:

AWSCodePipelineServiceRole Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketAcl",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectVersion",
        "s3:ListBucket",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::your-codepipeline-artifacts-bucket",
        "arn:aws:s3:::your-codepipeline-artifacts-bucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "codebuild:BatchGetBuilds",
        "codebuild:StartBuild"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "codedeploy:CreateDeployment",
        "codedeploy:GetApplication",
        "codedeploy:GetApplicationRevision",
        "codedeploy:GetDeployment",
        "codedeploy:GetDeploymentConfig",
        "codedeploy:RegisterApplicationRevision"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "codestar-connections:UseConnection"
      ],
      "Resource": "*"
    }
  ]
}

AWSCodeBuildServiceRole Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Resource": "*",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::your-codepipeline-artifacts-bucket",
        "arn:aws:s3:::your-codepipeline-artifacts-bucket/*"
      ]
    }
  ]
}

After creating the policies, create the following roles:

EC2InstanceRole (for EC2 instances)

AWSCodePipelineServiceRole (for CodePipeline)

AWSCodeBuildServiceRole (for CodeBuild)

AWSCodeDeployServiceRole (for CodeDeploy)

Step 2: EC2 Construction (RHEL10)

Before building EC2, let's create a security group in advance:

Enter "EC2" in the search box
Click EC2 from the search results
Click "Security Groups" in the left pane
Click the "Create security group" button on the right side
Fill in arbitrary values on the security group creation screen
Configure inbound and outbound rules as follows:

EC2 creation is mostly default except for the security group, so I'll omit the detailed steps.

After launch completion, connect to the web server via Teraterm and execute the following commands:

sudo yum update -y
sudo yum install -y ruby wget httpd
cd /home/ec2-user
wget https://aws-codedeploy-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/codedeploy-agent.noarch.rpm
sudo yum install -y ./codedeploy-agent.noarch.rpm
sudo systemctl start codedeploy-agent
sudo systemctl status codedeploy-agent
sudo systemctl start httpd
sudo systemctl enable httpd
sudo systemctl status httpd

After configuration, please assign the EC2InstanceRole to the instance.

Step 3: CodeBuild Configuration

Configure CodeBuild with the following settings:

Step 4: CodeDeploy Configuration

Create a CodeDeploy application as follows:

Create a deployment group as shown:

Step 5: Execution Results

During execution, the following error appeared:

Issue 1: Policy Permission Shortage

I discovered insufficient policy permissions, so I added the following policy to AWSCodePipelineServiceRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketAcl",
        "s3:GetBucketLocation",
        "s3:GetBucketVersioning",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:GetObjectVersion",
        "s3:ListBucket",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::codepipeline-ap-northeast-1-71a30834a9be-4ec0-a2b9-981224e19677",
        "arn:aws:s3:::codepipeline-ap-northeast-1-71a30834a9be-4ec0-a2b9-981224e19677/*"
      ]
    }
  ]
}

Issue 2: EC2 Permission Error

During deployment, an EC2 permission shortage error occurred, so I added the following inline policy to EC2InstanceRole:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::sphinx-handson-20250526",
        "arn:aws:s3:::sphinx-handson-20250526/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "codedeploy:CreateDeployment",
        "codedeploy:GetApplication",
        "codedeploy:GetDeployment",
        "codedeploy:GetDeploymentConfig",
        "codedeploy:ListApplications",
        "codedeploy:ListDeployments"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceStatus"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "tag:GetResources"
      ],
      "Resource": "*"
    }
  ]
}

After re-execution, the errors were resolved.

Let's access the host! We were able to access it successfully.

The goal for this time has been achieved!

Insights

Personally, troubleshooting CodeDeploy errors took some time, but I got the impression that once you do it a few times, it can be implemented without much effort.

Moreover, since the case implemented this time is a minimal configuration, I felt that it could be operated with high scalability by combining it with other services.

I still feel that I need to catch up on pipeline-related topics, so I would like to continue outputting activities.

Key Takeaways

IAM Permissions: Proper IAM role and policy configuration is crucial for successful pipeline execution
Troubleshooting: CodeDeploy errors can be resolved systematically by checking permissions step by step
Scalability: This minimal configuration can be extended with additional AWS services
Learning: Hands-on practice is the best way to understand pipeline concepts

Next Steps

Explore more complex pipeline configurations
Integrate with other AWS services (Lambda, CloudWatch, etc.)
Implement automated testing in the pipeline
Set up monitoring and alerting

Thank you for reading this article to the end! Feel free to share your experiences with AWS pipelines in the comments below.

[Research][AWS]Investigating Transit Gateway Routes with VPC Reachability Analyzer

Masaki Okuda — Mon, 23 Jun 2025 22:17:02 +0000

Introduction

Thank you for reading this article! I'm a mob engineer who previously wrote about Transit Gateway configurations. After successfully completing an AWS hands-on lab involving Transit Gateway, I wanted to share my findings about analyzing Transit Gateway communication paths using VPC Reachability Analyzer.

Background

This article builds upon the AWS Official Hands-on Lab for Transit Gateway configurations. I'll be investigating the network reachability between different VPC configurations through the Transit Gateway setup.

https://catalog.us-east-1.prod.workshops.aws/workshops/e0d1c19d-c80b-4695-a3fc-5c4a25132f47/ja-JP/2-hands-on/2-5-lab5

Current Architecture Overview

The current setup consists of:

Boundary VPC with EC2 instances
Private VPC1 with EC2 instances
Private VPC2 with Transit Gateway attachments
Private VPC3 with Transit Gateway attachments

All connected through a Transit Gateway infrastructure.

Investigation Scope

I wanted to analyze the following connectivity scenarios:

Boundary VPC EC2 ↔ Private VPC1 EC2
Boundary VPC EC2 ↔ Private VPC2 TGW Attachment
Boundary VPC EC2 ↔ Private VPC3 TGW Attachment

Current Ping Connectivity Status

Before diving into the VPC Reachability Analyzer results, I verified the current ping connectivity status between the instances to establish a baseline.

VPC Reachability Analyzer Results

Test 1: Boundary VPC EC2 ↔ Private VPC1 EC2

Analysis Configuration:

Source: EC2 instance in Boundary VPC
Destination: EC2 instance in Private VPC1

Result: Unreachable

The analysis showed that the path was not reachable between these two instances.

Test 2: Boundary VPC EC2 ↔ Private VPC2 TGW Attachment

Analysis Configuration:

Source: EC2 instance in Boundary VPC
Destination: Transit Gateway attachment in Private VPC2

Result: Unreachable

Similar to the previous test, this configuration also resulted in an unreachable status.

Test 3: Boundary VPC EC2 ↔ Private VPC3 TGW Attachment

Analysis Configuration:

Source: EC2 instance in Boundary VPC
Destination: Transit Gateway attachment in Private VPC3

Result: Unreachable

Analysis and Insights

Common Error Pattern

All three connectivity tests resulted in the same error: TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENT

This error indicates that the Transit Gateway route table doesn't have the necessary routes configured to reach the target attachments.

Root Cause Analysis

The primary reason for these connectivity issues appears to be related to the hands-on lab configuration. Specifically:

Missing Route Table Entries: The Transit Gateway route tables lack the necessary routes to direct traffic to the target VPC attachments
Configuration Gap: Without proper routing configuration, VPC Reachability Analyzer correctly identifies these paths as unreachable

Troubleshooting Resources

For teams encountering similar issues, AWS provides comprehensive documentation about VPC Reachability Analyzer error codes and their meanings. This documentation is invaluable for troubleshooting network connectivity issues in complex Transit Gateway environments.

https://docs.aws.amazon.com/vpc/latest/reachability/explanation-codes.html

Leveraging Amazon Q for Faster Resolution

To accelerate the troubleshooting process, I recommend using Amazon Q to:

Quickly identify the root cause of routing issues
Get specific guidance on Transit Gateway route table configurations
Understand the relationship between different AWS networking components

This AI-powered approach can significantly reduce the time needed to diagnose and resolve network connectivity problems.

Future Investigations

While this analysis focused on VPC Reachability Analyzer, I'm planning to explore Network Access Analyzer in future articles to provide even deeper insights into network communication patterns and security configurations.

Key Takeaways

VPC Reachability Analyzer is an excellent tool for validating network paths in Transit Gateway environments
Route table configuration is critical for Transit Gateway connectivity
Systematic analysis helps identify configuration gaps before they impact production workloads
AI-powered troubleshooting (like Amazon Q) can accelerate problem resolution

Conclusion

This investigation demonstrated how VPC Reachability Analyzer can effectively identify routing issues in Transit Gateway configurations. While the current setup showed connectivity problems due to missing route table entries, this analysis provides a clear path forward for resolving these issues.

The combination of traditional network analysis tools and modern AI-powered assistance creates a powerful troubleshooting workflow for complex AWS networking scenarios.

Thank you for reading this article! Feel free to share your experiences with Transit Gateway routing and VPC Reachability Analyzer in the comments below.

[Research]Investigating the route set in Trangit Gateway with VPC Reachability Analyzer![AWS]

Masaki Okuda — Sat, 31 May 2025 14:47:46 +0000

Introduction

Thank you for reading the article!
I was able to verify all the AWS hands-on tests I used in my previous article on Trangit Gateway without any problems. In this article, I would like to discuss the results of testing communications via Trangit Gateway using the VPC Reachabiligy Analyzer.

Hands-on Documents（AWS）

https://catalog.us-east-1.prod.workshops.aws/workshops/e0d1c19d-c80b-4695-a3fc-5c4a25132f47/ja-JP/2-hands-on/2-5-lab5

The perspectives I would like to investigate this time are as follows:

EC2 in Boundary VPC ↔ EC2 in Private VPC1
EC2 in Boundary VPC ↔ TGW attachment in Private VPC2
EC2 in Boundary VPC ↔ TGW attachment in Private VPC3

The current Ping communication confirmation results are as follows.

EC2 in Boundary VPC ↔ EC2 in Private VPC1

Setting For VPC Reachability Analyzer

Results

Information

It seems that it is not possible to display the reverse path when communicating via Trangit Gateway.

EC2 in Boundary VPC ↔ TGW attachment in Private VPC2

Setting For VPC Reachability Analyzer

Results

EC2 in Boundary VPC ↔ TGW attachment in Private VPC3

Setting For VPC Reachability Analyzer

Results

Summary

The error TGW_RTB_NO_ROUTE_TO_TGW_ATTACHMENT was commonly displayed, which is thought to be due to the hands-on configuration used this time.

Therefore, it is thought that the cause is that the route was not set in the route table, so detection by the VPC Reachability Analyzer was not possible.

The error content is summarized in the following document, so please refer to it when troubleshooting.

https://docs.aws.amazon.com/vpc/latest/reachability/explanation-codes.html

Furthermore, using Amazon Q to identify and address the cause of this error is expected to improve the speed of troubleshooting.

Personally, I would have liked to analyze the communication settings using Network Access Analyzer, but I will try to verify this next time.

This is a simple verification article, but thank you for reading to the end.

[AWS][Build Games]I created an AWS puzzle game using Amazon Q CLI!

Masaki Okuda — Wed, 28 May 2025 01:28:30 +0000

Introduction

Thank you for always reading our articles!!
I took on the challenge of "Making a game with Amazon Q CLI" which was posted as part of a Build Games project, so I wrote an article about it!

AWS Builder Center

Connect with builders who understand your journey. Share solutions, influence AWS product development, and access useful content that accelerates your growth. Your community starts here.

builder.aws.com

Install

The installation of the Amazon Q CLI is summarized in the official documentation.

https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/command-line-installing.html

For Amazon Linux, I think the easiest way is to download the Zip file and install it.

Once installed, the following screen will appear.

Game Image

The image of the game I'm trying to create this time is as follows:

Games where you can freely build appropriate architectures like BuilderCards
Make it playable on GitHub.io too

Below is the game I created while querying Amazon Q CLI.

This is the start screen

Operation screen

Results screen

Hint function is also included

We are also able to deliver results.

GitHub Code

https://github.com/MASAKIOKUDA-eng/aws-puzzle

Apps

https://masakiokuda-eng.github.io/aws-puzzle/

Summary

I was surprised to see that I could generate a simple puzzle game by querying the Amazon Q CLI.
However, I noticed that the response time of the Amazon Q CLI was quite slow, and I'm not sure if this was because of the campaign period.

The game I implemented this time can be implemented quickly in about 1-2 hours, so I thought I could do it in my spare time.

Although it was a simple article, thank you for reading it💪💪

P.S.

By the way, the thing that took the longest time was resolving the error that kept popping up.

[Research]simple test on VPC Reachability Analyzer[AWS]

Masaki Okuda — Mon, 19 May 2025 14:27:05 +0000

Introduction

Thank you for always reading our articles!
I was curious about VPC Reachability Analyzer, so I would like to do a simple technical investigation. I will write this article as easy to understand as possible, so I would appreciate it if you would read it.

Target audience

Those who want to know about the behavior of VPC Reachability Analyzer.
Want to know more about usage scenarios

What's VPC Reachability Analyzer

This feature was released in December 2020. The official AWS blog states the following

Amazon Virtual Private Cloud (VPC) allows customers to launch a logically isolated, dedicated virtual network on the AWS cloud. As customers expand their footprint on the cloud and deploy increasingly complex network architectures, network connectivity issues caused by misconfigurations become time-consuming to resolve. We are excited to announce VPC Reachability Analyzer, a network diagnostic tool that helps resolve reachability issues between two endpoints within a VPC or across multiple VPCs.

Blogs

To put it very simply, it might be easier to understand if you think of it as a tool for analyzing the reachability of communication between resources.

The usage fee is $0.10 per use.
Therefore, running it frequently can result in unexpected increases in costs.

In addition, as stated in the official documentation, there are also some points to note regarding load balancers and firewalls.

Docs

Verification details

There are four things I would like to verify this time:

1. VPC Peering in the same region (same account)

2: VPC Peering between different regions (same account)

3. VPC Peering in the same region (different accounts)

4: VPC Peering between different regions (different accounts)

Verification

We will not go into the details of the preparations that were made prior to the verification, but we did set up the VPC and peering settings.

After setting up, we set up the VPC Reachability Analyzer from TEST-A to each peering connection.
The results are as follows:

1. VPC Peering in the same region (same account)

2: VPC Peering between different regions (same account)

3. VPC Peering in the same region (different accounts)

4: VPC Peering between different regions (different accounts)

Impressions

You can check in different regions or in the same region.
Analysis costs $0.10 (per session), but the amount of information obtained is limited
It is unclear which protocol is used by default (probably UDP)

In my personal opinion, as an analysis tool it is expensive and provides little information, so I don't feel there is much value in using VPC Reachability Analyzer alone.

However, I think that combining it with Amazon Q will help speed up the process of troubleshooting communication problems.
(However, I would like to see improvements made to the inability to troubleshoot BGP issues and check the health of the load balancer.)

Since the scope of this verification was limited to AWS resources, I would like to verify whether it is possible to perform analysis that takes into account on-premises environments.

Thank you for reading this article to the end!!

Digression

There were six updates to the VPC Reachability Analyzer.

Forem: Masaki Okuda

Testing AWS DevOps Agent with Multi-Account

Disclaimer

Target Audience

Key Takeaways

About the Test Environment

AWS DevOps Agent Multi-Account Configuration

Testing with AWS DevOps Agent

Insights Gained Through Verification

Insight 1: Configuration itself is not difficult with the guide

Insight 2: There are risks with current specifications when configuring for user environments

Insight 3: Introducing multi-account makes DevOps Agent operations more complex

Future Outlook

Adding Cognito authentication to AWS DevOps Agent

Original Blogs

Notes

Target Audience

Leaning Outcome

Preparation for implementation

Prepare Cognito for AWS DevOps Agent

Login test

Impressions

Additional Note

[Tips] [Podman] What to do if you get an "insufficient space" error when loading an image

Use case

work around

Points to note

Warnig

Summary

Docs

Deep Dive into AWS Cloud WAN Core Network Policy: Configuration, Examples, and Strategy

Deep Dive into AWS Cloud WAN Core Network Policy: Configuration, Examples, and Strategy

Target Audience

Core Network Policy Structure

Core Network Policy Samples

1 Segment + 1 Region

2 Segments + Multiple Regions

When Including Specific Segment Settings

Network Configuration Considering Development Process

For Environments Not Using VPC

Placing a Firewall Between Networks

Policy Strategy Considerations

Summary

PS

[RHEL]Supports upgrading from RHEL9 to RHEL10 on AWS EC2 instances

Table of Contents

Purpose of this article

Target audience

Implementation flow

Part 0: Setup

Preliminary verification

Work details

Post-mortem verification

Impressions

Reference Sites

[AWS]We have summarized the domain costs that can be purchased through AWS Route53 (as of July 5, 2025)

(Reference) How to buy a domain on Route 53

domain cost

Conclusion

Reference site

[AWS]Building an AWS Security Learning Tetris Puzzle Game with Amazon Q Developer CLI

Introduction

Basic Development Approach

Game Overview

Key Features:

Development Architecture & Approach

Directory Structure

Deployment Strategy

Package Configuration

Implementation Challenges

Areas for Improvement

Current Issues:

Future Prospects

Key Takeaways

Technical Stack

Learning Outcomes

Related Resources

[AWS]Hands-on: Building a Simple Web Server with CodeBuild + CodeDeploy (Sphinx)

Introduction

Table of Contents