Skip to content

I turn infrastructure and security that people had to remember into systems that hold on their own.

I have run, moved, and automated game services and financial infrastructure across four clouds: AWS, Azure, GCP, and Tencent Cloud.

C&ThothAzureCom2us PlatformAWSGCPAzureTencentWoori FISAWSPersonal projects
4 clouds, 3,500 servers, 85% remediation, 0 downtime
  1. C&Thoth

    Aug 2020 – Feb 2023

    Protecting a client's large game

  2. Com2us Platform

    Feb 2023 – Feb 2026

    Running and moving four clouds

  3. Woori FIS

    Feb 2026 – Oct 2026

    Designing from zero under regulation

4
Clouds
3,500
Servers
85%
Remediation
0
Downtime

Featured stories

From a monthly security review to a daily automatic one

Catching risky actions across four clouds on the day they happen

One month?????????????????????????????ReviewAWSCloudTrailGCPCloud Audit LogsAzureActivity LogTencent CloudCloudAudit●●●●▲▲▲▲■■■■★★★★NormalizeWho · When · Where · WhatAWS · game-a-prod · Access Key issuedGCP · game-b-live · Project role addedTencent · game-c-cn · Security group rule addedAzure · tool-rg · Server createdResolvedResolvedSlackTelegramAutomatic review every day before dawnMonthly → Daily
Back to the calendar. This time every day gets a check. Monthly → Daily.

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. Review effort dropped to effectively zero.

What I learned

Defining the signals that lead to incidents, and never missing them, matters more than analysis after the fact. Without authority, "I tried this and it got better" persuades more than "we should do this".

Moving a live game between clouds without stopping it

80 servers, 20 databases, about one week, zero downtime

LIVEGCPTencent CloudFirewall rules firstOnline Migration · 80 server blocksPrivate validationTraffic cut overAbout 1 week · 0 downtimegcp.tf → tencentcloud.tf
Below the islands, the code: gcp.tf → tencentcloud.tf

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.

What I learned

When you move clouds, make the security standard move with you. The migration also stayed in Terraform code, which made later operations and changes easier.

Stopping 3 a.m. DDoS attacks with no one on the keyboard

Automated detection and blocking using logs that were already there

03:00Office lights outGame serviceMitigation flow logsSources with abnormal SYN volumeNSG block rules203.0.113.x203.0.113.x203.0.113.xNo one stepped in. The service kept running.
The office stays dark and the game service stays green.

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.

What I learned

Before adding a tool, see what the logs you already have can do. Stopping the attack is not enough. Build something that holds when it happens again.

Setting a security baseline for a financial cloud that had none

Network separation as structure, security settings as code

DMZ subnetPrivate subnetRegulationSeparate the DMZNo public IPsApproved exits onlyWallLocked doorNarrow exitOne codebase, every accountTerraform codeAccount AAccount BAccount C…New accounts get the same security baseline
The same shield lights up on every box.

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.

What I learned

Put a rule in structure and code instead of a document, and every deployment meets the same bar.

By the numbers

4
Clouds (AWS · Azure · GCP · Tencent)
3,500
Servers run as the dedicated engineer
80%
Faster deployments
40%
Shorter deployment time
60% → 85%+
Audit remediation rate
0
Downtime during migration
Monthly → Daily
Security review cycle
600
Servers covered by the firewall redesign

How they connect

Separate experiences that turn out to be one line of thought

All field notes

Theme
Company 24
3,500 servers650 databasesDedicated engineerOutageRecovered

C&Thoth · Aug 2020 – Feb 2023

Dedicated engineer for a 3,500-server global game

Keeping a client's service running, with large-scale Azure operations and technical advice

3,500 Servers650 DBs

  • · Lead technical contact for the client
  • · High-availability architecture advice
  • · Incident response, security audit, and cost analysis support
  • Azure
  • Large-scale operations
  • Client-facing
03:00Office lights outGame serviceMitigation flow logsSources with abnormal SYN volumeNSG block rules203.0.113.x203.0.113.x203.0.113.xNo one stepped in. The service kept running.

C&Thoth · Aug 2020 – Feb 2023

Stopping 3 a.m. DDoS attacks with no one on the keyboard

Automated detection and blocking using logs that were already there

Detect → block automated0 human steps

  • · Attacks clustered at night and on weekends, when response was slowest
  • · Solved at no added cost by reusing existing logs
  • · Detection results feed firewall rules automatically
  • Azure
  • DDoS
  • Automation
  • PowerShell
  • Response automation
Manual deploymentPowerShell scriptManual 100Automated 20-80%

C&Thoth · Aug 2020 – Feb 2023

Deploying to 500 servers, 80% faster

Automated with PowerShell what people repeated server by server

80% faster500 Servers / 100 DBs

  • · Manual steps repeated for every server group
  • · Steps bundled into a script that runs automatically
  • · One procedure instead of one per engineer
  • Azure
  • PowerShell
  • Deployment automation
ServersMetricsTelegrafCollectInfluxDBStoreGrafanaDashboardCPUMemoryTraffic

C&Thoth · Aug 2020 – Feb 2023

Infrastructure status at a glance, in real time

  • · Real-time dashboards with Telegraf, InfluxDB, and Grafana
  • · Monitoring operations with Zabbix and Grafana
  • Monitoring
  • Grafana
One month?????????????????????????????ReviewAWSCloudTrailGCPCloud Audit LogsAzureActivity LogTencent CloudCloudAudit●●●●▲▲▲▲■■■■★★★★NormalizeWho · When · Where · WhatAWS · game-a-prod · Access Key issuedGCP · game-b-live · Project role addedTencent · game-c-cn · Security group rule addedAzure · tool-rg · Server createdResolvedResolvedSlackTelegramAutomatic review every day before dawnMonthly → Daily

Com2us Platform · Feb 2023 – Feb 2026

From a monthly security review to a daily automatic one

Catching risky actions across four clouds on the day they happen

Monthly → Daily4 Clouds

  • · Found the gap myself, with no one asking
  • · One standard across four different cloud log formats
  • · Only critical actions trigger an alert and follow-up
  • Python
  • AWS
  • GCP
  • Azure
  • Tencent
  • Security automation
  • Detection & response
No service impactService impactHigh riskLow riskFindingFindingFindingFindingFindingFindingFindingFindingFindingFindingBlockDev teamClose the portentirely?IP restriction + WAFTerraform moduleDefaults60%85%Audit remediation rate

Com2us Platform · Feb 2023 – Feb 2026

Making sure the same finding never comes back

Sort by impact, agree on alternatives, and block it with code defaults

60% → 85%+

  • · Sorted by service impact instead of blocking everything
  • · Agreed on compensating controls when blocking was not possible
  • · Repeated findings became Terraform defaults and deployment gates
  • CSPM
  • Terraform
  • GitLab CI/CD
  • Jenkins
  • Collaboration
TerraformCopied codeTerraformCopied codeTerraformCopied codeTerraformCopied codeTerraformCopied codeTerraformCopied codeNeeds fixNeeds fixNeeds fixNeeds fixNeeds fixEditedCommon moduleSecurity defaultsdevDifferencesstgDifferencesprodDifferences-40%

Com2us Platform · Feb 2023 – Feb 2026

One codebase instead of copied infrastructure code

Moved live infrastructure into code, removed duplication, and cut deployment time 40%

-40% deploy time

  • · Moved running infrastructure into code
  • · Replaced per-environment and per-game copies with a shared structure
  • · Security defaults apply to every environment at once
  • Terraform
  • Terragrunt
  • IaC
  • AWS
  • GCP
LIVEGCPTencent CloudFirewall rules firstOnline Migration · 80 server blocksPrivate validationTraffic cut overAbout 1 week · 0 downtimegcp.tf → tencentcloud.tf

Com2us Platform · Feb 2023 – Feb 2026

Moving a live game between clouds without stopping it

80 servers, 20 databases, about one week, zero downtime

1 Week0 Downtime80 Servers / 20 DBs

  • · Decided to move firewalls before servers
  • · Migration tool plus private validation
  • · The entire migration captured in Terraform code
  • GCP
  • Tencent Cloud
  • Migration
  • Terraform
WebGameDBAdmin

Com2us Platform · Feb 2023 – Feb 2026

Redesigning a tangle of firewall rules

Cleaning up policy across Tencent Cloud and GCP for 600 servers and 70 databases

600 Servers / 70 DBs

  • · Reviewed every long-accumulated rule
  • · Removed duplicate and unnecessary rules
  • · Redesigned around server roles
  • Firewall
  • Tencent Cloud
  • GCP
  • Network Security
Tencent CloudGCPCloud Armor600 servers

Com2us Platform · Feb 2023 – Feb 2026

Stopping attacks on game servers

  • · Ran DDoS detection and defense for a 600-server game
  • · Used Cloud Armor for DDoS protection on GCP
  • DDoS
  • Cloud Armor
  • Tencent Cloud
  • GCP
SlackAlertTelegramAlertZabbix · Grafana

Com2us Platform · Feb 2023 – Feb 2026

Knowing first when something goes wrong

  • · Monitoring with Zabbix and Grafana
  • · Alerts through Slack and Telegram
  • · Monthly cost analysis (FinOps)
  • Zabbix
  • Grafana
  • FinOps
Make an S3 bucket moduleChroma vector DBSimilar codeSimilar codeSimilar codeLocal LLMGenerated Terraform codeModuleModuleModuleNext designLangChain

Com2us Platform · Feb 2023 – Feb 2026

An AI that writes infrastructure code from a plain request

A prototype with a local LLM and a vector database, and the limits found in testing

  • · RAG structure using production modules as reference material
  • · Taken as far as a team demo
  • · Diagnosed the limits myself and drew up the next design
  • AI
  • LLM
  • RAG
  • Ollama
  • Chroma
  • Docker
  • Terraform
DMZ subnetPrivate subnetRegulationSeparate the DMZNo public IPsApproved exits onlyWallLocked doorNarrow exitOne codebase, every accountTerraform codeAccount AAccount BAccount C…New accounts get the same security baseline

Woori FIS · Feb 2026 – Oct 2026

Setting a security baseline for a financial cloud that had none

Network separation as structure, security settings as code

IaC 0 → Terraform standard

  • · Financial network separation turned into design principles
  • · Network Firewall and WAF standardized as code
  • · The same baseline as accounts are added
  • AWS
  • Terraform
  • Network separation
  • Network Firewall
  • WAF
  • Finance
Key ringOnly what is neededcode

Woori FIS · Feb 2026 – Oct 2026

Only the access you need, recorded in code

  • · Zero Trust principle
  • · Service account and role permissions in Terraform
  • · New permissions must pass code review
  • IAM
  • Zero Trust
  • Terraform
Account AAccount BAccount CGuardDutyFinds threatsSecurity HubOne formatSplunk SIEMUnified monitoring

Woori FIS · Feb 2026 – Oct 2026

Alerts from many accounts on one screen

  • · GuardDuty and Security Hub connected to Splunk SIEM
  • GuardDuty
  • Security Hub
  • Splunk
  • SIEM
Act 2 · AfterOuter gateCloudFrontInner gateALBServerKRGuard (checkpoint)Trusts the noteChecks the real IPProof that it blocksSourceCountryResult203.0.113.xAbroadBlocked203.0.113.xAbroadBlocked

Security case

"Turned on" and "actually blocking" are different things

Finding where a block policy could be bypassed, fixing it, and proving it with logs

  • · Found the bypass by tracing the architecture
  • · Fixed it by moving the check to the outer edge
  • · Verified the block through log analysis
  • WAF
  • CloudFront
  • Athena
  • Log Analysis
Closed-network PCResource inventoryTraffic log searchReachability checkRequest-based applyReachability checkSourceSecurity groupSource outboundSecurity groupDestination inboundRoutingRequest to the infrastructure teamThe security group stays closedRequest-based applyRequest sheetExisting ruleExisting ruleExisting ruleOne rule applied

Woori FIS · Feb 2026 – Oct 2026

Operations tools that run on a PC with no internet

Turning repeated requests into tools and a standard process

4 tools31 Python packages, bundled offline

  • · Offline Windows development environment bundle
  • · Reachability checks that name the cause
  • · Excel request forms applied as real security group rules
  • Python
  • boto3
  • AWS
  • Automation
  • Closed network
Physical firewall policySecurity group policySourceDestinationPortAllow or denyReasonSourceDestinationPortAllow or denyReasonSame structure

Woori FIS · Feb 2026 – Oct 2026

Explaining in the language the other person already knows

  • · Security group policies documented in the physical firewall policy format
  • · An access and operations guide for engineers new to AWS
  • Documentation
  • Security Group
  • Onboarding
Filter netCapture filepcapng files converted in one pass

Woori FIS · Feb 2026 – Oct 2026

Less time spent capturing packets

  • · FortiGate packet capture commands built automatically
  • · pcapng files converted in one pass
  • FortiGate
  • Packet Capture
  • Python
Monthly reviewsJanFebMarAprMayJunJulAugSepOctNovDecHandover notesNext owner

Woori FIS · Feb 2026 – Oct 2026

Owning the security checks that repeat every month

  • · Operated FortiGate, FortiManager, FortiAnalyzer, WAF, and WIPS
  • · Monthly firewall policy adequacy reviews
  • · Handed the work over with written handover notes
  • Fortinet
  • WAF
  • WIPS
  • Regular reviews
Physical perimeter firewallNorth-SouthBetween outside and insideServer AServer BServer CEast-WestPlatform policyEach control takes the direction it handles best

Woori FIS · Feb 2026 – Oct 2026

A security review that tested requirements with numbers

  • · Security requirements organized into common, physical, and logical
  • · Platform capacity compared with the required level, in figures
  • · Proposed a split of duties for north-south and east-west traffic
  • Security review
  • Network separation
  • Microsegmentation
ManagementTechnologySalesChief of StaffFinanceHRTech LeadSenior EngineerEngineerQA EngineerSecurity EngineerDB EngineerPlanning & SalesLeadContent Marketer(off by default)CCTVDirectivePlanReviewrequestThe error travels uncheckedThe next agent trusts it without checkingPrevious agentNext agentAdd a verification stepPrinciple from this project · not a built feature

Personal projects

A virtual company staffed by 11 AI employees

A hand-built multi-agent orchestrator, and the trust boundary problem found inside it

11 Agents3 Divisions

  • · Role-based assignment, model priority with fallback, and cost tracking
  • · Slack, Jira, and GitHub connections, plus a pixel-art office dashboard
  • · Firsthand experience of agents trusting each other without checks
  • AI
  • Multi-Agent
  • Slack
Security group inbound not allowed

Personal projects

A service that answers "can these two talk?" in two clicks

An AWS network visualization and reachability service born from daily work (in progress)

  • · AWS resources across accounts and regions in one diagram
  • · Reachability between two resources, with the policy behind it
  • · Installed in the customer's own environment (BYOC)
  • AWS
  • Visualization
  • SaaS
  • BYOC
  • CloudFormation
  • AI
Public repository seriesPF-01AWS TerraformPF-02GCP TerraformPF-03Tencent TerraformPF-04AWS TerragruntPF-05Multi-cloud auditPF-06AetherCrewPF-09AWS NetOpsKeys and sensitive values masked or replaced

Personal projects

A public repository series for this portfolio

Rebuilding existing practice and tool repositories as numbered public repositories (in progress)

  • · Rebuilt as numbered public repositories
  • · Keys and sensitive values masked or replaced with examples
  • · Each repository linked to the related experience
  • GitHub
  • Terraform
  • Terragrunt

Principles from the work

What I am working on now

Open to work · Cloud infrastructure and security