DEV Community: Rev

Build and Deploy an Automatic Sync Solution for Amazon Bedrock Knowledge Bases

Rev — Sat, 16 May 2026 14:42:27 +0000

Introduction

The AWS Blog post "Build and deploy an automatic sync solution for Amazon Bedrock Knowledge Bases" introduces a solution for automatically synchronizing documents with Amazon Bedrock Knowledge Bases.

This AWS Blog post was published on April 27, 2026. During my validation in May 2026, I encountered two issues: S3 events routed via EventBridge were not being processed correctly, and the status was not being updated even after the Knowledge Base ingestion job completed.

This article documents the fixes I applied to resolve these issues, the validation results, and operational considerations you should be aware of.

References

Overview of the Sample Implementation

Architecture Overview from the AWS Blog

Architecture Diagram

Note: The original architecture diagram in the AWS Blog is low-resolution and hard to read when enlarged, so I recreated it above. The original diagram also lacked lines connecting the Event Processor Lambda and Sync Processor Lambda to DynamoDB, which I have added.

The sample implementation described in the AWS Blog executes the following workflow. As stated in the blog, this solution is designed with service quota limits in mind, and to improve resilience by enabling retries when those limits are exceeded.

Phase 1: Document Change Detection

User uploads/updates/deletes a document in Amazon S3
Amazon EventBridge captures the S3 event and routes it to the Event Processor Lambda
Event Processor Lambda determines the change type (create / update / delete) and records a change entry — including a change_id — in Amazon DynamoDB (TRACKING_TABLE)
Event Processor Lambda sends a change notification message to Amazon SQS

Phase 2: Queuing and Rate Limiting

Amazon SQS buffers the change notification messages and controls throughput to match the StartIngestionJob quota (1 request per 10 seconds)
Sync Processor Lambda receives SQS messages one at a time
Creates job-tracking metadata in Amazon DynamoDB (METADATA_TABLE) and starts an AWS Step Functions workflow

Phase 3: Orchestration via Step Functions

Check Quota Lambda verifies service quotas (5 concurrent per account / 1 concurrent per data source / 1 concurrent per Knowledge Base)
If quotas are exceeded, the workflow waits 5 minutes and retries; otherwise it proceeds
Start Sync Lambda calls the StartIngestionJob API to kick off the sync job and records the job ID in metadata
Monitor Sync Lambda periodically checks the status via GetIngestionJob (waits 60 seconds and re-checks if the job is not yet complete)
On completion, the workflow branches based on success or failure

Phase 4: Knowledge Base Sync Processing

Amazon Bedrock Knowledge Base ingests the entire data source
Documents are converted to vector embeddings and stored in the vector store
Data becomes available for semantic search

Phase 5: Completion Processing, Notification, and Monitoring

Monitor Sync Lambda detects job completion and updates the metadata status
Sets the ingestion_job_id on the corresponding change record in TRACKING_TABLE and marks it as processed
Sends completion/failure notifications via Amazon SNS to email subscribers
Visualizes metrics on an Amazon CloudWatch dashboard and detects anomalies via alarms

Concrete Example: Uploading 50 Files in Bulk

Following the README.md example, the workflow proceeds as follows:

50 S3 events are generated → Event Processor records each change in DynamoDB and sends messages to SQS
SQS delivers messages to Sync Processor at 10-second intervals
Sync Processor starts Step Functions → if quotas allow, kicks off an ingestion job; one job ingests all 50 files (actually the entire data source) at once
After completion, Monitor Sync Lambda updates DynamoDB and sends an SNS notification

As also stated in the README.md Important Note About Amazon Bedrock Knowledge Base Ingestion, the StartIngestionJob operation scans the entire data source — not just the changed files. To ingest at the individual file level, a different API would need to be used. However, this design is intentional because the Knowledge Base's managed sync process determines whether each file is new, modified, or deleted and handles it appropriately.

In this way, the solution is designed to track changes immediately while efficiently batching ingestion within service limits.

Prerequisites and Constraints of the Sample Implementation

Only One Data Source per Knowledge Base

This implementation assumes that there is only one data source under the Knowledge Base. If multiple data sources exist, the implementation uses the first entry returned by the list_data_sources API, but since the order is not guaranteed, an unintended data source may be selected as the sync target. In the code below, maxResults=10 is set but dataSourceSummaries[0] retrieves the first data source:

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/sync_processor_lambda.py#L70-L77

Sync Scope of the Bedrock Knowledge Base Data Source

The scope that StartIngestionJob actually scans and syncs to the Bedrock Knowledge Base is determined by the S3 URI configured in the Bedrock Knowledge Base data source settings — not by the S3KeyPrefix parameter in samconfig.toml. In the code below, S3KeyPrefix is used only as a filter for the EventBridge rule. In other words, if the Bedrock Knowledge Base data source references the entire s3://example-bucket/, even if you specify documents/ as the S3KeyPrefix, any event triggered under documents/ will cause StartIngestionJob to scan all documents under s3://example-bucket/.

To avoid this, you need to align the S3 URI used when building the data source with the S3KeyPrefix.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/samconfig.example.toml#L12

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/template.yaml#L234-L251

Fixes Applied to the Sample Implementation

Fix 1: S3 Events via EventBridge Not Being Processed Correctly

This sample implementation uses an EventBridge rule as the trigger for the Event Processor Lambda. However, the get_change_type() function is implemented to use direct S3 event notifications.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/event_processor_lambda.py#L74-L91

Additionally, the event_name argument of this function references a field called detail.name, but according to the AWS documentation, no such field exists in the EventBridge payload. The correct field to reference is detail-type.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/event_processor_lambda.py#L119

To resolve these issues, I modified the payload reference and the get_change_type() function. The specific changes are here:

https://github.com/revsystem/sample-automatic-sync-for-bedrock-knowledge-bases/pull/3

Fix 2: Metadata in Sync Processor Lambda Not Being Updated Correctly

The Event Processor Lambda generates a change_id and stores it in the autosync-tracking DynamoDB table. However, change_id is not included in the SQS message.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/event_processor_lambda.py#L184-L192

The Monitor Sync Status Lambda references the change_ids field in the message only when the ingestion job reaches COMPLETE status, and uses it to update the autosync-tracking table.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/monitor_sync_lambda.py#L93-L93

The Monitor Sync Status Lambda calls mark_changes_as_processed() only when the ingestion job completes. This function references the change_ids field to update the processed column in the autosync-tracking table. However, since change_ids is not included in the SQS message, processed always remains False.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/monitor_sync_lambda.py#L151-L152

To resolve this, I updated the implementation to include change_id in the SQS message and modified Monitor Sync Status Lambda to handle both change_id and change_ids fields (since the original design intent was unclear, I made it compatible with both). The specific changes are here:

https://github.com/revsystem/sample-automatic-sync-for-bedrock-knowledge-bases/pull/4

Fix 3: Correcting the Quota Value for Concurrent Ingestion Jobs per Account

The README.md and the code state that the quota for Concurrent ingestion jobs per account is 55, but the AWS official documentation shows the correct value is 5.

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/src/check_quota_lambda.py#L26-L27

https://github.com/aws-samples/sample-automatic-sync-for-bedrock-knowledge-bases/blob/22a51f8/README.md?plain=1#L354-L356

To resolve this, I set the Concurrent ingestion jobs per account quota to 5. The specific changes are here:

https://github.com/revsystem/sample-automatic-sync-for-bedrock-knowledge-bases/pull/5

Environment Setup

The code used in this article is published on GitHub:

https://github.com/revsystem/sample-automatic-sync-for-bedrock-knowledge-bases

All AWS resources in this guide are created in the us-east-1 region. If you use a different region, substitute the appropriate region name throughout.

The S3 bucket and Bedrock Knowledge Base are created manually; all other resources are created using the AWS SAM CLI.

Creating the S3 Buckets

You will create three S3 buckets:

One for storing Bedrock Knowledge Base documents
One for S3 server access logs
One for storing text extracted from images in multimodal RAG (optional)

The S3 server access log bucket is not strictly required, but as noted in the Amazon S3 Bucket Security Requirements section of the README, enabling S3 server access logging is recommended for auditing purposes.

Below are the steps for creating the document storage bucket for Bedrock Knowledge Base.

S3 Bucket for Bedrock Knowledge Base Documents

Create an S3 bucket for storing Bedrock Knowledge Base documents. Following the README, enable Block Public Access settings, Default Encryption, and Versioning.

Setting	Value
Bucket type	`General purpose`
Bucket namespace	`Account Regional namespace`
Bucket name prefix	`automatic-sync-for-bedrock-kb`
Block public access settings for this bucket	`Block all public access`
Bucket Versioning	`Enable`
Default Encryption	`Server-side encryption with Amazon S3-managed keys (SSE-S3)`

After creating the bucket, open the Server access logging block in the Properties tab and set it to Enable. Specify the log bucket you created as the destination.

Also in the Properties tab, open the Amazon EventBridge block and set "Send notifications to Amazon EventBridge for all events in this bucket" to On.

Next, open the Bucket Policy block in the Permissions tab and configure the bucket policy as shown below. Replace Resource with the ARN of your Bedrock Knowledge Base document storage bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictToTLSRequestsOnly",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::automatic-sync-for-bedrock-kb-<YOUR_ACCOUNT_ID>-us-east-1-an",
                "arn:aws:s3:::automatic-sync-for-bedrock-kb-<YOUR_ACCOUNT_ID>-us-east-1-an/*"
            ],
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Create a folder named documents inside this bucket for uploading documents.

Creating the Bedrock Knowledge Base

Note: The choices made here — such as Parsing strategy and Embedding model — are not essential to validating the automatic sync solution. As long as the S3 bucket is correctly configured in the data source, the rest can use default settings. For cost efficiency, I recommend selecting S3 Vectors as the Vector store type.

Follow the Knowledge Base creation wizard and select Knowledge Base with vector store.

Set the Knowledge Base name to sample-automatic-sync-for-bedrock.

Select Amazon S3 as the data source type.

Set the data source name to sample-automatic-sync-for-bedrock-data-source. For the S3 URI, specify the path to the document storage bucket you created earlier.

Select Foundation models as a parser for the Parsing strategy to enable handling of PDFs and rich documents.

For the parser model, select Nova Pro 1.0. While the model selection screen shows various options, only On-demand profile models can be selected. Cross-region inference profiles and global inference profiles cannot be selected — attempting to use them will result in an error during Knowledge Base creation.

For the Chunking strategy, select Semantic chunking. Set Max tokens size for a chunk to 512. The maximum input token count for Cohere Embed Multilingual v3 is 512 tokens. If the chunk size exceeds this, text will be truncated during embedding, so Max tokens size for a chunk must be set to 512 or lower.

Select Cohere Embed Multilingual v3 as the Embeddings model. This model is known for its strong multilingual embedding quality.

For Vector store, select Quick create a new vector store, and for Vector store type, select Amazon S3 Vectors.

For Multimodal storage destination, specify the S3 bucket for storing text extracted from images in multimodal RAG. This is optional and can be left unconfigured.

Deployment

Clone the GitHub repository:

git clone https://github.com/revsystem/sample-automatic-sync-for-bedrock-knowledge-bases.git

Navigate to the repository root directory:

cd sample-automatic-sync-for-bedrock-knowledge-bases

Copy the sample configuration file:

cp samconfig.example.toml samconfig.toml

vi samconfig.toml

Parameter	Value
KnowledgeBaseId	The ID of your Bedrock Knowledge Base
S3BucketName	The name of your document storage bucket (e.g. `automatic-sync-for-bedrock-kb-<YOUR_ACCOUNT_ID>-us-east-1-an`)
S3KeyPrefix	The folder name inside the document storage bucket (e.g. `documents`)
NotificationsEmail	Email address for notifications (optional)
LambdaMemorySize	Lambda memory size (optional)
LambdaTimeout	Lambda timeout duration (optional)

# Example samconfig.toml.
version = 0.1

[default.deploy.parameters]
stack_name = "autosync"
resolve_s3 = true
s3_prefix = "autosync"
region = "us-east-1"
confirm_changeset = true
capabilities = "CAPABILITY_IAM"
disable_rollback = true
parameter_overrides = "KnowledgeBaseId=\"<your-knowledge-base-id>\" S3BucketName=\"<your-s3-bucket-name>\" S3KeyPrefix=\"<optional-prefix>\" NotificationsEmail=\"<optional-email>\" LambdaMemorySize=\"256\" LambdaTimeout=\"60\""
image_repositories = []

Run the deployment:

sam build
sam deploy --guided --profile {YOUR_PROFILE} --region {YOUR_REGION}

With the --guided option, the CLI will prompt you as follows:

Setting default arguments for 'sam deploy'
=========================================
Stack Name [autosync]:
AWS Region [us-east-1]:
Parameter KnowledgeBaseId [<YOUR_KNOWLEDGE_BASE_ID>]:
Parameter S3BucketName [<YOUR_S3_BUCKET_NAME>]:
Parameter S3KeyPrefix [<YOUR_S3_KEY_PREFIX>]:
Parameter NotificationsEmail [<YOUR_EMAIL_ADDRESS>]:
Parameter LambdaMemorySize [256]:
Parameter LambdaTimeout [60]:
#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
Confirm changes before deploy [Y/n]: Y
#SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation [Y/n]: Y
#Preserves the state of previously provisioned resources when an operation fails
Disable rollback [Y/n]: Y
Save arguments to configuration file [Y/n]: Y
SAM configuration file [samconfig.toml]:
SAM configuration environment [default]:

A successful deployment will display the following message in your terminal:

Successfully created/updated stack - autosync in us-east-1

For more details on deploying and troubleshooting with the AWS SAM CLI, refer to README-SAM.md.

SNS Subscription Confirmation

During deployment, an SNS subscription is created. This subscription is used to receive notifications when documents are uploaded or deleted.

When the subscription is created, an email like the following will be sent to the NotificationsEmail address:

Subject: AWS Notification - Subscription Confirmation

You have chosen to subscribe to the topic:
arn:aws:sns:us-east-1:<YOUR_ACCOUNT_ID>:autosync-notifications

To confirm this subscription, click or visit the link below (If this was in error no action is necessary):
Confirm subscription

Please do not reply directly to this email. If you wish to remove yourself from receiving all future SNS subscription confirmation requests please send an email to sns-opt-out

Click Confirm subscription to activate the SNS subscription. Be careful not to accidentally click the unsubscribe link.

The subscription confirmation email may contain an unsubscribe link. Clicking this link immediately cancels the subscription. Corporate email security systems or spam filters may automatically open links in incoming emails to inspect them, potentially triggering the unsubscribe link unintentionally.

To prevent this, you should confirm the SNS subscription via the AWS Management Console or AWS CLI, as described in this article:

https://repost.aws/knowledge-center/prevent-unsubscribe-all-sns-topic

Verification

Uploading a Document

Upload a document using the aws s3 cp command or from the S3 Management Console:

aws s3 cp {YOUR_DOCUMENT_PATH} s3://{YOUR_S3_BUCKET_NAME}/{YOUR_S3_KEY_PREFIX}/

Verifying Document Sync

You can verify document sync from the Bedrock Knowledge Base dashboard. The sync history for the data source is shown in Sync history.

If the SNS subscription is active, a message like the following will be sent when the ingestion job completes:

Subject: Bedrock KB Sync Job COMPLETE

{
  "knowledge_base_id": "<YOUR_KNOWLEDGE_BASE_ID>",
  "job_id": "<YOUR_JOB_ID>",
  "status": "COMPLETE",
  "statistics": {
    "numberOfDocumentsDeleted": 0,
    "numberOfDocumentsFailed": 0,
    "numberOfDocumentsScanned": 1,
    "numberOfMetadataDocumentsModified": 0,
    "numberOfMetadataDocumentsScanned": 0,
    "numberOfModifiedDocumentsIndexed": 0,
    "numberOfNewDocumentsIndexed": 1
  },
  "processed_changes": 1
}

Checking DynamoDB Data

The DynamoDB table names are autosync-tracking and autosync-metadata.

aws dynamodb scan --table-name autosync-tracking --profile {YOUR_PROFILE} --region {YOUR_REGION}
aws dynamodb scan --table-name autosync-metadata --profile {YOUR_PROFILE} --region {YOUR_REGION}

Example output from the autosync-tracking table. The change_type field records deletions and new additions:

{
    "Items": [
        {
            "knowledge_base_id": {
                "S": "<YOUR_KNOWLEDGE_BASE_ID>"
            },
            "event_time": {
                "S": "2026-05-10T17:14:43Z"
            },
            "ingestion_job_id": {
                "S": "KGF5YGBN2P"
            },
            "processed": {
                "BOOL": true
            },
            "timestamp": {
                "N": "1778433285.169089"
            },
            "bucket": {
                "S": "<YOUR_S3_BUCKET_NAME>"
            },
            "change_type": {
                "S": "delete"
            },
            "key": {
                "S": "documents/n1120000.pdf"
            },
            "change_id": {
                "S": "4bc82a1e-56da-4f13-8d0e-a2db399aca8b"
            }
        },
        {
            "knowledge_base_id": {
                "S": "<YOUR_KNOWLEDGE_BASE_ID>"
            },
            "event_time": {
                "S": "2026-05-10T17:15:32Z"
            },
            "ingestion_job_id": {
                "S": "YGYDOSMKQR"
            },
            "processed": {
                "BOOL": true
            },
            "timestamp": {
                "N": "1778433333.72125"
            },
            "bucket": {
                "S": "<YOUR_S3_BUCKET_NAME>"
            },
            "change_type": {
                "S": "create"
            },
            "key": {
                "S": "documents/n1120000.pdf"
            },
            "change_id": {
                "S": "07b7b739-d44f-4a35-aa5c-8bc1fa104b01"
            }
        },
...
    ],
    "Count": 10,
    "ScannedCount": 10,
    "ConsumedCapacity": null
}

Checking Logs

Check logs in CloudWatch Logs. Logs are output to log groups matching /aws/lambda/autosync-*.

You can also check the status and metrics for each resource in the EventBridge, Step Functions, and Lambda Management Consoles.

Conclusion

I validated the sample implementation introduced in the AWS Blog and confirmed its behavior end-to-end.

In this sample implementation, when a file is uploaded, updated, or deleted in S3, the Knowledge Base sync API (StartIngestionJob) is automatically invoked, ensuring reliable ingestion while respecting service quotas.
The design — using EventBridge to detect S3 events, SQS to buffer and deliver messages, and Step Functions for orchestration — is highly efficient. Change tracking via DynamoDB also makes state management straightforward.

While a few fixes were necessary due to discrepancies between the implementation and the specification, the sample implementation provided a clear picture of how automatic sync works end-to-end.

Setting Up an L2TP/IPsec Remote Access VPN on EdgeRouter X

Rev — Tue, 28 Apr 2026 15:46:56 +0000

Introduction

In the previous article, Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X, I built a system that periodically runs a DDNS client on the EdgeRouter X to keep a Route 53 DNS record in sync with the global IP address assigned to its WAN interface. This made it possible to associate an FQDN with the dynamically changing global IP address. In this article, I use that setup to connect to the EdgeRouter X via remote access VPN.

References

Test Environment

Tested on EdgeRouter X (ER-X) firmware 3.0.1.

Network Topology

The diagram below is a simplified view of the configuration that connects Site A and Site B via VPN.

graph LR
    subgraph SiteA["Site A (192.168.10.0/24)"]
        PC[PC] --- L2SWA[L2 Switch] --- RouterA[Router]
    end

    subgraph SiteB["Site B (192.168.1.0/24)"]
        ERX[EdgeRouter X] --- L2SW[L2 Switch]
        L2SW --- NAS[NAS]
        L2SW --- RPI[Raspberry Pi]
        L2SW --- AP[Wireless AP]
        AP -.-|Wireless| IoT1[IoT Device 1]
        AP -.-|Wireless| IoT2[IoT Device 2]
        AP -.-|Wireless| IoT3[IoT Device 3]
    end

    RouterA ===|VPN| ERX

Configuring L2TP/IPsec

I configured L2TP/IPsec by following EdgeRouter X – 6. リモートアクセス VPN (L2TP).

Open the CLI window from the EdgeRouter X GUI, or access the router via SSH.

  _____    _
 | ____|__| | __ _  ___          (c) 2010-2023
 |  _| / _  |/ _  |/ _ \         Ubiquiti Inc.
 | |__| (_| | (_| |  __/
 |_____\__._|\__. |\___|         https://www.ui.com
             |___/

Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

Enter configuration mode:

configure

In configuration mode, run the following commands to configure L2TP/IPsec:

## Basic IPsec configuration
set vpn ipsec ipsec-interfaces interface eth0
set vpn ipsec nat-networks allowed-network 0.0.0.0/0
set vpn ipsec nat-traversal enable
set vpn ipsec auto-firewall-nat-exclude enable

## Specify that the L2TP WAN-side IP address is assigned via DHCP
set vpn l2tp remote-access dhcp-interface eth0

## Specify the IP address range assigned to L2TP clients
set vpn l2tp remote-access client-ip-pool start 192.168.1.100
set vpn l2tp remote-access client-ip-pool stop 192.168.1.200

## Set the L2TP "secret"
## Replace YOUR_SECRET with any password of your choice
set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret
set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret YOUR_SECRET
set vpn l2tp remote-access ipsec-settings ike-lifetime 3600

## Set L2TP client authentication to local
set vpn l2tp remote-access authentication mode local

## Set the L2TP client username and password
## Replace YOUR_USERNAME and YOUR_PASSWORD with your values
set vpn l2tp remote-access authentication local-users username YOUR_USERNAME password YOUR_PASSWORD

## Set the L2TP MTU conservatively
set vpn l2tp remote-access mtu 1280

## Set the DNS used by L2TP clients to the router itself and Google DNS
set vpn l2tp remote-access dns-servers server-1 192.168.1.1
set vpn l2tp remote-access dns-servers server-2 8.8.8.8

## Enable DNS forwarding on the router so that L2TP clients can use the router's DNS
set service dns forwarding listen-on lo

commit
save

Firewall Configuration on the WAN-Side Interface

Next, configure the firewall so that L2TP/IPsec connections from the WAN side can reach the EdgeRouter X. This is also based on the sites listed in the References section.

Log in to the EdgeRouter X GUI as an administrator and open the firewall settings. Click the Firewall/NAT icon in the left-side menu.

Click the Firewall Policies tab → Actions for WAN_LOCAL → Edit Ruleset.

Click Add New Rule. (The screenshot below shows the state after the rules described below have already been added.)

Click the Basic tab. Enter any name in Description. Here, I use Allow L2TP. For Action, select Accept, and for Protocol, select UDP.

Then click the Destination tab and enter 500,1701,4500 in Port. Finally, click Save.

Next, click Add New Rule again.

Click the Basic tab. Enter any name in Description. Here, I use Allow ESP. For Action, select Accept. For Protocol, select Choose a protocol by name, and choose esp from the dropdown. Finally, click Save.

Move the two newly added rules so they sit between the existing Allow established/related rule and the Drop invalid state rule. You can drag and drop each rule by hovering over it.

Configuring the VPN Client on Windows 11

My Windows 11 system is set to English, so the menus and buttons appear in English. The screen layout and button positions are the same in the Japanese version, so substitute as needed.

In the Settings app, click Network & Internet → VPN → Add VPN.

Fill in each field by referring to the table below.

Field	Value
VPN Type	`L2TP/IPsec with pre-shared key`
Type of sign-in info	`Username and password`
Connection name	Any name
Server name or address	The FQDN configured via DDNS
Pre-shared key	The `YOUR_SECRET` set in the L2TP/IPsec configuration
Username	The `YOUR_USERNAME` set in the L2TP/IPsec configuration
Password	The `YOUR_PASSWORD` set in the L2TP/IPsec configuration

In the VPN connection you just created, click Advanced options.

Click Edit next to More VPN properties.

Click the Security tab, select Allow these protocols, and check Microsoft CHAP Version 2 (MS-CHAP v2).

Click the Networking tab, select Internet Protocol Version 4 (TCP/IPv4), and click Properties.

On the General tab, click Advanced.

On the IP Settings tab, uncheck Use default gateway on remote network.

Verifying the Connection

Click Connect.

When the connection succeeds, the connection details are displayed as follows.

If you can reach network devices behind the VPN, such as a NAS, the connection is working. Internet traffic is routed through the WAN side of the EdgeRouter X. You can also access the LAN-side IP address of the EdgeRouter X from the VPN client to check the status of the remote site.

Conclusion

In this article, I covered how to connect to an EdgeRouter X via remote access VPN, specifically:

L2TP/IPsec configuration on the EdgeRouter X
Firewall configuration on the WAN-side interface
VPN client configuration on Windows 11

The Windows 11 VPN client setup was a bit involved. The VPN properties span several screens, and a few options are not particularly intuitive.

For EdgeRouter X configuration in general, the EdgeRouter X がすごい series is a great reference. It contains many practical configuration examples, so I recommend it as a reference.

By combining the previous article, Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X, with the configuration described here, you can connect to your EdgeRouter X via remote access VPN. I hope this article is helpful.

Translation notes

A few stylistic decisions I made to match your previous dev.to post:

Headings: Used ## Introduction, ## References, ## Test Environment, and ## Conclusion, identical to the prior post.
Voice: First-person ("I built", "I use") for narrative sections and imperative ("Click", "Run") for procedural steps, matching your earlier article.
Terminology: Kept "shared secret", "Lambda function URL", "FQDN", "WAN side" consistent with the previous translation. "拠点 A / 拠点 B" → "Site A / Site B" to match common networking phrasing.
References: Listed as bullet points with <>-wrapped URLs, the same format as before.
Title: Used Setting Up an L2TP/IPsec Remote Access VPN on EdgeRouter X to mirror the gerund + "on EdgeRouter X" style of the prior title (Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X). If you prefer something closer to the literal Japanese, Connecting to EdgeRouter X via Remote Access VPN also works.
Image links: Left the Qiita-hosted image URLs intact. They are publicly accessible from S3, so they should render on dev.to as-is. If you want to host them on dev.to instead, you'll need to re-upload via the dev.to editor.

Let me know if you'd like a different title, a more literal translation of any specific section, or if you want me to save this as a file in the repo (e.g., outside public/ so the Qiita CLI doesn't pick it up).

I tried out "1-bit LLM Bonsai" using the Linux terminal app on my Google Pixel 7a.

Rev — Wed, 15 Apr 2026 15:59:09 +0000

Introduction

I tried running PrismML's 1-bit LLMs, Bonsai-8B and Bonsai-1.7B, on the Linux terminal app on a Google Pixel 7a. Bonsai-8B has a compact model size of just 1.15GB and reportedly runs on a Raspberry Pi 4B. Since it was described as "An 8-billion-parameter LLM that 'runs on a smartphone' — '1-bit Bonsai' at 1.15GB claiming production-level performance draws attention," I decided to test whether it actually runs on a smartphone.

References

https://prismml.com/news/bonsai-8b

https://qiita.com/y0kud4/items/3f7faeea52d7eec01b0f

https://qiita.com/moritalous/items/96cdc8bcd48d8a193556

https://qiita.com/revsystem/items/7ad150a7f99aaea27691

https://zenn.dev/kun432/scraps/ce16474a3be277

Test Environment

Google Pixel 7a
Android 16
Linux terminal

Setup

Enabling the Linux Terminal app

To enable the Linux terminal app on a Pixel device, refer to the article Running AWS Bedrock API Using Google Pixel's Linux Terminal app.

Building llama.cpp

Build llama.cpp by following this article:

https://qiita.com/moritalous/items/96cdc8bcd48d8a193556

Install the packages required for the build:

sudo apt update
sudo apt install -y git cmake build-essential libopenblas-dev pkg-config openssl libssl-dev

Clone the llama.cpp fork maintained by PrismML:

git clone https://github.com/PrismML-Eng/llama.cpp && cd llama.cpp

Build the project. This takes approximately 15 minutes.

cmake -B build -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=OpenBLAS
cmake --build build --config Release -j2

Running the Models

Since the Pixel's Linux terminal app does not support Japanese input, I used a simple prompt: 'hello'. Both models produced streaming output too slowly to be practical on the Pixel's Linux terminal app. Additionally, the Linux terminal app crashed frequently, requiring a full recovery each time, so I was only able to test the following two patterns.

Bonsai-8B

The first run takes longer because the model needs to be downloaded. When the context size was not specified with -c, a Segmentation fault occurred. Following the advice at https://zenn.dev/kun432/scraps/ce16474a3be277#comment-3592ca1fdb0075, I set the context size to 32784.

./build/bin/llama-cli \
  -hf prism-ml/Bonsai-8B-gguf \
  -p "hello" \
  -c 32784

The results were as follows:
[Prompt: 1.5 t/s | Generation: 0.1 t/s]

Bonsai-1.7B

Similarly, I ran Bonsai-1.7B. This model did not require specifying the context size.

./build/bin/llama-cli \
  -hf prism-ml/Bonsai-1.7B-gguf \
  -p "hello"

The results were as follows:
[Prompt: 4.4 t/s | Generation: 1.5 t/s]

Conclusion

I tested Bonsai-8B and Bonsai-1.7B on the Google Pixel 7a's Linux terminal app. I confirmed that both models run. However, despite being lightweight models, the devices' performance was insufficient for practical use. That said, the fact that the build completed successfully was an interesting finding.

Running an AWS Lambda + Route 53 DDNS Client on EdgeRouter X

Rev — Fri, 10 Apr 2026 18:07:44 +0000

Introduction

My home network is assigned a dynamic global IP address by the ISP, so DDNS is essential for inbound connections. I built a system that periodically updates DNS records from an EdgeRouter X using the serverless DDNS solution (Lambda + Route 53 + DynamoDB) published by AWS.

This article covers the steps from setting up the AWS environment to configuring the client on the EdgeRouter X and verifying operation.

The ultimate goal is to connect to the EdgeRouter X via remote access VPN using DDNS, but first we need to build the DDNS infrastructure.

For details on how the solution works, see Building a Serverless Dynamic DNS System with AWS.

References

Test Environment

Tested on EdgeRouter X (ER-X) firmware 3.0.1.

About the Forked Repository

I forked the official AWS repository awslabs/route53-dynamic-dns-with-lambda and created revsystem/route53-dynamic-dns-with-lambda.

The fork includes the following changes, organized by branch:

fix/lambda-security: Fixed security vulnerabilities in the Lambda function (timing attack, input validation, exception handling, information leakage). Improved code quality (resolved function name conflicts, unified return types, moved boto3 to module level, removed Python 2 compatibility code).
fix/cdk-improvements: Tightened IAM policy resource restrictions (Route 53, CloudWatch Logs). Changed DynamoDB RemovalPolicy to RETAIN and billing mode to PAY_PER_REQUEST. Set Lambda log retention period and reserved concurrency. Removed unused imports and improved CDK-Nag suppressions.
fix/client-scripts: Fixed variable quoting, operator errors, deprecated command substitutions, and JSON construction safety in dyndns.sh. Added JSON injection prevention, improved exception handling, and secret masking in newrecord.py.
test/add-tests: Completely rewrote the unimplemented tests (all assertions were commented out). Added 7 CDK stack tests and 15 Lambda unit tests (22 total). Covers GET/SET normal cases, validation, authentication, and error handling.
docs/fix-typos-and-docs: Fixed typos in README.md and invocation.md. Updated response examples in invocation.md to match the Lambda implementation. Added version range specification to requirements.txt. Updated cdk.json feature flags.
fix/cdk-nag-log-retention: Added CDK-Nag suppressions for the custom resource Lambda auto-generated by the log_retention setting. Since the CDK internal resource cannot be modified, the suppression includes an applies_to clause with documented rationale.
feat/manage-record-script: Created managerecord.py to allow viewing configuration, immediately changing TTL, and deleting records via subcommands.

CDK-Nag is a tool that automatically checks CDK applications against security and compliance best practices. Error-level violations cause cdk synth to fail, blocking deployment. Warning-level violations do not block deployment. To intentionally exempt a rule, you set a suppression with a documented reason.

Setting Up the AWS Environment

Prerequisites

A domain hosted in Route 53
Permissions to operate Lambda, DynamoDB, and Route 53
An environment with the AWS CLI available

Architecture Overview

[Operator]
  |
  |-- newrecord.py (create/update) --> DynamoDB (hostname -> JSON)
  |
[EdgeRouter X]
  |-- dyndns.sh --> Lambda URL --> Lambda --> DynamoDB + Route 53

Deploying the CDK Stack

This solution is deployed using AWS CDK. The Lambda function, DynamoDB table, and IAM roles are created at once.

Clone the repository:

git clone https://github.com/revsystem/route53-dynamic-dns-with-lambda.git

cd route53-dynamic-dns-with-lambda

Install the Python dependencies:

pip install -r requirements.txt

Bootstrap is required the first time you deploy to a given account and region combination (environment). If the account is the same but the region differs, run it separately for each region.

cdk bootstrap

If you are told the CDK CLI version is too old, update it:

sudo npm install -g aws-cdk

Deploy the stack:

cdk deploy

When the deployment completes, the Lambda function URL is output. You will use this URL in the client configuration later.

Configuring the DNS Record

Run newrecord.py to interactively configure the Route 53 hosted zone and record set. The configuration is saved to the DynamoDB table.

python3 newrecord.py

If your AWS profile or region differs from the defaults, specify the environment variables:

AWS_PROFILE=production AWS_DEFAULT_REGION=us-east-1 python3 newrecord.py

Enter the hosted zone name (e.g., example.jp), hostname (e.g., router.example.jp), TTL (default 60), and shared secret in order. If the hosted zone does not exist, you will be asked whether to create it.

The shared secret, together with the Lambda function URL, is the key to authentication. Set it to a sufficiently complex string. Using a random string generated by openssl rand -hex 32 is recommended.

Once the input is complete, a confirmation is displayed:

##############################################
#                                            #
# The following configuration will be saved: #
#                                            #
  Host name:  router.example.jp
  Hosted zone id: ZXXXXXXXXXXXXXXXXXXXXXXX
  Record set TTL: 60
  Secret: ********
#                                            #
#      do you want to continue? (y/n)        #
#                                            #
##############################################

When the setup is complete, the parameters needed to run dyndns.sh are displayed:

./dyndns.sh -m set -u https://XXXXXXXXXX.lambda-url.REGION.on.aws/ -h router.example.jp -s <YOUR_SECRET>

Take note of the Lambda function URL and shared secret. They will be used in the EdgeRouter X configuration.

Verification

Test-run dyndns.sh to verify the integration between the Lambda function and Route 53. On environments that use shasum, you may need to install perl-Digest-SHA.

sudo yum install perl-Digest-SHA

Test the IP address retrieval:

./dyndns.sh -m get -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/"

If a public IP address is returned, the Lambda function is working correctly.

DDNS Client Implementation Approach

EdgeRouter X has a built-in DDNS feature that can be configured with set service dns dynamic. Internally it runs ddclient and supports standard protocols such as dyndns2 and cloudflare.

However, the AWS DDNS solution uses a protocol that sends an HTTP POST with JSON to a Lambda function URL and performs application-level authentication using a SHA-256 hash. The Lambda function URL itself is published with authentication type NONE (public access), and authentication is achieved by verifying the hash value included in the request within the Lambda function. Since ddclient does not have a definition for this protocol, the built-in DDNS feature cannot be used.

Instead, we periodically execute the shell script dyndns.sh provided in the repository using the EdgeRouter X task scheduler.

Note: The following steps are executed on the EdgeRouter X CLI or via SSH.

Deploying dyndns.sh

SSH into the EdgeRouter X and download the script. Files placed under /config/scripts/ are preserved after firmware upgrades.

curl -o /config/scripts/dyndns.sh https://raw.githubusercontent.com/revsystem/route53-dynamic-dns-with-lambda/master/dyndns.sh

chmod +x /config/scripts/dyndns.sh

dyndns.sh internally uses shasum -a 256 to generate the authentication hash. Firmware 3.0.1 includes the shasum command, so no script modification was needed. If shasum is not found on older firmware, you can replace the relevant line with openssl dgst -sha256.

Verifying dyndns.sh

IP Address Retrieval Check

First, use the -m get mode to verify that the connection to the Lambda function URL and IP address retrieval succeed.

/config/scripts/dyndns.sh -m get -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/"

If a global IP address is returned, the network connection and Lambda function are working correctly. If nothing is returned, check the Lambda function URL, DNS resolution, or firewall rules.

DNS Record Update Check

Next, use the -m set mode to actually update the Route 53 record.

/config/scripts/dyndns.sh -m set \
  -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/" \
  -h "router.example.jp" \
  -s "<YOUR_SECRET>"

On success, a response like the following is returned:

{
    "return_status": "success",
    "return_message": "router.example.jp has been updated to XXX.XXX.XXX.XXX",
    "status_code": "201"
}

If the IP address has not changed, the following response is returned. This is also normal behavior.

{
    "return_status": "success",
    "return_message": "Your IP address matches the current Route53 DNS record.",
    "status_code": "200"
}

Creating a Wrapper Script

Since dyndns.sh operates via command-line arguments, prepare a wrapper script for the task scheduler to call.

cat << 'EOF' > /config/scripts/run-ddns.sh
#!/bin/bash
/config/scripts/dyndns.sh \
  -m set \
  -u "https://XXXXXXXXXX.lambda-url.REGION.on.aws/" \
  -h "router.example.jp" \
  -s "<YOUR_SECRET>" \
  >> /var/log/aws-ddns.log 2>&1
EOF

chmod +x /config/scripts/run-ddns.sh

Registering with the Task Scheduler

Configure the task scheduler in EdgeOS CLI configuration mode:

configure
set system task-scheduler task aws-ddns interval 300m
set system task-scheduler task aws-ddns executable path /config/scripts/run-ddns.sh
commit
save
exit

This runs run-ddns.sh every 300 minutes (5 hours). Adjust the interval value based on how frequently your ISP changes your IP address.

Verifying the Configuration

Check the task scheduler registration:

configure
show system task-scheduler
exit

Verifying the DNS Response

Verify that the record has been correctly reflected in Route 53. There is one caveat here: the EdgeRouter X CLI is Vyatta-based and interprets ? as a help invocation key. This behavior persists even in operational mode (the $ prompt). Therefore, you cannot paste a URL containing ? directly into the CLI.

To work around this, create and execute a script file with vi. Using echo does not help because the CLI still interprets the ?.

vi /tmp/dnscheck.sh

Write the following content and save:

curl -s "https://dns.google/resolve?name=router.example.jp&type=A"

Execute the script:

sh /tmp/dnscheck.sh

If everything is working, JSON like the following is returned:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": false,
  "CD": false,
  "Question": [{"name": "router.example.jp.", "type": 1}],
  "Answer": [{"name": "router.example.jp.", "type": 1, "TTL": 60, "data": "XXX.XXX.XXX.XXX"}],
  "Comment": "Response from 205.251.196.248."
}

If the IP address in the data field under Answer matches the WAN interface IP address, the DDNS setup is working correctly. You can check the WAN IP address with show interfaces. The 205.251.196.248 in the Comment is a Route 53 nameserver IP address, indicating that the record is being served from the AWS side.

If you want to use dig or nslookup, you can install the dnsutils package, but the EdgeRouter X has limited storage (256MB NAND). For simple DNS verification, the method above is sufficient, and it is best to avoid installing unnecessary packages.

ping can also be used as a verification method that does not involve ?:

ping router.example.jp

The first line shows PING router.example.jp (XXX.XXX.XXX.XXX), revealing the resolved IP address. When run from the LAN behind the router, the ping targets the router's own WAN IP address, so no reply is returned. Stop with Ctrl+C. Use this only to verify whether name resolution succeeds.

Checking the Logs

The execution results of run-ddns.sh are appended to /var/log/aws-ddns.log.

cat /var/log/aws-ddns.log

Task scheduler execution may not be recorded in the system log. Verify scheduler operation by checking the log output in /var/log/aws-ddns.log.

Managing DNS Records

Use managerecord.py to view, modify, or delete configurations set by newrecord.py. The DynamoDB table name is automatically resolved from CloudFormation, so you do not need to look it up manually.

Reconfiguring / Changing the Shared Secret

Re-running newrecord.py overwrites the configuration for the same hostname. Use this method to change the TTL or shared secret.

Viewing the Current Configuration

python3 managerecord.py show router.example.jp

Displays the configuration stored in DynamoDB along with the current IP and TTL from Route 53.

Hostname        : router.example.jp
Hosted zone ID  : ZXXXXXXXXXXXXXXXXXXXXXXX
TTL             : 60
Secret          : ********
Current IP      : XXX.XXX.XXX.XXX
Route 53 TTL    : 60

Immediately Applying a TTL Change

The Lambda function only checks for IP address changes and does not compare TTL values. Therefore, the Route 53 TTL is not updated unless the IP address changes. To apply a TTL change immediately, use the update-ttl subcommand.

python3 managerecord.py update-ttl router.example.jp 300

This updates both the DynamoDB TTL and the Route 53 record simultaneously. From the next IP address change onward, the updated TTL is automatically applied.

Deleting a Record

To delete only the DynamoDB record:

python3 managerecord.py delete router.example.jp

To also delete the Route 53 DNS record, add --also-route53:

python3 managerecord.py delete --also-route53 router.example.jp

In both cases, a confirmation prompt is displayed before execution.

Conclusion

I built a DDNS client that updates Route 53 DNS records from an EdgeRouter X using AWS Lambda + Route 53 + DynamoDB. This allows DDNS operation entirely within the AWS ecosystem, without depending on external DDNS services.

Since this solution retrieves the IP address and calls the Lambda function URL using curl in a shell script, it can be adapted to other network devices or servers that support curl and a scheduler such as cron.

The AWS repository does not provide a way to modify or delete configurations, so I created managerecord.py to fill that gap. It supports viewing configurations, immediately changing TTL, and deleting records via subcommands.