Trek10 designs, builds, and supports cutting-edge solutions for our clients using the absolute best tools and AWS platform services.

With multiple production deployments under our belt, our team is one of the foremost experts on building serverless apps and enabling enterprises to migrate to serverless architectures. Massive scalability, heavy automation, and remarkably low operating costs are our hallmarks.

Hear From Our Happy Clients

Trek10's expertise with the Serverless Framework enabled us to focus on the specifics of our application’s functionality and not have to worry about endless infrastructure configuration. Pay only for what you use, let AWS handle the scaling and resiliency, and don’t look back.

Trek10 is more than a partner, they have become part of our team and success. We committed to an internal deadline, and these guys worked all hours with my team to make it happen. Dedication, talent and teamwork! I am blessed to be working with these guys.

Given the many S3 breaches over the past year and some inaccurate information I have seen across various news outlets about the default security of S3, I thought it would be beneficial to demystify some of the complexities of S3 permissions.

AWS Lambda makes it easy for developers to write and deploy code at almost limitless scale. What has been hard is debugging that code. Live debugging has been a pipe dream, and offline tools work most of the time but not for everything. We managed to change that with AWS Lambda Debugger.

Until recently, running a multi-region API Gateway was impossible to do. Well, impossible without servers. This time is over. With the new launch of Regional API Endpoints for API Gateway, the nightmare is over. You can now do Active/Active or Active/Passive failover with ease.

At Trek10, one of the great things about our CloudOps offering is that we often have to solve problems on AWS for ourselves and then use our learning to implement the same solution for our customers. In this case, it was a security challenge. How do we balance the principle of least privilege with a reasonable level of productivity in a wide-ranging set of AWS accounts?

Josh von Schaumburg, Customer Solutions Lead and Senior Solutions Architect at Trek10, recently spent some time with the team at LinkedIn Learning recording a new course, Amazon Web Services - Disaster Recovery.

We founded Trek10 three and a half years ago with a mission to transform our clients’ IT infrastructure by leveraging the very best and latest in cloud technologies. Since then, we’ve been racing at full speed to build a company that provides world-class engineering expertise and support for high-performance environments on Amazon Web Services.

In 2015, TechPoint launched the Tech 25 Awards, a prestigious selection of twenty-five individuals who are critical and exceptional performers helping to grow our community’s tech and tech-enabled companies, but who — not being the CEO or other C-suite executives — don’t get celebrated publicly as often as they deserve.

In case you’ve missed it, AWSume is a cross-platform AWS command-line tool that makes working with the AWS CLI under different profiles or roles super easy. You no longer have to manually set environment variables, or pass the --profile to the end of your AWS CLI calls.

At Trek10, we always try to consider the need for automation and repeatability with everything that we do. That’s why we focus on using tools like CloudFormation, Serverless, and CI, as well as building other tools.

Trek10, Inc, an AWS Partner Network (APN) Advanced Consulting Partner with the DevOps and IOT Competencies, today announced support for AWS Greengrass. AWS Greengrass is a new service from Amazon Web Services (AWS) that seamlessly extends AWS to devices so they can act locally on the data they generate, while still using the cloud for management, analytics, and durable storage.

Way back in March of 2011, AWS announced the release of [Dedicated Instances](https://aws.amazon.com/blogs/aws/amazon-ec2-dedicated-instances/), which allows organizations to launch EC2 instances on dedicated infrastructure. Typically, when an EC2 instance is launched in a VPC, the virtualized infrastructure is built from a pool of shared resources (e.g., CPU units) that is in use by all customers within a given [Availability Zone](https://aws.amazon.com/about-aws/global-infrastructure/).

There are multiple AWS services that are tailor-made for data ingestion, and it turns out that all of them can be the most cost-effective and well-suited in the right situation. We'll try to break down the story for you here.

We have several projects that use DynamoDB heavily. And, while DynamoDB works great, you can hit throttle limits if you are trying to tightly match your provisioned capacity to your actual demand. What about scaling up during the day and down during the night to meet your need? To do this, you would essentially need DynamoDB Auto Scaling.

Today we were looking for a quick way to replace scheduled jobs in Jenkins with GitLab CI. Unfortunately GitLab CI does not support scheduled runs. Being the lambda lovers we are, we figured a quick scheduled lambda function could fix this.

For all of our customers, any downtime for an IPsec tunnel results in significant business impact. This is why we built a Lambda function in Python that leverages the VNS3 API to check all IPsec tunnels for any outages and then posts a custom Datadog metric to notify our 24/7 CloudOps team of any IPsec tunnel issues.

One of the most compelling solutions that is enabled by assembling Lambda with other AWS Platform services is IoT. At Trek10 we are leading the way in building massively scalable IoT back-ends with AWS Serverless.

You may have seen the announcement recently about what we at Trek10 consider to be the biggest update to CloudFormation since CloudFormation itself. AWS CloudFormation Update – YAML, Cross-Stack References, Simplified Substitution.

There are many compelling reasons to consider a Serverless/Lambda-based architecture for your next project: scalability, fault-tolerance, low maintenance cost, high flexibility. But one of the most often-cited is cost.

When you hear “Serverless” I know what you’re thinking… oh boy, another buzzword! I get it. And it’s a pretty confusing one, on two levels. There are still servers! We're just talking about a new abstractoin above the servers, but of course the servers are still hiding down in the stack.

Here at Trek10, we work with many clients, and thus work with multiple AWS accounts on a regular (daily) basis. We needed a way to make managing all our different accounts easier. We create a standard Trek10 administrator role in our clients' accounts that we can assume. For security we require that the role assumer have multifactor authentication enabled.

As a follow up to our post HTTPS Everywhere, today we'll discuss some history behind the SSL certificate and why they seem to cost so much money. We will also dive into the current landscape of SSL certificates and how you can obtain free Domain Validation certs through AWS Certificate Manager and Let’s Encrypt.

CloudWatch Event rules can be scheduled at minimum intervals of 5 minutes. At Trek10, we saw the need for a smaller interval, namely 1 minute. This need arose specifically in the context of handling Auto Scaling within ECS.

Like any good engineering-driven culture, at Trek10 we constantly evaluate new technologies, tinkering with them to figure out how they might fit into our workflows and processes. Want to know what the coolest new framework we have been playing with recently has been? Serverless.

In Part 1, we reviewed a use case for roles in which console users would be required to assume a role for access to the production environment; we have implemented this for some of our more security conscious customers for the benefits we mentioned in Part 1. In Part 2, we will review cross-account roles and some of the different use cases.

New technology appears and old job functions become obsolete. The practitioners move on to retrain on higher-value tasks and in the end the whole system is more productive. It happened when cars replaced blacksmiths, when the computer replaced armies of human calculators, and it is happening now as cloud services replace low-level hardware babysitting on a large scale.

The bytes that make up the page you are reading right now were delivered by a set of servers close to you. They were not generated by a server running WordPress or Joomla. In fact, the entire Trek10 website has no traditional server backend at all.

Amazon EC2 has over 40 different instance types and keeping track of them all can feel a little daunting. To simplify it, pay attention to something called an “instance family”. This is the prefix before the period in the instance name, for example the m3.large instance is in the family “m3”.

About Trek10

Born in the cloud and 100% focused on AWS infrastructure, Trek10 specializes in leveraging the absolute best tools and AWS platform services to design, build, and support cutting edge solutions for our clients.

Quick Contact

Please call (888) 736-2446 (we are available 24/7) or write us at info@trek10.com.