DEV Community: Jonathan Wong

IEC BC x ISACA Vancouver Cybersecurity Networking Event

Jonathan Wong — Thu, 30 Apr 2026 23:04:57 +0000

At the IEC BC x ISACA Vancouver Cybersecurity Networking Event this week, newcomers, experienced professionals, and employers had the chance to connect meaningfully. Thank you to Immigrant Employment Council of BC, ISACA Vancouver Chapter and Vancouver Community College (VCC) for making this possible.

The speaker shared a clear breakdown of certification pathways in cybersecurity.

Foundational certifications include ISC2 Certified in Cybersecurity (CC).

Intermediate tracks include CISA, CCSP, and AWS Security.

Senior level designations include CISSP and CISM, which reflect broader responsibility across governance, architecture, and organizational risk.

The speaker also highlighted the challenges overseas trained professionals face in the Vancouver job market. Many arrive with strong technical backgrounds, yet still need to navigate local hiring expectations, credential recognition, and the persistent “Canadian experience” requirement. Hearing this acknowledged openly was valuable for many attendees.

Another insight from the talk focused on how companies are adopting AI inside their organizational structure. The risk is not only technical. For SMEs with fewer than 50 employees, restructuring teams too quickly around AI can create instability and unclear ownership.

One final note for anyone exploring cybersecurity.

The free ISC2 Certified in Cybersecurity (CC) enrollment ends on May 20, 2026.

If you are considering a first step into the field, this is a good opportunity before the window closes.

About the Author

Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.

Connect with me on LinkedIn

The post IEC BC x ISACA Vancouver Cybersecurity Networking Event appeared first on Behind the Build.

Sakura Migration

Jonathan Wong — Sun, 26 Apr 2026 05:03:15 +0000

Not long ago I visited UBC, where the Sakura blossoms were in full bloom again.

It reminded me of the first time I saw them decades ago in Japan, when I was working inside a 200‑person IT department. That was the on‑prem era. Everything lived in racks and server rooms. Everything felt stable, predictable, and physical. I thought my career would stay that way.

But life moves. Sometimes quietly. Sometimes without a plan.

Later I met Notey, and that was the beginning of my startup journey. I moved from enterprise structure to startup speed. From on‑prem systems to the cloud. From a single role to wearing multiple hats. That was my first migration, not geographical but mental. A shift in how I saw technology, teams, and myself.

I moved to Boxful next. Built an MVP that helped secure funding. Shifted from development to product. From proprietary stacks to open source. From execution to ownership. Another migration. Another environment. Another version of myself.

After that chapter, I joined venture builders, Flatiron, helping capital create new startups. Moving from building one company to helping many. From operator to enabler. From solving problems to designing systems that solve problems. Another migration.

Eventually, the Startup Visa program brought me to Vancouver. From East Asia to North America. From familiar ground to a new ecosystem. From the world I grew up into the world I chose. A migration across continents, but also across identity.

Walking past the students on UBC’s campus takes me back to when I was an undergraduate, excited about my first Yahoo email. At the time, I believed I would be happy coding every day. But the world kept shifting. We moved from desktop to cloud, then to mobile, and now to AI, where skills can be downloaded and coding itself is being redefined. Another migration. Another environment. Another identity.

Looking back, none of these migrations were planned. They happened one step at a time. Each one pulled me into a new environment and forced me to grow in ways I never anticipated.

There were migrations in scale. Migrations in technology. Migrations in geography. Migrations in identity.

Those who pause beneath the Sakura on UBC’s Memorial Road often say the trees were brought from Japan and replanted here. They blossom every year in a way you cannot find anywhere else. They did not choose the journey, yet they grew. And they became something unique because of the journey, not in spite of it.

Are you someone shaped by migrations.

What has been your latest migration.

The post Sakura Migration appeared first on Behind the Build.

The Modernization Journey: How to Take a Legacy System From Zero Trust to AI Ready Without Rewrites or Downtime and Big Costs

Jonathan Wong — Fri, 24 Apr 2026 22:58:21 +0000

Modernization is often misunderstood. Many organizations believe it requires rewriting their legacy systems, replacing entire architectures, or enduring long periods of downtime. In reality, modernization is a sequence. It begins with security, continues with infrastructure uplift, and ends with AI powered capabilities that operate safely around the legacy core.

This journey illustrates how we helped a client transform a fragile legacy PHP system into a secure, compliant, AI ready platform without rewriting the application and without interrupting production. The journey is documented across a series of articles that cover the business perspective, the technical deep dives, and the AI implementation. This final piece brings the entire story together.

Project Background: Why Modernization Became Mandatory

The client wanted to elevate their product and expand into new regulated markets. To do that, they needed to meet compliance standards such as SOC 2 and PCI DSS. These frameworks require strict identity controls, auditability, and a security posture that legacy systems rarely provide. Compliance was not a technical preference. It was a business requirement for entering new industries.

At the same time, the client wanted to introduce AI powered features into their product. They envisioned multilingual document understanding, intelligent automation, and natural language interfaces. But AI cannot be safely added to a system that lacks identity boundaries, secure data flows, or modern compute layers. Without the right foundation, AI becomes a risk multiplier.

This created a clear sequence. Secure the current system. Achieve compliance readiness. Modernize the environment. Prepare the architecture for AI. Then introduce AI features safely. This is why the project began with Zero Trust rather than AI.

The Business Case

The business perspective behind this transformation is detailed in the article:

How I Delivered Zero Trust Security for a Client’s Legacy PHP System Without Rewrites, Downtime, or Big Costs

The core challenge was simple. The legacy system was too critical to rewrite and too fragile to modify. It supported daily operations and revenue generating workflows. A rewrite would introduce risk, cost, and uncertainty. A multi-year migration could easily fail. Even a successful rewrite could disrupt the business.

The constraints were clear:

No application revamp
No downtime
Free or low‑cost solutions only
Compliance‑aligned security improvements
Immediate business value

The smarter approach was to modernize around the legacy system. Strengthen the environment. Improve the security posture. Introduce modern cloud capabilities. Build new features outside the legacy core. This approach delivered value quickly and reduced risk. It also created a path where AI could be added safely and incrementally.

The Zero Trust Foundation

The Zero Trust foundation became the anchor of the entire transformation. It provided the identity first model required for SOC 2 and PCI DSS. It removed public exposure. It enforced access boundaries. It created a secure perimeter around the legacy system without modifying the application code.

The technical implementation is documented in two deep dive articles:

The foundation included VPC only networking, IAM based access to RDS, S3, and CloudWatch, passwordless authentication, and a hardened runtime. Every component was isolated. Every request was authenticated. Every action was logged. The system became secure by design.

This foundation made compliance achievable and created the conditions required for safe modernization.

The Modernization Path

Once the security perimeter was in place, we modernized the environment around the legacy system:

The application code remained untouched. Instead, we uplifted the infrastructure into modern cloud primitives.
Introduced observability, identity enforcement, and automation.
Replaced brittle components with managed services.
Created a modernization perimeter that isolated risk and allowed new capabilities to be added without affecting production.

This approach delivered immediate improvements. The system became more stable. Operations became more predictable. Compliance became measurable. And the environment became ready for the next stage.

The AI Ready Architecture

AI readiness is not about adding a model. It is about preparing the system to support AI safely. That requires an architecture that is event driven, API first, identity enforced, and capable of handling structured and unstructured data.

However there was a major constraint: the client’s primary business entity is registered in an unsupported region for these advanced AI models. The only viable path was to leverage their overseas entity to create a new AWS account in a supported region and integrate it with their existing environment.

The constraints were non‑negotiable:

multilingual inference
multi‑modal document processing
cross‑account AWS integration
cross‑region invocation
access to advanced LLMs such as Claude
strong security controls for sensitive customer data

We introduced two‑sided trust‑granting model and network isolation to secure APIs and data pipelines that could feed Bedrock or other models. We ensured that every AI workflow operated within the Zero Trust perimeter. The result was an architecture that could support AI features without exposing the legacy system to new risks.

Lambda and Bedrock Integration

The AI execution layer is documented in the article:

How I Delivered a Cross Account Cross Region Multilingual Multi Modal AWS Bedrock Solution in a Zero Trust Environment

Lambda act as a region proxy. Bedrock provided secure enterprise grade AI capabilities. Together, they enabled new features without touching the legacy code.

We implemented multilingual understanding, multimodal document analysis, workflow automation, and intelligent assistants. The legacy system remained stable. The AI layer delivered new value. The business moved forward without risk.

The detailed implementation of the AI pipeline is documented:

Building a Multilingual Multi Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6

This article explains how the multilingual and multimodal capabilities were orchestrated using Lambda, Bedrock, and secure data flows inside the Zero Trust perimeter.

Outcomes and Lessons Learned

The transformation delivered measurable results.

The client achieved a compliance ready security posture
The system became more stable and more observable
The legacy system remained untouched
No rewrite, no downtime, no big costs
The business expanded into new regulated markets
The product gained new AI capabilities
The entire journey followed a repeatable sequence that can be applied to any legacy environment.

The core lesson is simple. Modernization is not a single project. It is a sequence.

Secure first
Modernize the environment
Prepare the architecture
Add AI safely

This approach reduces risk, accelerates delivery, and creates long term value.

Modernization is not a rewrite. It is a journey. And when executed in the right order, it turns a legacy system into an AI ready platform without disruption.

The post The Modernization Journey: How to Take a Legacy System From Zero Trust to AI Ready Without Rewrites or Downtime and Big Costs appeared first on Behind the Build.

Building a Multilingual, Multi‑Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6

Jonathan Wong — Wed, 22 Apr 2026 20:16:46 +0000

In my last article How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment, I walked through the architecture that makes secure, multilingual, multi‑modal AI processing possible across AWS accounts and regions. That foundation solved the infrastructure challenge, but it left one critical question unanswered: how does the system actually understand real documents?

This article picks up exactly where the last one ended. Now that the pipeline is built, it’s time to open the black box and examine the Lambda Python function that turns raw files into structured, multilingual insights. This is where OCR, model selection, prompt engineering, and Claude Sonnet 4.6 all come together to form the intelligence layer of the entire solution.

Selecting the Right LLM Model

The core requirement was clear: the model must handle multilingual content (English + Chinese) and multi‑modal inputs including text files, PDFs, and images. Several AWS‑native and third‑party models were evaluated.

Evaluation Results

AWS Textract + Titan performs OCR well for English, but Titan consistently ignored Chinese content, making it unsuitable for bilingual documents.
Amazon Nova attempted to interpret Chinese text but produced random guesses with a very low success rate.
Qwen3 handled Chinese better, with an acceptable success rate for mixed‑language documents.
Claude Sonnet 4.6 delivered 5× higher accuracy than Qwen3 while also offering lower total cost. It consistently extracted structured fields correctly across English‑only, Chinese‑only, and mixed‑language documents.

Final Decision
Claude Sonnet 4.6 was selected due to its superior multilingual reasoning, stable multi‑modal performance, and cost efficiency.

Activating Claude Sonnet 4.6 in AWS Bedrock
Before the Lambda function can invoke Claude, the model must be activated in the AWS account.

Step 1: Submit the Use Case
Submit the required use case form in the Bedrock console. Approval typically takes 15–30 minutes.

Step 2: Test in the Model Playground
Run a first inference in the Claude Sonnet 4.6 playground to confirm access.

Step 3: Resolve Marketplace Permission Errors
Some accounts encounter the following error during the first invocation:

“Model access is denied due to IAM user or service role not authorized to perform the required AWS Marketplace actions (aws-marketplace:ViewSubscriptions, aws-marketplace:Subscribe)...”

To resolve this, attach the following IAM policy to the IAM user or role:

{
  "Effect": "Allow",
  "Action": [
    "aws-marketplace:Subscribe",
    "aws-marketplace:ViewSubscriptions"
  ],
  "Resource": "*"
}

After applying the policy, retry the model activation. Once the subscription completes, the Lambda function can invoke Claude normally.

Lambda Function Architecture
The Lambda function is the operational heart of the pipeline. It performs ingestion, OCR, reasoning, and structured extraction.

Handler
The handler contains the main execution logic:

Receive request payload from the EC2 caller
Download the uploaded file from the S3 bucket
Perform OCR text extraction
Invoke Claude Sonnet 4.6 for reasoning and field extraction
Clean and normalize the output
Return the structured JSON result back to the EC2 instance

Claude handles PDFs and images differently during OCR and target‑field extraction, so the Lambda logic must normalize and clean the model’s output to ensure consistent, structured results:

# s3_doc_in_bytes , the s3 document as bytes format  
# content_type , the content type matched by s3 document extension  

# covert the bytes to Claude supported base64 type  
doc_base64 = base64.standard_b64encode(s3_doc_in_bytes).decode("utf-8")

# Build the content block based on document type
if content_type == "application/pdf":
    doc_config = {
    "type": "document",
    "source": {
        "type": "base64",
        "media_type": content_type,
        "data": doc_base64,
    },
    }
else:
    doc_config = {
    "type": "image",
    "source": {
        "type": "base64",
        "media_type": content_type,
        "data": doc_base64,
    },
    }

request_body = {
    "anthropic_version": "bedrock-2023-05-31",
    "max_tokens": 4096,
    "temperature": 0,  # no creative answer  
    "system": OCR_PROMPT,
    "messages": [
    {
        "role": "user",
        "content": [
            doc_config,
            {"type": "text", "text": TARGET_FIELD_PROMPT},
        ],
    },
    ],
}

response = bedrock_client.invoke_model(
    modelId=BEDROCK_MODEL_ID,
    contentType="application/json",
    accept="application/json",
    body=json.dumps(request_body),
)

response_body = json.loads(response["body"].read())
assistant_text = response_body["content"][0]["text"]

# remove any markdown code fences from Claude answer, if present
cleaned = assistant_text.strip()
if cleaned.startswith("

```"):
    cleaned = cleaned.split("\n", 1)[1]
if cleaned.endswith("```

"):
    cleaned = cleaned.rsplit("

```

", 1)[0]
cleaned = cleaned.strip()

# other logic

Prompts
Two categories of prompts guide the LLM’s behavior.

OCR Prompt Defines the system role, extraction rules, and reasoning instructions. It explains how the LLM should interpret different document scenarios.
Target Field Prompt Defines how to handle different file types (PDF, image, text). Provides a list of target fields with descriptions and common pattern multilingual examples, like: | total_deposit | Total deposit collected in HKD (numeric) — include ALL deposits: deposit (按金), electricity deposit (電費按金), renovation deposit, etc. Use the grand total from the receipt/table if available. |. Specifies strict output format rules such as:
- no markdown
- no explanation
- return only a JSON object

These prompts ensure deterministic, repeatable extraction across diverse document types.

Deploying the Lambda Function
Deployment is straightforward but requires attention to packaging:

Zip only the Python files, not the parent folder.
The zip file must contain the .py files at the root level.
Use the Upload ZIP button in the Lambda console.

Configuring the Handler
In the Lambda configuration tab, set the handler to match your file and function name. For example:

document_handler.handler

Where:

document_handler.py is the file
handler is the function inside that file

Closing Thoughts

This architecture demonstrates how to build a multilingual, multi‑modal document analysis pipeline using AWS Lambda and Claude Sonnet 4.6. The key is not just choosing the right model, but designing the prompts, IAM permissions, and Lambda workflow so the system behaves predictably under real production workloads.

About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn

The post Building a Multilingual, Multi‑Modal Document Analysis Pipeline with AWS Lambda and Claude Sonnet 4.6 appeared first on Behind the Build.

Inside TECHSPO Vancouver 2026 at Paradox Vancouver — Innovation, Community, and Real Conversations

Jonathan Wong — Tue, 21 Apr 2026 01:00:30 +0000

This year’s TECHSPO Vancouver 2026, hosted at the Paradox Vancouver, brought together innovators, founders, engineers, and creators across the tech spectrum, with the venue’s modern, design‑driven environment providing the perfect backdrop for two days of meaningful conversations and emerging‑tech exploration.

TECHSPO showcased a diverse range of companies across iCRM , MarTech , AI , SaaS , and even mental‑health technology , creating an experience built for hands‑on demos, high‑value networking, and discovering the next wave of digital innovation.

The hotel’s atmosphere, shaped by modern architecture, clean lines, and a calm yet energetic vibe, created a perfect setting for focused conversations and networking.

Meaningful Connections Throughout the Event

Reconnected with my friend Maksym , a hardware professional I first met at the Vancouver Careerin Coffee Meetup. He’s one of the rare engineers who can move seamlessly from low‑level parts and protocol discussions to market intelligence. His insights always sharpen my thinking.
Met Layth , a cybersecurity professional with real‑world threat experience. Our conversation covered:
- A real supply‑chain attack case
- How fake network infrastructures deceive internal teams
- The rising importance of AI model protection.
Connected with startup founders , including Anil , who is building an AI‑agent service. It’s energizing to see founders experimenting with automation, agentic workflows, and new business models.
Met new workforce talent , like Betty , an Intermediate Software Engineer open to work and passionate about accessibility‑first design. Her enthusiasm for inclusive product development was refreshing and aligned with where modern product expectations are heading.

Vancouver’s tech ecosystem is clearly accelerating, with momentum spanning AI agents, cybersecurity, and mental‑health technology, and what stood out most throughout TECHSPO was the depth of talent across the community, from experienced founders to early‑career engineers, all building with purpose and pushing the region’s innovation forward.

If you attended TECHSPO Vancouver as well, I’d love to hear what conversations or trends stood out to you.

The post Inside TECHSPO Vancouver 2026 at Paradox Vancouver — Innovation, Community, and Real Conversations appeared first on Behind the Build.

How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment

Jonathan Wong — Mon, 20 Apr 2026 05:47:25 +0000

After I modernized my client’s platform security, the next strategic move was clear: elevate their product with generative AI. They wanted an LLM‑powered component capable of analyzing customer‑submitted documents during application intake and performing price forecasting. The goal was to dramatically improve user experience by streamlining the workflow, offering proactive suggestions, and providing real‑time assistance.

To deliver this, the AI analyst feature needed multilingual support , multi‑modal document understanding (images, PDFs, text files, and more), and advanced reasoning , which pointed directly to models like Claude. But there was a major constraint: the client’s primary business entity is registered in an unsupported region for these advanced AI models. The only viable path was to leverage their overseas entity to create a new AWS account in a supported region and integrate it with their existing environment.

The constraints were non‑negotiable:

multilingual inference
multi‑modal document processing
cross‑account AWS integration
cross‑region invocation
access to advanced LLMs such as Claude
strong security controls for sensitive customer data

It reads like an AWS Solution Architect Professional exam scenario? It wasn’t a hypothetical. This was a real‑world architecture challenge with real compliance, security, and business constraints.

To achieve the goal, I designed a two‑sided trust‑granting model between the two AWS environments. AWS Account A (AC‑a) operates in Region A, and AWS Account B (AC‑b) operates in Region B.

Why Lambda in AC‑b Is Mandatory

Claude enforces region restrictions based on the source IP. This means:

all traffic to Claude must originate from Region B , and
any request coming directly from Region A will be blocked , regardless of AWS account ownership.

Because of this, the Lambda function in AC‑b becomes a non‑negotiable region proxy. It is the only component allowed to make outbound requests to Claude, ensuring that Anthropic sees a valid Region‑B AWS IP.

In other words: AC‑a (data + app) → AC‑b (Lambda proxy + Claude) is the only viable architecture that satisfies both the business requirements and the regional restrictions.

Resources and IAM Roles

In AC‑a, an EC2 instance acts as the caller of the AI service hosted in AC‑b. The EC2 instance assumes the IAM role ec2‑production , which must be explicitly granted permission to invoke the Lambda function in AC‑b.

{
    "Effect": "Allow",
    "Action": "lambda:InvokeFunction",
    "Resource": "arn:aws:lambda:region-b:ac-b-id:function:lambda-name"
}

At the same time, the Lambda function in AC‑b must enforce the reverse trust boundary: it should only accept invocations originating from AC‑a’s ec2‑production role. It uses resource-based policy:

Statement ID : AllowCrossAccountPHPInvoke
Principal : arn:aws:iam::ac-a-id:user/ec2-production  
Effect : Allow
Action : lambda:InvokeFunction

At the Lambda IAM role level, it must be explicitly granted permission to access Amazon Bedrock and invoke Claude. This role becomes the trusted execution identity for all outbound LLM requests from AC‑b, ensuring that only the Lambda function running in the supported region is authorized to call the model:

{
    "Sid": "AllowBedrockInvoke",
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": [
    "arn:aws:bedrock:*:ac-b-id:inference-profile/your-claude-model",
    "arn:aws:bedrock:*::foundation-model/your-claude-model"
    ]
}

Set the region to “*” in the IAM policy, since Bedrock may internally route the invocation across multiple supported regions. This ensures the Lambda role can invoke the service regardless of the specific regional endpoint used.

This ensures mutual, least‑privilege trust across accounts and regions.

Cross‑Account Data Access

Because the system exchanges customer‑sensitive data across multiple AWS accounts and regions , the communication path must meet strict security guarantees. The design enforces three core requirements:

No traffic may traverse the public internet
Data can only originate from controlled, authenticated AWS resources
Data can only be delivered to controlled, authenticated AWS resources

The PrivateLink endpoint is protected by a dedicated security group that permits inbound HTTPS traffic only from the ec2-production instance. This ensures that no other resource, inside or outside the VPC, can reach the endpoint at the network layer.

In addition, the PrivateLink service is bound to a resource policy that explicitly authorizes only the ec2-production IAM role to invoke the controlled Lambda function. Even if another resource could reach the endpoint, the policy prevents it from calling the Lambda:

{
    "Sid": "RestrictToLambda",
    "Principal": {
    "AWS": "arn:aws:iam::ac-a-id:user/ec2-production"
    },
    "Action": "lambda:InvokeFunction",
    "Effect": "Allow",
    "Resource": "arn:aws:lambda:aws-region-b:ac-b-id:function:lambda-name"
}

Together, the security group and the endpoint policy enforce strict, dual‑layer Zero Trust: network access is restricted to a single controlled source, and service‑level access is restricted to a single controlled identity.

The Lambda function is responsible for analyzing the customer’s document as part of the AI prediction workflow. However, due to regulatory requirements, all customer data must remain stored in AC‑a’s private S3 bucket. However, AC‑b still needs controlled access to this data for analysis. Therefore, the S3 bucket policy in AC‑a must selectively grant AC‑b permission to read only the required objects, while maintaining strict Zero Trust boundaries. This is the authoritative gatekeeper :

{
    "Sid": "AllowACBReadSpecificObjects",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::ac-b-id:role/lambda-role"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This ensures AC‑b cannot read anything outside the approved prefix.

In the AC-b, the lambda iam role attaches a policy to ensure that only attempt to access the specific S3 objects it is supposed to. This is the identity‑side limiter :

{
    "Sid": "AllowReadOnlySpecificObjects",
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::your-bucket/path/to/allowed/*"
}

This is the same dual‑layer pattern AWS recommends for cross‑account S3 access with Zero Trust.

After the Claude model is activated and the required use‑case approvals are completed, the EC2 instance in AC‑a can securely invoke the AWS Bedrock service.

Bringing It All Together

This project was not only about adding generative AI to an existing platform, but also delivering advanced LLM capabilities under strict regional, security, and compliance constraints. By designing a cross‑account, cross‑region architecture with a mandatory Lambda proxy, enforcing mutual least‑privilege trust, and routing all sensitive data through PrivateLink, the solution enables multilingual, multi‑modal AI analysis without ever exposing customer information to the public internet.

The result is a fully compliant, Zero‑Trust, enterprise‑grade AI integration that unlocks Claude’s capabilities for a business operating in an otherwise unsupported region—transforming their application workflow while preserving the highest security standards.

The post How I Delivered a Cross‑Account, Cross‑Region, Multilingual, Multi‑Modal AWS Bedrock Solution in a Zero Trust Environment appeared first on Behind the Build.

Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or...

Jonathan Wong — Sun, 19 Apr 2026 02:37:09 +0000

This section expands on the technical architecture and implementation behind my recent Zero Trust case study: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs, and extend the part 1 story to the internet‑facing Zero Trust layer, covering how external traffic is authenticated, filtered, and isolated before it ever reaches the private network.

Below is the high‑level architecture diagram:

API Server — Nginx Layer

The Nginx layer enforces strict request‑level security controls before traffic ever reaches PHP. It blocks unsafe request patterns, rejects malformed uploads, prevents host‑header spoofing, and adds essential security headers. Sensitive files, hidden paths, and directory traversal attempts are denied outright. The server also hides all version information and limits request size to reduce attack surface. Together, these rules create a hardened perimeter that filters out malicious traffic and ensures only clean, intentional API requests reach the application.

Nginx Configuration Snippet

//  other settings  

autoindex off;  

# Block direct IP access
if ($host != "yourdomain.com") {
    return 444;
}

# Security headers
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

# Allow large uploads
client_max_body_size 2M;  

location ~ ^/.*/$ {
    return 403;
}  

# Block hidden files
location ~ /\.(?!well-known).* {
    deny all;
}

# Main routing
location / {
    try_files $uri $uri/ /index.php?$query_string;
}

# PHP handler
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;  

    //  auth header   
    fastcgi_param HTTP_AUTHORIZATION $http_authorization;  

}

//  other settings

Cloudflare Layer

Cloudflare acts as the authenticated edge for the entire API surface in internet . Mutual TLS and Worker JWT validation creates a strong identity and authorization boundary before traffic ever touches your private API server.

1. Mutual TLS — It is configured directly in the Cloudflare dashboard. In the SSL/TLS > Client Certificates section, create a new Client Certificate and download the certificate and private key. Embed this certificate into your mobile app. Cloudflare automatically manages the Client CA and validates every incoming request against it.

Than go to Security > Security rules > Custom rules and click Create rule to set up the logic to identify unverified traffic as follows:

2. Cloudflare Worker — It runs at the edge and validates the JWT before forwarding the request to your origin. The Worker checks the signature, issuer, audience, and expiration, and rejects any invalid or expired token. This ensures that only authenticated and authorized traffic reaches your private API server.
The JWT public key should be added as a “Secret” to the Workers > Settings > Variables > Secrets.

Cloudflare Worker JWT Validation Code Snippet

export default {
  async fetch(request, env) {
    const auth = request.headers.get("Authorization");
    if (!auth || !auth.startsWith("Bearer ")) {
      return new Response("Unauthorized", { status: 401 });
    }

    const token = auth.replace("Bearer ", "");

    try {  
      // env.JWT_PUBLIC_KEY is the JWT public key   
      const { payload } = await env.JWT.verify(token, env.JWT_PUBLIC_KEY, {
        issuer: "yourdomain.com",
        audience: "cloudflare"
      });

      // Token is valid → forward to origin
      return fetch(request);
    } catch (err) {
      return new Response("Invalid or expired token", { status: 401 });
    }
  }
};

Support components

Robust logging is essential for real‑time production monitoring. Logrotate handles local retention by deleting old logs right after rotation, while Fluent Bit streams the latest logs to CloudWatch, ensuring centralized, reliable observability.

Configure Logrotate
We use Logrotate to clear logs daily, reducing retention risk and minimizing the security exposure of sensitive operational data. To create a config file:

sudo nano /etc/logrotate.d/ec2-production

add the Logrotate configuration

/var/log/yourdomain/*.log
/var/log/nginx/yourdomain.access.log
/var/log/nginx/yourdomain.error.log {
    daily
    missingok
    rotate 0        # This deletes the old log immediately after rotation
    notifempty
    copytruncate    # Clears the file content without changing the filename
    nocreate        # Do not create a new file; let the app handle it
}

Install Fluent Bit
Run these commands on your Ubuntu instance to install the stable version:

sudo wget -qO /etc/apt/keyrings/fluentbit.asc https://packages.fluentbit.io/fluentbit.key 
echo "deb [signed-by=/etc/apt/keyrings/fluentbit.asc] https://packages.fluentbit.io/ubuntu/noble noble main" \
| sudo tee /etc/apt/sources.list.d/fluentbit.list  

sudo apt update  
sudo apt install -y fluent-bit  
sudo systemctl start fluent-bit
sudo systemctl enable fluent-bit  
systemctl status fluent-bit

Configure Fluent Bit to ship the logs to CloudWatch. Update /etc/fluent-bit/fluent-bit.conf to track these files.

[SERVICE]
    Flush        5
    Daemon       Off
    Log_Level    info
    Parsers_File parsers.conf

# 1. PHP Application Logs
[INPUT]
    Name             tail
    Path             /var/log/yourdomain/*.log
    Tag              ec2-production.php
    Refresh_Interval 5

# 2. Nginx Access Logs
[INPUT]
    Name             tail
    Path             /var/log/nginx/yourdomain.access.log
    Tag              ec2-production.nginx_access
    Parser           nginx  # Standard built-in parser for Nginx access
    Refresh_Interval 5

# 3. Nginx Error Logs
[INPUT]
    Name             tail
    Path             /var/log/nginx/yourdomain.error.log
    Tag              ec2-production.nginx_error
    # Nginx error logs often need a custom regex parser or 'multiline'
    Refresh_Interval 5  

    Multiline        On
    Parser_Firstline nginx_error_firstline
    Parser_Nextline  nginx_error_nextline

[OUTPUT]
    Name            cloudwatch_logs
    Match           ec2-production.*
    region          aws-region
    log_group_name  ec2-production
    log_stream_prefix ec2-
    auto_create_group On

Restart the Fluent Bit

sudo systemctl restart fluent-bit

Open the CloudWatch Console. Go to Logs > Log Groups. Look for the group name ec2-production. You should see log streams appearing within a few minutes of activity on your Nginx/PHP server.

Bastion Server

To minimize the attack surface, the production EC2 server remains inside the AWS private network with no public IP and no inbound rules, except controlled SSH access from a bastion host used for production support.

The bastion server

Enabled only when production support is required
Accessible only with an approved SSH key and trusted IP
Access to production is performed exclusively through a controlled login script
No production server private IPs or SSH keys are ever exposed

To add the production server controlled login script

# ensure the normal user can't read the production server key 
sudo mkdir -p /root/keys
sudo mv /home/ubuntu/.ssh/ec2-production.pem /root/keys/
sudo chmod 600 /root/keys/ec2-production.pem 

# login-ec2-production is the production server login script 
sudo nano /usr/local/bin/login-ec2-production  

# ensure normal can't update the login script 
sudo chmod 700 /usr/local/bin/login-ec2-production
sudo chown root:root /usr/local/bin/login-ec2-production

add the permission to the normal user to run the script by “sudo visudo”

# add the permission   
ubuntu ALL=(root) NOPASSWD: /usr/local/bin/login-ec2-production

We can go to the production server by login-ec2-production for production support without direct access.

Security Outcome

This layered setup ensures:

Zero public exposure — no public IPs, all traffic enters through Cloudflare Tunnel only.
Authenticated edge — Cloudflare enforces mTLS and validates JWTs before forwarding any request.
No direct origin access — only Cloudflare Tunnel can reach the private API server.
Strict request filtering — Nginx blocks unsafe patterns, malformed requests, and disallowed methods.
Hardened runtime — PHP runs with disabled dangerous functions, strict session rules, and no version leakage.
No stored passwords — API connects to RDS using IAM authentication, not static credentials.
RDS Proxy only — EC2 instances cannot connect directly to the database.
Identity at every hop — Cloudflare mTLS → Worker JWT → IAM role → RDS Proxy → RDS.
East‑west segmentation — security groups restrict lateral movement between internal components.
Minimal attack surface — no directory browsing, no file uploads, no sensitive files exposed.
Consistent Zero‑Trust posture — every request, device, and connection must prove identity before being allowed through.

It’s a Zero Trust architecture applied to a legacy PHP system — without rewriting the application, without downtime, and without blowing the budget.

The post Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs (Part 2) appeared first on Behind the Build.

How to Create and Manage a Copilot Task That Automatically Scans Gmail for Bills and Adds Them to Google Calendar

Jonathan Wong — Wed, 15 Apr 2026 21:59:07 +0000

I recently discovered a new feature in Copilot called Tasks. It’s a cloud‑based automation capability that can take over routine, multi‑step processes and keep them running in the background — even when your computer is off. To understand what it can actually do, I tried a simple experiment: creating a task that scans Gmail for bill or invoice emails and automatically adds the due dates to my Payment Google Calendar.

Let’s Create the Task

1. Describe the automation in natural language

You told Copilot:

“Scan Gmail for bill/invoice emails from the past 7 days and create events on my Payment Google Calendar.”

2. Copilot interprets the workflow

It identifies required connectors, and permission prompts appear:

“Allow Copilot to read your Gmail”: Gmail (to read emails)
“Allow Copilot to create events in Google Calendar”: Google Calendar (to create events)

3. Copilot generates a task card

The card summarizes:

What the task will do
When it will run
What services it needs access to

4. You approve the permissions

Copilot start to create the task and show the result. The task becomes active and begins running on its schedule.

The automation runs independently on Copilot’s servers, not your device. You don’t need to keep Copilot open. The task simply executes on schedule and reports back when it’s done.

What Are the Outcomes?

Daily Gmail scanning

Looks back 7 days
Detects bill/invoice emails
Extracts due dates and vendor names

Automatic calendar event creation

Creates events on your Payment Google Calendar
Time: 8:00–8:30 AM
Reminder: 1 day before

You can now find the new task card in your Copilot Tasks tab:

Manage Tasks Status

To pause, resume, and remove tasks

In tasks tab you can ask Copilot to:

“List my scheduled tasks” — see all active tasks

“Pause my bill check task” — temporarily stop it

“Delete my bill check task” — remove it entirely

To modify the task:

“Modify my bill check task to scan 14 days instead of 7.”

“Update my bill task to add a 2‑day reminder.”

“Change the calendar to ‘Finance’ instead of ‘Payment’.”

Copilot will regenerate the task card with updated logic.

Manage Task Permissions

You can review and manage task permissions through the Sources and Connectors section in Copilot. This lets you see exactly which accounts and data the task relies on.

Option 1: Copilot Dashboard

Click the Sources and Connectors icon in the Copilot dashboard message bar. It shows a full list of all accounts and data sources your task is currently using.

Select the “Connector settings” button to view all connector details associated with the task.

Option 2: Ask Copilot

In the message bar, type “Show me the connectors used in my bill check task.” Copilot will return a list of all connectors the task currently uses.

If you want to revoke Gmail or Google Calendar access, go to:

https://copilot.microsoft.com → Settings → Connected Accounts

There you can:

Disconnect Gmail
Disconnect Google Calendar
Remove all scopes previously granted

Once removed:

The task will fail gracefully
Copilot will notify you that access is required
You can re‑grant permissions anytime

Key Takeaway

My first hands‑on trial of Copilot Tasks shows that Microsoft is quietly building a true cloud‑native automation engine — one that can run multi‑step workflows independently, without relying on your local machine. The experience is already surprisingly capable, but it’s important to note that Copilot Tasks is still in research preview, not general availability , so features, reliability, and UI flows may continue to evolve as Microsoft expands the rollout.

The post How to Create and Manage a Copilot Task That Automatically Scans Gmail for Bills and Adds Them to Google Calendar appeared first on Behind the Build.

Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or...

Jonathan Wong — Tue, 14 Apr 2026 19:26:40 +0000

Below is the high‑level architecture diagram:

AWS Layer — Role‑Based Access + Network Isolation

The AWS environment is built around least privilege, no public exposure, and segmented trust boundaries. We enforce this through IAM roles, security groups, resource‑level permissions, and Cloudflare Tunnel.

Resources

1. EC2 (api-production) — API Server with No Public IP

This EC2 instance runs the PHP API and sits entirely inside a private subnet. It has no public IP, no inbound rules, and no exposed ports. The only way it communicates with the internet is through Cloudflare Tunnel.

Cloudflare Tunnel works because:

The EC2 instance initiates an outbound TLS connection to Cloudflare
Cloudflare never needs to reach into AWS
No public IP, no inbound SG rules, and no NAT Gateway are required

This outbound‑only model eliminates the attack surface while still allowing global access.
Cloudflare Tunnel setup:

A. Install the cloudflared

curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg \
| sudo tee /usr/share/keyrings/cloudflare.gpg >/dev/null 

echo "deb [signed-by=/usr/share/keyrings/cloudflare.gpg] https://pkg.cloudflare.com/cloudflared jammy main" \
| sudo tee /etc/apt/sources.list.d/cloudflared.list  

sudo apt update
sudo apt install cloudflared

B. Cloudflare Login and authentication. This command generates a one‑time login URL that authenticates your machine with Cloudflare and authorizes this cloudflared instance. During the process, Cloudflare downloads a “cert.pem” file, which the CLI uses later when creating and managing tunnels.

// Please log in to your Cloudflare dashboard before running the command below. Otherwise, you will be redirected to the Cloudflare login page and the authentication flow will not complete.  

cloudflared tunnel login

C. Create Cloudflare tunnel. This command create Cloudflare tunnel, and returns a tunnel ID in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234
## Make sure to copy the tunnel ID for use in subsequent configuration steps

cloudflared tunnel create api-production-cf-tunnel

E. Create tunnel DNS record. This command creates the DNS record for in Cloudflare. You should see a new ‘tunnel’ DNS record appear automatically in the Cloudflare dashboard. There is no need to manually add the record yourself.

cloudflared tunnel route dns api-production-cf-tunnel yourdomain.com with value xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234.cfargotunnel.com

D. Create tunnel runtime configurations

nano ~/.cloudflared/config.yaml

The settings

tunnel: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234        # The tunnel ID returned by Cloudflare
credentials-file: /etc/cloudflared/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx1234.json  # Tunnel credentials

ingress:
  - hostname: yourdomain.com                        # Public hostname
    service: http://localhost:80                    # Local service to forward to
  - service: http_status:404                        # Default fallback

F. Start the Cloudflare tunnel

## save the configuration  
sudo mkdir -p /etc/cloudflared 
sudo mv ~/.cloudflared/config.yml /etc/cloudflared/
sudo mv ~/.cloudflared/*.json /etc/cloudflared/  
sudo chown root:root /etc/cloudflared/config.yml
sudo chown root:root /etc/cloudflared/.json 
sudo chmod 600 /etc/cloudflared/.json
sudo chmod 600 /etc/cloudflared/config.yml  

## start the cloudflare tunnel in the api-production (EC2) 
cloudflared tunnel run api-production-cf-tunnel

G. Install cloudflared as service

sudo cloudflared service install  
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
sudo systemctl status cloudflared

2. RDS (rds-production) — Private MySQL Database
The production database is fully isolated:

No public access
No internet routing
IAM authentication only
Encryption enabled

It can only be reached through the RDS Proxy.

3. RDS Proxy (rds-proxy-production) — IAM‑Authenticated Database Access
The proxy sits between the EC2 instance and the database. It enforces:

IAM authentication
Connection pooling
No direct database exposure

IAM Roles

1. role-ec2-production — API Server Role
Attached to the EC2 instance. It grants access only to:

Specific S3 buckets
The RDS Proxy
CloudWatch logs

No IAM users, no access keys, no long‑lived credentials. The inline policy:

role-ec2-production Inline Policy

//  RDS  
{
  "Effect": "Allow",
  "Action": [
    "rds-db:connect"
  ],
  "Resource": [
    "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:db-instance-arn/role-rds-db",
    "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:prx-proxy-arn/role-rds-db"
  ]
}
//  S3  
{
  "Sid": "AllowListBucket",
  "Effect": "Allow",
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::bucket-name",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "aws-region"
    }
  }
},
{
  "Sid": "AllowObjectReadWrite",
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::bucket-name/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "aws-region"
    }
  }
}
//  CloudWatch  
{
  "Effect": "Allow",
  "Action": [
    "logs:DescribeLogGroups",
    "logs:DescribeLogStreams",
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "*"
}
//  JWT  
{
  "Sid": "AllowJWTPrivateKey",
  "Effect": "Allow",
  "Action": [
    "ssm:GetParameter",
    "ssm:GetParameters"
  ],
  "Resource": "arn:aws:ssm:aws-region:aws-ac-id:parameter/category-name/jwt/private-key"
}

2. role-rds-db — RDS Proxy Role
Attached to the RDS Proxy. It allows the proxy to authenticate to the database using IAM auth. Tokens are generated and signed by AWS KMS.

role-rds-db Inline policy

{
  "Sid": "GetSecretValue",
  "Action": [
    "secretsmanager:GetSecretValue"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:secretsmanager:aws-region:aws-ac-id:secret:rds-proxy-role-rds-db-name"
  ]
}
{
  "Sid": "DecryptSecretValue",
  "Action": [
    "kms:Decrypt"
  ],
  "Effect": "Allow",
  "Resource": [
    "arn:aws:kms:aws-region:aws-ac-id:key/decrypt-key"
  ],
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.aws-region.amazonaws.com"
    }
  }
}
{
  "Effect": "Allow",
  "Action": "rds-db:connect",
  "Resource": "arn:aws:rds-db:aws-region:aws-ac-id:dbuser:db-name/role-rds-db"
}

3. role-rds-db — Database IAM Auth User
The same IAM auth username must exist inside the MySQL database. Creation SQL:

-- 1. Create IAM-authenticated user (no password)
CREATE USER 'role-rds-db'@'%' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

-- 2. Grant only SELECT, INSERT, UPDATE, DELETE on the your_db database
GRANT SELECT, INSERT, UPDATE, DELETE ON your_db.* TO 'role-rds-db'@'%';

-- 3. Reload privileges (optional but safe)
FLUSH PRIVILEGES;

This ensures the proxy can authenticate as a database user without passwords.

Security Groups

1. sg-ec2-production

Attached to the api-production
No inbound access except from the bastion host via private IP
Outbound allowed for Cloudflare Tunnel

This removes the external attack surface entirely.

2. sg-rds-proxy

Attached to the RDS Proxy
Only allows inbound 3306 from sg-ec2-production

3. sg-rds-db

Attached to the RDS instance
Only allows inbound 3306 from sg-rds-proxy

This ensures:

EC2 cannot reach the database directly
Only the proxy can communicate with the database
Even inside the private network, lateral movement is blocked

API Server — PHP Layer

1. JWT validation and authorization in the PHP API before processing any request

The PHP API verifies the JWT signature
enforces expiration
checks user permissions directly from the claims

Generate JWT Code Snippet

// your function 

// -------------------------------
// 1. Load RSA private key from SSM
// -------------------------------

$ssm = new SsmClient([
    'region'  => 'aws-region',
    'version' => 'latest'
]);

$result = $ssm->getParameter([
    'Name' => '/category-name/jwt/private-key',   // <-- your parameter name
    'WithDecryption' => true
]);

$privateKeyPem = $result['Parameter']['Value'];

$privateKey = openssl_pkey_get_private($privateKeyPem);

if (!$privateKey) {
    
    //  error handling  
}

// -------------------------------
// 2. Helper: Base64URL encoding
// -------------------------------

function base64UrlEncode($data) {
    return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
}

// -------------------------------
// 3. Build JWT header + payload
// -------------------------------

$header = [
    'alg' => 'RS256',
    'typ' => 'JWT'
];

$payload = [
    "sub" => $sub,  //  variable for later checking  
    "iat" => time(),
    "exp" => time() + 360000,
    "iss" => "yourdomain.com",
    "aud" => "cloudflare"
];

$base64Header  = base64UrlEncode(json_encode($header, JSON_UNESCAPED_SLASHES));
$base64Payload = base64UrlEncode(json_encode($payload, JSON_UNESCAPED_SLASHES));

$dataToSign = "$base64Header.$base64Payload";

// -------------------------------
// 4. Sign with RSA private key
// -------------------------------

if (!openssl_sign($dataToSign, $signature, $privateKey, OPENSSL_ALGO_SHA256)) {
    
    //  error handling  
}

$jwt = $dataToSign . "." . base64UrlEncode($signature);  

// other function logic

Validate JWT Code Snippet

//  your function  

list($h, $p, $s) = explode('.', $jwt);

$dataToVerify = "$h.$p";
$signature    = base64UrlDecode($s);

$publicKey = openssl_pkey_get_public(file_get_contents(your_jwt_public_key_path));

// validate signature  
$valid = openssl_verify($dataToVerify, $signature, $publicKey, OPENSSL_ALGO_SHA256);

if ($valid !== 1) { 

    // error handling  

}  

$payload = json_decode(base64UrlDecode($p), true);  

// validate payload 
if (!$payload || !isset($payload['exp'])) {

    // error handling  

}

// validate expiry 
if (time() <= $payload['exp']) { 

    // error handling  
    
}  

//  your function other logic

2. Secure database access

All database operations use PDO’s native parameter binding, which inherently prevents SQL injection.
The connection enforces TLS encryption with the RDS CA bundle, ensuring data in transit is protected and the server identity is verified. The RDS CA bundle can be downloaded here
Authentication is fully passwordless using IAM role–based RDS authentication, so no credentials are stored in the application.
The PHP layer is restricted to connect exclusively through the RDS Proxy, never directly to the RDS instance, enforcing a strict Zero Trust boundary.

Database Connection Code Snippet

//  your function 

$host = "proxy-xxxxxxxx"; // RDS Proxy endpoint
$port = 3306;
$username = "role-rds-db"; // MySQL user created with IDENTIFIED WITH AWSAuthenticationPlugin
$region = "aws-region";
$dbname = "your_db";

// AWS SDK
$sdk = new Sdk([
    'region'   => $region,
    'version'  => 'latest'
]);  

$provider = CredentialProvider::defaultProvider();  

$rdsAuthGenerator = new AuthTokenGenerator($provider);

// Generate IAM token (no password stored)
$token = $rdsAuthGenerator->createToken("$host:$port", $region, $username);  

$dsn = "mysql:host=$host;port=$port;dbname=$dbname;charset=utf8mb4";  

// Enforces TLS encryption with the RDS CA bundle  
$ca_bundle_path = realpath($path_to_store_ . "/cert/global-bundle.pem");

$options = [
    PDO::ATTR_PERSISTENT         => false,                  // Disable persistence in PDO  
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION, // Throw exceptions on errors    
    PDO::MYSQL_ATTR_SSL_CA       => $ca_bundle_path,       // Path to RDS CA bundle  
//  other option settings  
];

try {
    // 3. Establish the connection
    $pdo = new PDO($dsn, $username, $token, $options);
    
    return $pdo;  
    
} catch (PDOException $e) {
    //  error handling  
}  

//  other function logic

3. No direct file handling on the server — The API never accepts file uploads. All file operations are performed through S3 pre‑signed URLs, ensuring the PHP layer remains stateless and free from file‑system exposure

S3 Upload / Read Code Snippet

//  your upload function  

$bucket = 'your-bucket';
$region = 'aws-region';
$subFolder = 'your-subFolder';  
//  $contentType as parameter  

$s3 = new S3Client([
    'region'  => $region,
    'version' => 'latest'
]);

// Generate unique filename
$filename = random_str() . '.' . $ext;
$key = $subFolder . $filename;

// Create command for PUT
$cmd = $s3->getCommand('PutObject', [
    'Bucket' => $bucket,
    'Key'    => $key,
    'ContentType' => $contentType  
]);

// Create pre-signed URL valid for 60 seconds
$request = $s3->createPresignedRequest($cmd, '+600 seconds');
$presignedUrl = (string) $request->getUri();

//  other function logic  

//  your read function  

    $bucket = 'your-bucket';
    $region = 'aws-region';  
    //  $filepath  as parameter  

    $s3 = new S3Client([
        'region'  => $region,
        'version' => 'latest'
    ]);

    // Create command for PUT
    $cmd = $s3->getCommand('GetObject', [
        'Bucket' => $bucket,
        'Key'    => $filepath 
    ]);

    // Create pre-signed URL valid for 60 seconds
    $request = $s3->createPresignedRequest($cmd, '+600 seconds');
    $presignedUrl = (string) $request->getUri();  
    
//  other function logic

4. php.ini Security Hardening — These php.ini changes lock down the PHP runtime by removing risk. The result is a minimal‑surface, production‑safe environment aligned with Zero Trust principles.

php.ini Setting Snippet

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable Dangerous Functions
; Prevent command execution, file system abuse, and code injection
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable URL File Access
; Prevent Remote File Inclusion (RFI) attacks
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

allow_url_fopen = Off
allow_url_include = Off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Hide PHP Version & Reduce Fingerprinting
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

expose_php = Off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Session Security
; Protect against hijacking, fixation, and CSRF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Strict
session.use_trans_sid = 0
session.sid_length = 48
session.sid_bits_per_character = 6

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error Handling
; Never leak stack traces or internal paths to users
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = path_to_log_folder/php_errors.log

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Disable Legacy, Unsafe Features
; Prevent remote code injection via old PHP behaviors
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

register_globals = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off

Security Outcome

This layered setup ensures:

Zero public exposure — no public IPs, all traffic enters through Cloudflare Tunnel only.
Authentication — JWTs are fully validated before any request is allowed to trigger the API.
No direct origin access — only Cloudflare Tunnel can reach the private API server.
No stored passwords — API connects to RDS using IAM authentication, not static credentials.
RDS Proxy only — EC2 instances cannot connect directly to the database.
Identity at every hop — IAM role → RDS Proxy → RDS.
East‑west segmentation — security groups restrict lateral movement between internal components.
Hardened runtime — PHP runs with disabled dangerous functions, strict session rules, and no version leakage.
Minimal attack surface — no file uploads, no sensitive files exposed.
Consistent Zero Trust posture — every request, device, and connection must prove identity before being allowed through.

What Next’s
This article focused on the AWS private‑network Zero Trust architecture I applied to a legacy PHP system — the part that happens inside the VPC, with no public exposure and identity‑driven access to every internal component.
In my next article, I’ll extend the story to the internet‑facing Zero Trust layer, covering how external traffic is authenticated, filtered, and isolated before it ever reaches the private network. That next piece will dive into:

Cloudflare Edge and global identity enforcement
Nginx request filtering and origin isolation
Supporting operational components like CloudWatch and the bastion host

Together, these complete the full end‑to‑end Zero Trust posture — from the public internet all the way down to the private AWS runtime.

The post Technical Deep Dive: How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs (Part 1) appeared first on Behind the Build.

Joining the Google Cloud Get Certified Program Again — Day 1 Highlights

Jonathan Wong — Tue, 14 Apr 2026 03:01:08 +0000

I’m glad to have the chance to join the Google Cloud Get Certified Program again. Today I attended the online, live, Instructor‑Led Training (ILT) session. It was a full one‑day workshop that delivered a solid refresh across key Google Cloud services.

The training covered a wide range of topics, including:

Cloud Marketplace
VPC Networking
Google Compute Engine
Cloud Storage
Cloud SQL
Cloud Run (Kubernetes)

The session was well organized by Jellyfish Training, with clear explanations and strong demonstrations throughout the day. The structure made it easy to follow the progression from foundational services to more hands‑on deployment scenarios.

We also completed several Google Skill Boost hands‑on labs , which helped reinforce the concepts with practical exercises.

With the first stage completed, I’m looking forward to the next phase of the program — the Certification Journey. This is where the deeper preparation begins, and I’m excited to continue building momentum.

If you’re also working toward a Google Cloud certification, feel free to connect. Always open to sharing study approaches and learning together.

The post Joining the Google Cloud Get Certified Program Again — Day 1 Highlights appeared first on Behind the Build.

Building Agentic AI Solutions with Azure AI Foundry — My Training Day Review & Updated AI‑103 Study Plan

Jonathan Wong — Thu, 09 Apr 2026 17:16:00 +0000

On March 19, I attended the Microsoft Virtual Training Day: Build Agentic AI Solutions with Azure AI Foundry , a deep‑dive session focused on the emerging world of agentic AI , multi‑agent orchestration, and the evolving Azure ecosystem. With the new AI‑103 (beta) exam approaching, this training arrived at the perfect time.

Microsoft has now published the official AI‑103 syllabus and a few self‑paced modules , which provide much‑needed structure for early learners:

https://learn.microsoft.com/en-us/training/courses/ai-103t00#course-syllabus

Below is my updated summary of the training, how it aligns with the exam, and my revised learning plan.

1. Summary of the Training Day Content

The training covered the full lifecycle of building AI agents on Azure:

Getting Started with AI Agent Development on Azure

A walkthrough of Azure AI Foundry, including model catalog, prompt flow, and evaluation tools.

Developing an AI Agent with Azure AI Agent Service

How to configure, deploy, and scale agents using Microsoft’s new agent runtime.

Integrating Custom Tools into Your Agent

Connecting agents to APIs, enterprise systems, and custom tools for real‑world use cases.

Developing Agents with the Semantic Kernel SDK

Using planners, skills, connectors, and orchestration patterns to build intelligent workflows.

Orchestrating Multi‑Agent Solutions

Designing collaborative agent systems that delegate tasks and coordinate actions.

Developing Multi‑Agent Solutions with Azure AI Foundry Agent Service

Advanced multi‑agent patterns, routing strategies, and evaluation workflows.

Integrating MCP Tools with Azure AI Agents

A forward‑looking module on the Model Context Protocol (MCP) and standardized tool integration.

2. How This Training Supports AI‑103 Exam Preparation

The training aligns closely with the expected AI‑103 domains:

Azure AI Foundry fundamentals
Agent Service configuration
Semantic Kernel development
Tool integration (including MCP)
Multi‑agent orchestration
Evaluation and responsible AI

With the syllabus now available, it’s clear that AI‑103 is centered on agentic AI , not just traditional LLM operations.

3. AI‑103 Beta Exam — Registration Still Pending

Although the exam has been announced, beta registration is not yet open.

This creates a unique situation: early learners must prepare using a mix of training content, documentation, and hands‑on practice.

The newly published syllabus helps clarify the scope, but official learning paths are still limited.

4. Updated Learning Plan (Now Including Official Syllabus)

With the syllabus available, I’ve updated my study plan to align with Microsoft’s structure.

A. Follow the Official AI‑103 Syllabus

The syllabus outlines the core domains:

Azure AI Foundry
Agent development
Semantic Kernel
Tool integration
Multi‑agent orchestration
Evaluation and monitoring

This is now my primary roadmap.

B. Complete the Available Self‑Paced Modules

The course page includes a few early modules that reinforce foundational concepts.

These are short but useful for grounding terminology and workflows.

C. Deep Dive into Azure AI Foundry Documentation

Focus areas:

Model catalog
Prompt flow
Agent Service
Evaluation tools
Deployment patterns

D. Semantic Kernel GitHub Samples

Hands‑on practice with:

Planners
Skills
Connectors
Multi‑agent orchestration

E. Build Practical Mini‑Projects

To internalize the concepts, I’m building:

A multi‑agent research assistant
A tool‑calling enterprise agent
A workflow‑orchestration agent using SK

F. Review Build & Ignite Sessions

These sessions contain early previews of Microsoft’s agentic architecture.

5. Suggested Learning Plan for Other AI‑103 Candidates

If you’re also preparing for AI‑103, here’s a simple, effective path:

Start with the official syllabus
Complete the self‑paced modules
Learn Azure AI Foundry basics
Build a single agent with Azure AI Agent Service
Deep‑dive into Semantic Kernel
Create a multi‑agent solution
Practice tool integration (including MCP)
Use Azure’s evaluation tools
Monitor Microsoft Learn for new content

This sequence mirrors both the training and the exam structure.

Closing Thoughts

The March 19 training was a strong introduction to Microsoft’s agentic AI stack and a helpful starting point for AI‑103 beta preparation. With the syllabus now available, I’ve updated my study plan to align with Microsoft’s official direction.

I’ll continue sharing updates as I progress through the learning materials and as Microsoft releases more content leading up to the exam.

The post Building Agentic AI Solutions with Azure AI Foundry — My Training Day Review & Updated AI‑103 Study Plan appeared first on Behind the Build.

How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs

Jonathan Wong — Sun, 05 Apr 2026 02:13:55 +0000

A practical playbook to implementing Zero Trust architecture using AWS and Cloudflare. Covering edge security, identity controls, and data protection for modern cloud infrastructure.

As the founder of Jonanata, I often support clients who are growing fast but whose infrastructure hasn’t kept up with modern security expectations. One recent project stands out because it reflects a challenge many founders face:

How do you bring an existing production system closer to SOC 2 and PCI‑DSS expectations , without rewriting the application, without downtime, and without blowing the budget?

My client had a public‑facing mobile app backed by a legacy PHP API server built on a proprietary framework. It worked, but it wasn’t compliant, and it wasn’t defensible. They were already using AWS and Cloudflare — but only Cloudflare’s free plan.

The constraints were clear:

No application revamp
No downtime
Free or low‑cost solutions only
Compliance‑aligned security improvements
Immediate business value

This is the story of how I delivered a Zero Trust Architecture that strengthened every layer — AWS, Cloudflare, PHP, and Nginx — while keeping the system running and the budget under control.

Why Zero Trust, SOC 2, and PCI‑DSS Matter

Before diving into the solution, it’s worth explaining these concepts in business terms.

Zero Trust Architecture (ZTA)

A modern security model built on one principle:

Never trust anything by default — verify everything.

It protects businesses from:

Credential theft
Lateral movement inside servers
Insider threats
Misconfigurations
Public exposure

For founders, Zero Trust means reduced risk , better investor confidence , and stronger customer trust.

SOC 2

A widely recognized security and operational standard.

It focuses on:

Access control
Logging and monitoring
Network restrictions
Data protection
Operational discipline

Even if you’re not formally audited, aligning with SOC 2 makes your business more trustworthy to partners and enterprise clients.

PCI‑DSS

A security standard for systems that handle payment‑related data.

It emphasizes:

Network segmentation
Least privilege
Secure coding
Logging
Encryption

Even if you don’t process payments directly, PCI‑DSS alignment reduces the risk of data breaches and strengthens your compliance posture.

The Challenge: Secure a Legacy System Without Rewriting It

The client’s PHP backend was built on a proprietary framework. Rewriting it would take months and introduce risk. Instead, I designed a solution that wraps the existing system in Zero Trust , hardens every layer, and enforces strict access control — all without touching core business logic.

The only additional cost?

CloudWatch log storage.

Everything else used AWS native features and Cloudflare’s free plan.

AWS Layer: Identity‑Based Access and Network Isolation

1. IAM Roles Only — No Stored Keys

The production EC2 instance uses a dedicated IAM role (role-ec2-production) with:

Access only to specific S3 buckets
Access only to the RDS MySQL instance
Access only to CloudWatch
All permissions scoped to resource names
No IAM users, no access keys stored on the server

Business & compliance value:

No leaked keys, no credential rotation headaches, and full alignment with SOC 2 CC6.1 and PCI‑DSS 7.1.

2. Private EC2 — No Public IP

The production EC2 sits behind a new security group (sg-ec2-production) with:

No public IP
No inbound access from the internet
Only the bastion host can reach it via private IP

Business & compliance value:

The production server is invisible to attackers.

This satisfies PCI‑DSS 1.2.1 and SOC 2 CC6.6.

3. RDS: Identity‑Based Database Access

The MySQL database:

Accepts connections only from the production SG
Uses IAM authentication (no password stored anywhere)
Generates short‑lived tokens via AWS KMS
Grants the role-ec2-production only SELECT/INSERT/UPDATE/DELETE
No public IP and is accessible only inside the VPC
Is fully encrypted

Business & compliance value:

No database passwords to leak.

No over‑privileged accounts.

Meets PCI‑DSS 3.4, 7.2 and SOC 2 CC6.1.

4. S3: Fully Private With Pre‑Signed URLs

Block all public access
Upload/download only via pre‑signed URLs

Business value:

Keeps all PII and sensitive files private and off the public internet, reducing breach risk and supporting compliance with SOC 2 (CC6.6, CC6.7, CC9.1) and PCI‑DSS (3.4, 7.1, 10.2).

5. Logging: Fluent Bit + CloudWatch + Logrotate

Logs stored outside the web root
Fluent Bit ships logs to CloudWatch
Logrotate deletes rotated logs immediately

Business & compliance value:

Centralized, tamper‑resistant logs that satisfy SOC 2 CC7.2 and PCI‑DSS 10.x.

6. Bastion Host: Controlled, Auditable Access

Only turned on when needed
Only developer IPs allowed
Developers authenticate with their own SSH keys
Developers never see the production private key
A controlled script handles access to the production EC2

Business & compliance value:

No shared credentials.

Full accountability.

Meets SOC 2 CC6.3 and PCI‑DSS 8.x.

Cloudflare Layer: Strong Perimeter Security (Free Plan)

Even on the free plan, Cloudflare provides powerful security controls when configured correctly.

1. Cloudflare Tunnel — What It Is and Why It Matters

Cloudflare Tunnel creates an outbound‑only connection from the EC2 instance to Cloudflare.

This means:

The server is never exposed to the public internet
No open ports
No public IP
All traffic passes through Cloudflare’s Zero Trust layer

Compliance value:

Supports SOC 2 CC6.6 (network segmentation) and PCI‑DSS 1.3 (no direct public access).

2. mTLS With Client Certificates

A security mechanism where both the client and server present certificates, proving their identities before any data is exchanged.

This means:

The server to trust the client
The client to trust the server
Only devices with valid client certificates can reach the API
Prevents unauthorized devices, bots, or compromised workloads from connecting to your API
Eliminates blind trust inside the network and blocks lateral movement

Business & compliance value:

Even if someone discovers the tunnel URL, or credentials (JWT) leak they cannot bypass certificate‑based authentication to access the API.

This fulfills SOC 2 CC6.7 (strong authentication) and PCI‑DSS 8.x.

3. Cloudflare Worker: JWT Validation at the Edge

Before requests reach the EC2 instance, a Worker:

Validates the JWT
Rejects invalid or expired tokens
Ensures only authenticated traffic reaches the backend

Business & compliance value:

Reduces load on the server and blocks attacks early.

Supports SOC 2 CC7.1 (input validation) and PCI‑DSS 6.5.

PHP Layer: Hardening Without Rewriting Code

Even without modifying business logic, we strengthened the runtime environment.

1. Disable Dangerous Functions

Functions like exec, system, popen, etc. are disabled. Prevents remote command execution.

2. Disable URL File Access

Prevents remote file inclusion (RFI) attacks.

3. Disable legacy PHP features that automatically turn user input into variables

Attackers can exploit old PHP behaviors such as register_globals and magic_quotes_gpc, which implicitly convert or modify user input. Prevents malicious input from becoming variables and reduces the risk of remote code injection.

4. Hide PHP Version & Disable Error Display

Prevents attackers from fingerprinting the system.

5. Session Security Hardening

Protects against session hijacking and fixation.

6. PDO Everywhere

Prevents SQL injection.

Compliance value:

Hardens the PHP runtime without modifying business logic, eliminating high‑risk attack vectors (RCE, SQL injection, session hijacking) and strengthening compliance posture for SOC 2 and PCI‑DSS by enforcing safer defaults, strict input handling, and controlled execution paths.

Nginx Layer: API‑Focused Security Controls

No directory browsing
Block multipart uploads
Enforce correct Host header
Add HSTS and minimal CSP
Limit request size
Block directory traversal
Block hidden files except .well-known
Block sensitive files
Remove version numbers

Business & compliance value:

Reduces attack surface and prevents common web vulnerabilities.

Supports PCI‑DSS 6.6 and SOC 2 CC7.1.

Defense in Depth: How Each Layer Protects the Business

How Each Layer Protects the Business

This is Zero Trust in practice : every layer assumes nothing is safe and verifies everything.

The Outcome: Compliance‑Aligned Security Without Rewrites or Cost Overruns

By applying Zero Trust principles across AWS, Cloudflare, PHP, and Nginx, we delivered:

A secure, compliant, modernized backend
No application rewrite
No downtime
No expensive tools
Only CloudWatch storage cost
A defensible security posture aligned with SOC 2 and PCI‑DSS

For the client, this meant:

Stronger trust with users
Better readiness for enterprise partnerships
Reduced operational risk
A future‑proof foundation for growth
A compliance‑aligned architecture that enables expansion into regulated or restricted markets without major rework
A security posture that meets the expectations of partners operating in highly controlled industries and jurisdictions

This is the kind of security upgrade that delivers real business value , not just technical improvements.

What’s Next

I’ll publish a deeper technical breakdown on my next AWS Builder Center article, including full configuration examples and source code in my GitHub repository.

The post How I Delivered Zero Trust Security for a Client’s Legacy PHP System — Without Rewrites, Downtime, or Big Costs appeared first on Behind the Build.