Features
| Pricing | Documentation | Contact | Blog
Features
| Pricing | Documentation | Contact | Blog
Proxylity eliminates the cost and overhead of running network services on VMs (EC2, Fargate, EKS, etc.) by providing the network connections (IP addresses and ports) for your service traffic and delivering the packets that arrive on them to resources in your AWS account (Lambda, StepFunctions, S3, DDB, SNS, etc.). You have complete control over your data -- how and where it is processed and stored. Proxylity does not store or inspect network traffic beyond what's neccessary to deliver it to your serverless backend (which is very little).
This means instead of running a "server" to handler UDP, you might deploy a Lambda function or simply direct the traffic to a Firehose for archival. It's a simple idea, but enables a big step in modernizing network applications by eliminating painful and undifferentiated work and allowing your team to focus on business logic and features instead.
This isn't a new idea, rather it applies an old idea to a new protocol. For HTTP there are myriad options like AWS API Gateway and Application Load Balancers that eliminate HTTP servers from your architectures and facilitate moving to serverless. Now, for your UDP traffic there is Proxylity.
Still, let's be plain about it: Proxylity may not be for you.
If you are happy (and effective) using cloud VMs (or containers) running off-the-shelf network server code then the fundamental idea behind Proxility may not be right for you. Proxility's purpose is to eliminate those VMs and connect traffic directly to serverless resources instead. For many organizations eliminating the customization, mainenance and operation work (security) of VM-based server software empowers developers and results in faster delivery of new features.
If your team has made the leap to service- and event-oriented architectures but are struggling to breaking-free of legacy servers, Proxylity may be a great simplifying addition your architectures.
Maybe this sounds familiar: You started with a single container but a couple of high-profile outages motivated scaling-out to run them in multiple Availability Zones; then, latency became an issue in some part of the world and now you're running them in multiple regions with latency based routing; then, a couple critical vulnerabilities were found in audit and now you're testing and deploying patches regularly. Maybe one or two people understand how to keep it going. Or, maybe not and you know it may end poorly.
The above may seem like a "Fear, Uncertainty and Doubt" pitch. It isn't meant to be. We've seen this reality in every organzation to greater or lesser degree, and we want to help.
High Availability is the norm today, but it is complicated and expensive to maintain.
Proxylity is designed to be a reliable and cost-effective way to connect your serverless resources to the network. It's built on the same infrastructure that powers AWS's own services, so you can be confident that it will be available when you need it. And because you only pay for what you use, you may even save money compared to running your own network servers.
Our services are global in scale (resident in multiple AWS regions) and designed from the ground up for high availability and performance. When clients connect via a Proxylity ingress DNS name it resolves via latency-based routing to multiple IPs served via AWS Global Accelerator (GX). Your UDP traffic sent to one of those IPs is directed to the closest available instance of our service.
Of course this means your client will experience the best network performance, but it also provides resiliency in the face of outages (and rolling deployments, though our deployments within regions are also very nearly "zero downtime"). You have the option of configuring delivery to "same region" resources for optimal backend performance as well, or can elect for a single resource to be used for simplicity.
Interested in giving it a spin? Read about Getting Started.