AWS-Assisted WireGuard Remote Access

Overview

This project uses an AWS EC2 instance as a WireGuard relay to provide secure remote access back into my home network. It allows remote devices to reach internal services and infrastructure that I intentionally do not expose through a reverse proxy or other public-facing path.

The design solves a real networking limitation in my home environment while keeping the lab mostly self-hosted, private by default, and accessible when I am traveling or away from my local network.

Problem This Project Solves

While traveling for work, I realized that I could not continue managing or improving my homelab if I had no secure way to reach it away from home.

My initial plan was to use WireGuard through the UniFi interface, but I discovered that my ISP places my home connection behind Carrier-Grade NAT. That meant I did not have a directly routable public IPv4 address available for reliable inbound VPN connections.

I needed a remote-access design that worked around that limitation without exposing internal services directly to the public internet.

Goals

The goals of this project were to:

• Create a secure remote path back into my home network while traveling
• Work around CGNAT without requiring inbound connections directly to my home ISP connection
• Keep the architecture low-cost and easy to reason about
• Support additional remote clients over time
• Preserve a private-by-default approach for internal services

Environment or Constraints

At the time of this project, my homelab had already grown to include several self-hosted virtual machines, working NAS integrations, and SSH-based administration for much of my Proxmox environment.

That design kept recurring cost low and reduced public exposure, but it also meant nearly all of the systems I was actively learning from lived behind my home network boundary. Traveling for work created a practical limitation: I could continue planning the lab, but not meaningfully operate or troubleshoot it without a secure remote path back in.

The final design needed to respect several constraints:

• My home connection was behind CGNAT
• I did not want to expose internal services unnecessarily
• The solution needed to stay low-cost
• It needed to support more than one remote client over time

Final Architecture

The final design uses a small AWS-hosted relay as the stable meeting point between remote devices and the homelab.

• AWS EC2 relay

  • Runs WireGuard
  • Uses a stable public endpoint
  • Accepts encrypted tunnel connections from approved peers

• Home WireGuard gateway VM

  • Lives inside the homelab
  • Establishes an outbound tunnel to the AWS relay
  • Routes permitted traffic toward internal lab resources

• Remote client devices

  • Phone and laptop clients connect to the relay
  • Traffic intended for approved homelab resources is routed through the relay to the home gateway VM

Because direct inbound tunneling to the home network was blocked by CGNAT, the AWS relay provides the publicly reachable anchor point that the home gateway and remote clients can both reach.

Design Decisions

I chose to build the relay in AWS EC2 for two reasons.

First, I needed a stable public endpoint outside my CGNAT-constrained home network. A small cloud VM provided that reachable anchor without requiring me to change my home ISP situation or expose internal services directly.

Second, I wanted the project to become a practical AWS learning exercise. Deploying the relay gave me experience with EC2 provisioning, elastic IP planning, security group decisions, cost visibility, and the operational responsibilities that come with running even a small public-facing compute instance.

This also leaves room for future improvements such as CloudWatch-based visibility, stronger logging, and more deliberate automation around lifecycle management.

Implementation Path

1. Provisioned an AWS EC2 relay with a stable public address.
2. Installed and updated Ubuntu Server on the relay host.
3. Installed WireGuard on the relay and on the initial home-network client.
4. Generated and exchanged public keys between peers while keeping private keys local to each device.
5. Configured the relay and home WireGuard gateway VM so the homelab could be reached through the tunnel.
6. Added additional remote client devices and updated the relay configuration to recognize them.
7. Adjusted UniFi firewall and routing rules so tunneled traffic could reach the intended internal networks.
8. Validated the design from outside the home network by testing connectivity to the relay, the home gateway, and selected internal resources.

What I’m Learning

This project taught me quite a bit about cloud-assisted networking and how local firewall behavior can become the hardest part of an otherwise straightforward design:

• How CGNAT affects self-hosted remote access strategies
• How WireGuard peers, keys, and allowed IPs shape tunnel behavior
• Why firewall and routing rules matter as much as the tunnel itself
• How to expose a public entry point without broadly exposing internal services
• The importance of tracking generated keys and peer configurations carefully
• How a small cloud service can extend a mostly local infrastructure model

Current Status

This project is currently in production for two remote client devices: my phone and my laptop.

From those clients, I can securely reach selected services, servers, and storage resources inside my home network while traveling. The relay has solved the original CGNAT constraint and has become a stable part of how I continue working on the homelab away from home.

Planned Improvements

• Add traffic visibility and logging for the relay host
• Explore IDS/IPS or other lightweight monitoring around the exposed cloud endpoint
• Document a standardized process for securely onboarding additional remote clients
• Evaluate whether relay lifecycle automation could reduce cost without harming reliability
• Create a sanitized architecture diagram showing the traffic path between remote clients, AWS, and the homelab

Lessons Learned

I was surprised by how straightforward the WireGuard configuration itself felt compared with the routing and firewall work required to make the design useful in practice.

The cloud relay and peer configuration came together fairly quickly. The harder part was making sure the local UniFi rules allowed the right traffic to move from the tunnel into the intended internal networks without opening more access than necessary.

That troubleshooting took longer than the rest of the project combined, but it also made the architecture much clearer to me. I now have a far better understanding of where those controls live, how they affect remote-access designs, and how to extend the model as the homelab grows.

Related Documentation

• Full technical write-up on GitHub: homelab/docs/networking/aws-wireguard-ec2-hop.md
• Planned: sanitized traffic-flow architecture diagram