Eric Connelly

Solutions Consultant II at Google

Complex systems.
Clear next steps.

I’m Eric Connelly, a Solutions Consultant II at Google focused on cloud security and customer adoption. My background spans cloud engineering at TELUS Health and customer cloud support at AWS.

View my experience Connect on LinkedIn ↗

Experience

Engineering foundation. Customer focus.

Google

Solutions Consultant II

Support cloud-security customers through technical questions, adoption blockers, and renewal-risk conversations, coordinating next steps with account executives and solutions engineers.

Amazon Web Services

Cloud Support Engineer

Troubleshoot customer cloud environments and explain technical findings, workarounds, and next steps.

TELUS Health

Cloud Engineer

Worked on cloud infrastructure and Kubernetes environments before moving into customer-facing cloud support.

Earlier experience

Software Engineer Intern, Varicent · May 2020–Aug 2021. Cloud Engineer, Pegasystems · Mar 2024–Jun 2024.

Personal infrastructure projects

Architecture & operations

Personal project · AWS

On-demand infrastructure
for multiplayer sessions.

A personal control panel for starting temporary game servers on AWS, checking readiness, and preserving supported game worlds between sessions.

Personal project developed with AI coding assistance. This walkthrough explains the operating model, design choices, and limitations.

Step FunctionsEC2DynamoDBS3
Explore the launcher ↗Read the design notes ↓

Simplified launch path

BrowserLaunch APIStep FunctionsEC2

DynamoDB tracks ownership and capacity. Readiness checks gate joining details. S3 retains supported game worlds.

Concurrency limitUp to two simultaneous runtimes.
Session cleanupIdle shutdown and a maximum session duration.
Backup verificationBackup checks before normal termination.

AWS · Static delivery

This portfolio, from source to delivery.

Static HTML served through S3 and CloudFront, with GitHub-to-CodePipeline deployment. The choice trades dynamic application features for a small hosting footprint and a repeatable deployment path.

View public source ↗

Architecture decisions

Design behavior, tradeoffs, and limits
Check the application before showing “ready.”Reliability

Instance health is only the first check. The launcher waits for the game service and protocol response before publishing joining details. A boot delay or failed startup stays visible as a startup problem.

The tradeoff: readiness takes longer than simply exposing an IP address, but players receive an application-level signal rather than an infrastructure status.

Separate temporary compute from saved worlds.Data lifecycle

Persistent world data lives beyond the runtime. The normal shutdown path stops the game and checks its S3 backup before termination. Recovery paths retain the instance or create a snapshot when verification fails.

The tradeoff: recovery can retain storage or compute longer than a normal session. Backup verification is a design safeguard, not a guarantee against every data-loss scenario.

Make cleanup part of the design.Operations

Concurrency limits, idle shutdown, and session deadlines reduce accidental compute use. A watchdog reconciles expired or unexpected states. Cleanup is part of the lifecycle rather than a reminder to the operator.

The tradeoff: stored worlds, snapshots, networking, and control-plane requests continue to incur charges between sessions.

Let’s connect

Let’s talk cloud
and customer challenges.

Connect on LinkedIn ↗GitHub ↗