KIM JUNHYUNHANN.

Dedicated engineer for a global MMORPG with 3,500 servers and 650 databases, covering Azure operations and technical advice.

Highlights

Lead technical contact for the client

Highlights

High-availability architecture advice

Highlights

Incident response, security audit, and cost analysis support

• Azure
• Large-scale operations
• Client-facing

Connected Azure logs that already existed so DDoS detection through blocking runs with no human steps.

Problem

Attacks clustered at night and on weekends, when the fewest people were on hand. While someone read the alert, logged in, found the attacking IPs, and added block rules, the service shook.

Judgment

Instead of adding staff or buying a new product, I used logs that already existed. Azure's DDoS protection was already recording where attacks came from.

What I did

Sources sending abnormally many TCP SYN packets became attack candidates. Scheduled queries pull those IPs, and a PowerShell script adds them to NSG (firewall rule set) block rules automatically.

Result

Detection through blocking now runs with no human steps, which removed the night and weekend response delay. It needed no new product and no extra staff.

• Azure
• DDoS
• Automation
• PowerShell
• Response automation

Bundled deployment steps people repeated for every server group into PowerShell scripts, making deployments 80% faster.

Highlights

Manual steps repeated for every server group

Highlights

Steps bundled into a script that runs automatically

Highlights

One procedure instead of one per engineer

• Azure
• PowerShell
• Deployment automation

Built real-time dashboards with Telegraf, InfluxDB, and Grafana, and ran monitoring with Zabbix and Grafana.

Highlights

Real-time dashboards with Telegraf, InfluxDB, and Grafana

Highlights

Monitoring operations with Zabbix and Grafana

• Monitoring
• Grafana

Replaced a multi-day manual month-end review of four clouds with a daily automatic one that surfaces risky actions the same day.

Problem

Security reviews happened once a month and took days of manual work. If someone gave themselves excessive permissions or deleted a key server, we might not know for nearly a month. No one asked me to fix it. I decided to change it myself.

Judgment

Even a simple permission change was recorded differently in every cloud. I chose to convert every log to one common standard, "who did what, to which resource, and when".

What I did

Audit logs from every project in all four clouds are collected, normalized, and reviewed automatically before dawn each day. Only actions that could lead to an incident count as critical. They go to Telegram and Slack, and are recorded as resolved after the actor confirms.

Result

The review cycle went from monthly to daily, and awareness of risky actions went from up to a month later to the same day. No one had to set time aside for it anymore; the review was already done automatically at the same time every day.

• Python
• AWS
• GCP
• Azure
• Tencent
• Security automation
• Detection & response

Sorted security findings by service impact, agreed on compensating controls, and turned repeated findings into code defaults, raising the audit remediation rate from 60% to over 85%.

Highlights

Sorted by service impact instead of blocking everything

Highlights

Agreed on compensating controls when blocking was not possible

Highlights

Repeated findings became Terraform defaults and deployment gates

• CSPM
• Terraform
• GitLab CI/CD
• Jenkins
• Collaboration

Moved live infrastructure into code and replaced copied Terraform with a shared Terragrunt structure, cutting deployment time 40%.

Highlights

Moved running infrastructure into code

Highlights

Replaced per-environment and per-game copies with a shared structure

Highlights

Security defaults apply to every environment at once

• Terraform
• Terragrunt
• IaC
• AWS
• GCP

Moved the GCP infrastructure of Summoners War: Chronicles (80 servers, 20 databases) to Tencent Cloud in about one week with zero downtime.

Problem

A live service on GCP (80 servers, 20 databases) had to move to Tencent Cloud. Downtime was not acceptable.

Judgment

The biggest risk was security policy going missing or changing during the move. So I moved the network and firewall first, before any server.

What I did

Firewall rules were built on Tencent Cloud to match GCP first, then servers moved with Online Migration. Before cutover, the dev team and I checked for issues in private validation.

Result

After validation the service was cut over. The migration finished in about one week with zero downtime.

• GCP
• Tencent Cloud
• Migration
• Terraform

Reviewed every firewall rule across Tencent Cloud and GCP for 600 servers and 70 databases, then redesigned them around server roles.

Highlights

Reviewed every long-accumulated rule

Highlights

Removed duplicate and unnecessary rules

Highlights

Redesigned around server roles

• Firewall
• Tencent Cloud
• GCP
• Network Security

Ran DDoS detection and defense for a 600-server game on Tencent Cloud and GCP.

Highlights

Ran DDoS detection and defense for a 600-server game

Highlights

Used Cloud Armor for DDoS protection on GCP

• DDoS
• Cloud Armor
• Tencent Cloud
• GCP

Watched server and database metrics with Zabbix and Grafana, responded to Slack and Telegram alerts, and analyzed monthly costs.

Highlights

Monitoring with Zabbix and Grafana

Highlights

Alerts through Slack and Telegram

Highlights

Monthly cost analysis (FinOps)

• Zabbix
• Grafana
• FinOps

Built an infrastructure code generation prototype with a local LLM and a vector database, demoed it to the team, and found its limits in testing. It did not reach day-to-day use.

Highlights

RAG structure using production modules as reference material

Highlights

Taken as far as a team demo

Highlights

Diagnosed the limits myself and drew up the next design

• AI
• LLM
• RAG
• Ollama
• Chroma
• Docker
• Terraform

I moved network separation rules out of documents and into structure and code, so every new account gets the same security baseline.

Problem

The group's companies were adopting public cloud for the first time, and there was no IaC (managing infrastructure as code) at all. Each account had different needs, but the common security baseline had to hold everywhere.

Judgment

I turned network separation (a Korean financial regulation that splits networks by sensitivity so outside threats cannot reach inside directly) into three design principles. Separate DMZ and Private subnets, no public IPs on backend resources, and outbound traffic to approved destinations only.

What I did

I introduced Terraform, defined Network Firewall and WAF as code, and applied the same code to every account.

Result

As accounts are added, the same security baseline repeats through code. Settings no longer vary by engineer.

• AWS
• Terraform
• Network separation
• Network Firewall
• WAF
• Finance

I defined service account and role permissions in Terraform, so that granting too much access became structurally difficult.

Highlights

Zero Trust principle

Highlights

Service account and role permissions in Terraform

Highlights

New permissions must pass code review

• IAM
• Zero Trust
• Terraform

I connected GuardDuty, Security Hub, and Splunk SIEM to monitor security events across multiple AWS accounts in one place.

Highlights

GuardDuty and Security Hub connected to Splunk SIEM

• GuardDuty
• Security Hub
• Splunk
• SIEM

In a CDN and load balancer setup, I found where a geo-block policy could be bypassed, fixed it, and proved the block with logs. This case is already fixed.

Highlights

Found the bypass by tracing the architecture

Highlights

Fixed it by moving the check to the outer edge

Highlights

Verified the block through log analysis

• WAF
• CloudFront
• Athena
• Log Analysis

I built an offline development environment and four Python tools for work PCs with no internet, turning repeated traffic requests into a standard process.

Highlights

Offline Windows development environment bundle

Highlights

Reachability checks that name the cause

Highlights

Excel request forms applied as real security group rules

• Python
• boto3
• AWS
• Automation
• Closed network

I documented security group policies in the physical firewall format the team already knew, so engineers new to AWS could start work right away.

Highlights

Security group policies documented in the physical firewall policy format

Highlights

An access and operations guide for engineers new to AWS

• Documentation
• Security Group
• Onboarding

I automated FortiGate capture commands and pcapng file conversion with Python, which shortened the time needed to prepare an analysis.

Highlights

FortiGate packet capture commands built automatically

Highlights

pcapng files converted in one pass

• FortiGate
• Packet Capture
• Python

I operated firewalls, WAF, and WIPS, wrote the regular monthly review reports, and documented that work in handover notes when I left.

Highlights

Operated FortiGate, FortiManager, FortiAnalyzer, WAF, and WIPS

Highlights

Monthly firewall policy adequacy reviews

Highlights

Handed the work over with written handover notes

• Fortinet
• WAF
• WIPS
• Regular reviews

I handled the security part of a review for adopting a new virtualization platform. I organized the requirements, tested them with numbers, and proposed a split of duties by traffic direction.

Highlights

Security requirements organized into common, physical, and logical

Highlights

Platform capacity compared with the required level, in figures

Highlights

Proposed a split of duties for north-south and east-west traffic

• Security review
• Network separation
• Microsegmentation

I built a virtual company of 11 AI employees on a hand-built orchestrator, and saw firsthand the trust boundary problem when agents accept each other's work without checks.

Highlights

Role-based assignment, model priority with fallback, and cost tracking

Highlights

Slack, Jira, and GitHub connections, plus a pixel-art office dashboard

Highlights

Firsthand experience of agents trusting each other without checks

• AI
• Multi-Agent
• Slack

I am turning the manual work of tracing AWS traffic paths in the console into a service where you pick two resources on a diagram and get an answer.

Highlights

AWS resources across accounts and regions in one diagram

Highlights

Reachability between two resources, with the policy behind it

Highlights

Installed in the customer's own environment (BYOC)

• AWS
• Visualization
• SaaS
• BYOC
• CloudFormation
• AI

I am rebuilding my existing GitHub practice and tool repositories as numbered public repositories and linking them to each experience.

Highlights

Rebuilt as numbered public repositories

Highlights

Keys and sensitive values masked or replaced with examples

Highlights

Each repository linked to the related experience

• GitHub
• Terraform
• Terragrunt