I'm working on an online card game. We use a simple client-server architecture. Each game involves the player being matched with another user (or the computer AI) and then the game runs until someone wins or concedes, usually 5-10 minutes. Currently we run a single game server.

I'd like to know how I can scale the system to accommodate more players in the future. My initial thought was to have a front edge server to perform load balancing, matchmaking and security functions, which sends player updates to the appropriate server and evenly distributes the players across the servers. As we run additional servers, they will register with the front edge server. Is there commercial or open source software that already does something like this? Currently, the servers are i/o bound with a large number of players but I'm concerned that in the future, it will be network traffic on the front edge server that will be the bottleneck. Is there a way to hand-off the network traffic to a server once the players are matched? What other architectures should I consider?

Many thanks in advance. I realize that there isn't a lot of data here but would appreciate any pointers and ideas.

Are there commercial or open source load balancers? Yes.
Try haproxy for an open source package.
Try any modern ingress router with DNAT for commercial hardware.
Also, typically it's the load balancer that does liveness check on the app servers, rather than the other way around, by making some null request every few seconds.

My main question to you is what your game state looks like, and what your communications looks like.
If game state can be persistently stored between game turns, then each request can be stateless. The serving app server would just slurp in the game state, perform the action, and store the new game state back. This would work very well with existing HTTP scalability infrastructure.
Almost any database should be able to keep those games in RAM for fast access. Or go with something that's explicitly RAM-based, such as Redis.
You'd want long-term data (like rankings/scoring/winnings/etc) to live in a more traditional disk-based relational database though.

Finally -- how come you are I/O bound? Your workload does not sound to me like it should be like that. Probably, something is tuned or implemented unwell...