AWS Startups Blog

This post comes as part of the Startups on Air series; where the Startup Evangelist Mackenzie Kosut, goes around to different startups and learns more about who they are, what they do, and how they utilize AWS. 

Founded in 2011 in Israel, Cloudinary is a boot-strapping success story, growing organically without venture capital funding. In 2015, the company expanded internationally, opening its U.S. headquarters in Palo Alto, California.

The key to Cloudinary’s success is its ability to solve a very real problem for today’s developers: how to deal with the challenges resulting from the use of images and videos in modern websites and apps. As the need for images and video grows in importance, developers must figure out how to best manipulate and deliver this media to a variety of screens at the proper resolution for each user, while minimizing page size to ensure a great user experience.

Cloudinary has reinvented the way that media is managed online, enabling developers to optimize sites for end users who expect fast access to high-quality, high-resolution images and videos, regardless of what device they’re using or where they are located. Cloudinary’s comprehensive cloud-based image and video management solution quickly has become a preferred solution used by web and mobile application developers at major companies around the world to streamline media management and deliver an optimal end-user experience.

Cloudinary automates the entire media lifecycle. Cloudinary supports image and video upload; cloud storage; digital asset management; on-the-fly image and video manipulations; and optimized delivery to end users.

In just over five years, Cloudinary has attracted more than 180,000 developers who are managing approximately 10 billion media files. Among Cloudinary’s users are Answers.com, Conde Nast, Gawker, Gizmodo, GrubHub, Indiegogo, Outbrain, Snapdeal, Under Armour, Vogue, and Wired.

Technical Recap:

“From our customer’s perspective, DevOps perspective, and customer success perspective, AWS Athena is a nice addition to our core” -Nadav Soferman, Co-founder and Chief Product Officer, @NadavSoferman

Cloudinary runs their image processing using Amazon EC2 instances with Elastic Load Balancing, while using Amazon S3 for their storage needs. Since re:Invent 2016, Cloudinary has begun using some of Cloudfronts’s newer features such as Lambda@Edge, which allows Cloudinary to run “almost arbitrary code on the edge itself” for requests sent via the Amazon CloudFront CDN. Using Lambda@Edge gives Cloudinary the capability to create varying adaptations of an image in real time without having to forward the requests to centralized servers.

Additionally, Cloudinary has begun to move its databases from Cloudinary’s own EC2 instances to Amazon Aurora, which gives Cloudinary increased scalability, uptime guarantees, and cross-region replication. Auto Scaling in Aurora allows Cloudinary to avoid provisioning excess database storage to handle future growth: “It makes our lives much easier because we have so many objects (more than 13 billion stored).”

Lately, Cloudinary has shifted towards Amazon Athena, which helps them generate sophisticated reports and insight into their customer’s use of images. Through Athena, they can run ad-hoc queries on the data they’ve gathered, and dive into the data more deeply in a variety of ways depending on their specific needs each time. “From our customer’s perspective, DevOps perspective, and customer success perspective, this is a nice addition to our core.”

Cloudinary not only uses AWS Lambda at the CloudFront CDN level via Lambda@Edge, but also for integration purposes elsewhere in Cloudinary’s infrastructure. AWS Lambda allows Cloudinary to send callbacks via HTTP or SNS, get notified of any image that’s being uploaded, and have the ability to react to it in real time. “We have a way of triggering Cloudinary from a Lambda function when the new image or video arrives in your S3 bucket, and you can reuse your own S3 bucket for enterprise purposes.” This allows Cloudinary to give their customers a lot of flexibility and scalability, including the ability to process more than 5,000 new images per second.

“We have varying use across the day given the time of day and location, and AWS makes it very easy and adaptive to our needs. We use Spot Instances when it makes sense, and Auto Scaling across multiple services. AWS allows us to do all this while concentrating on the core product, which has been a huge win.”

Interested in learning more about Cloudinary? Check out their Twitter page.

Whether you are a Startup new to the cloud or an experienced user, you will learn something new at the AWS Summit – San Francisco April 18- 19.

This free event is designed to educate you on the AWS platform and develop the skills to design, deploy, and operate infrastructure and applications. Don’t miss the opening keynote offered exclusively at the AWS Summit—San Francisco featuring Dr. Werner Vogels, Amazon CTO and Vice President and a fireside chat with AWS CEO Andy Jassy.

Startup Loft at the AWS Summit – San Francisco

At the AWS Summit – San Francisco we created an experience designed just for you to help you build and grow your startup.

• AWS Startup Loft –We are bringing the AWS Loft to the AWS Summit – San Francisco. It’s a place where startups can meet, attend educational sessions, and get in-person answers to AWS technical questions.
• Ask a Startup Expert—No appointment is necessary. AWS Startup customers will be onsite to answer technical questions on topics ranging from Serverless to Artificial Intelligence. AWS Solution Architects will also be there to help with any foundational questions.
• Lightning Talks featuring Hot Startups –Join us for lightning talks to learn about cool projects startups such as Branch, CloudCoreo and Metabase are working on.

Continue your learning by attending sessions, workshops, and hands-on activities and adding them to your schedule via our mobile app! Download our app to maximize your AWS Summit experience. Find the talks listed below, build your startup schedule, reference way finding maps, and learn more about our exhibiting partners. You can also provide session feedback so we can continue to improve the Summit program. Search “AWS Summits 2017” in your app store or visit https://crowd.cc/s/summits

Startup Agenda at the AWS Summit – San Francisco

This post comes as part of the Startups on Air series; where the Startup Evangelist Mackenzie Kosut, goes around to different startups and learns more about who they are, what they do, and how they utilize AWS. 

Founders Chemi Katz and Ohad Greenshpan come from an extensive and broad background in security, eCommerce, and machine learning. After detecting a market opportunity and researching it thoroughly, they built a minimum viable product (MVP) and met key design partners to help bring their vision to fruition in 2014. They welcomed extremely positive feedback from the market, and went on to raise $6M in their first round. From there, they grew the Namogoo team and developed their IP, which is now sold to leading companies worldwide.

Namogoo provides a session firewall technology that protects consumer-facing applications and websites against client-side threats that operate on the application layer. These client-side threats include:

• Digital malware – Code that runs through browser extensions. Malicious software is installed on the end user’s device or hacked WiFi network that the user is connected to. Right after a page is served and during the page rendering, digital malware takes control of the session in order to “inject” content and code and leverage various monetization channels. For example, it can inject competitive products into product pages to drive the user to competitors’ websites, or it can inject advertisements (such as distracting popups, banners, and in-text ads) to monetize through views and clicks.

• Code injection – Client-side threats inject code in order to conduct fraud activity. By using code injection, a hacker can manipulate forms on the site to obtain sensitive information and “listen” to the user’s key strokes, sending the information directly from the session to the hacker’s servers. The hacker also can inject fake phishing surveys into a website to request the data directly from the user’s device.

• Bots – Namogoo protects websites and applications from client-side bots that run on the application layer. These bots are a form of automated traffic that use browsers to conduct their activity.

Namogoo’s technology is based on unique, proprietary IP.  It includes strong machine learning, anomaly detection foundations, and reaches extremely high coverage with a zero false-positive rate. Their technology is robust, scalable, and self-learning It works in any environment and language, and it requires no customization or manual involvement. Namogoo provides high-quality analytics and intelligence about any session and device at a SessionID and PageView resolution. This allows for advanced device and threat investigation, along with integration into different analytical tools.

Namogoo currently protects top-tier retailers and eCommerce companies globally across all platforms, brands, and geographies. Namogoo provides a holistic, application-side layer that protects websites and applications against various client-side threats that are not covered today by other solutions.

Technical Recap:

“AWS enables us to focus less on solving problems, but rather on innovation, running faster, providing capabilities, and new technologies”– Ohad Greenshpan, COO/co-founder 

Namogoo uses Amazon EC2 and Auto Scaling infrastructure for their servers, but they plan to switch to AWS Lambda and a server-less architecture soon. They store their data in Amazon S3 before moving it over to Amazon Redshift, their big data warehouse, “We are very, very happy with Redshift – we’ve done some interesting work on Redshift with AWS. Something we’re really proud of is the ability to store data for life, and we do it with relatively minimum space.”

From Amazon Redshift, Namogoo aggregates the data using the MySQL engine in Amazon RDS. This gives Namogoo quick access, which provides “a lot of robustness and speed.” Namogoo’s customer success team uses Amazon QuickSight with the RDS database to track user data. Namogoo plans to further integrate with their customers in the future via Amazon QuickSight, with the goal of sharing more data with customers in the future.

Namogoo also uses Amazon Elasticsearch Service, which allows Namogoo to take advantage of the powerful Elasticsearch APIs without having to undertake the undifferentiated heavy lifting of setting up and managing an Elasticsearch cluster manually.  All of Namogoo’s research, classification, and statistical analysis is done by moving data from Redshift to Amazon Elasticsearch Service, and is moved on either a daily or hourly basis, “Amazon enables us to focus less on solving problems, but rather on innovation, running faster, providing capabilities, and new technologies.”

Interested in learning more about Namogoo and their ways of cyber security? Check out their twitter page!

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.

Cloud-gaming company Parsec, believes that we’re entering a new phase of computing where all of our software and processing are delivered via shared resources in the cloud. They want to eliminate personal hardware and free everyone from the constant upgrade cycles required to keep up with the latest software. Parsec was started in March 2016 when the founders realized that the confluence of ubiquitous access to low-priced, powerful video decoders, plummeting bandwidth costs, and cloud investments by companies like AWS were making it possible to deliver on this vision today.

Parsec is being built to power a magical cloud gaming experience, freeing people from investing and upgrading their gaming hardware. They’ve proven that low-powered, inexpensive devices, like a Raspberry Pi, can become your go-to gaming machine connected to the cloud. The technology behind this experience is a low latency, 60 frames-per-second video streamer and low latency UDP network to make cloud computers feel like native devices.

Technical Recap:

“We rely heavily on AWS internal services such as SQS and Kinesis. Because we don’t have to develop these in-house, we can deploy that much faster.”
-Eric Nygren, Senior Engineer @_nygren

Parsec builds small services that are deployed on Kubernetes clusters and rely on Amazon SQS for communication. Each service consists of a small code base that performs a specific function. For example, one service’s dedicated purpose is to start and stop AWS GPU instances in a given region. To trigger it, users interact with Parsec’s website, which in turn sends messages to launch or terminate instances on the SQS queue, ensuring that nobody else has access to the machines or services themselves.

Users can launch Parsec’s AMI from any of the AWS regions that currently have G2 instances.  “We’re in every region of the world right now because of AWS.” Parsec’s entire monitoring system is powered by an ELK stack on an Elasticsearch cluster on Amazon EC2 instances.

Going forward, Parsec has toyed with the idea of pushing their monitoring to Amazon CloudWatch to take advantage of notifications when latency is peaking in specific AWS regions. But they haven’t decided on any moves yet nor are they too worried about it,“that’s one of the reasons why AWS is the best service for us to use, because of their infrastructure.” Parsec is confident that whatever decision they make, AWS will be there with the right tool and capacity to support their infrastructure needs.

Interested in learning more about Parsec and staying up to date with their latest endeavors in gaming? Follow them on Twitter here.

Guest post by Michael Mendlawy, Senior developer, Crazylister

“What is the best infrastructure for processing massive amounts of requests at unpredictable times?” In this blog post, we describe what led us to ask this question and how AWS Lambda helped us answer it.

Before we dive into the nuts and bolts of the solution, a bit of background:

Here at Crazylister we help online retailers easily expand to new sales channels by removing the technological barriers. One way we tackle this problem is by giving eBay sellers the ability to easily create professional HTML product pages for their eBay listings, without writing a single line of code.

Many eBay sellers use “cross-selling galleries” in the descriptions of their products. Cross-selling galleries promote related products from the same seller, as shown in the following example.

Recently, eBay announced that it will begin phasing out “active content” from product descriptions in June 2017. This includes banning JavaScript from product descriptions, and by extension will break many existing JavaScript-based cross-selling galleries. We used this opportunity to introduce a prominent feature of our product: a JavaScript-free cross-selling gallery, which eBay sellers can add to their listings in a single click.

How does it work?

When an eBay seller comes to our dedicated landing page and enters his eBay credentials, we inject our cross-selling gallery code into each of his product pages. To do that, we use eBay’s API to get all of the seller’s product pages, insert the cross-selling gallery code into the description part of each page, and send it back to eBay.

Sounds simple enough, right? Well… yes and no.

The problem is volume. Some eBay sellers have hundreds of thousands (and some even have millions) of product pages.

Processing this amount of requests is typically handled via one of two ways:

1. Overprovisioning – determining an upper limit for the number of supported concurrent requests and having a large enough instance ready at all times.
2. Automatic scaling – launching Amazon EC2 instances on demand. This can be done using AWS Elastic Beanstalk and Auto Scaling.

The following table summarizes the main issues that arise from these solutions.

As you can see, these solutions pose problems in terms of response time and cost efficiency. The nature of our cross-selling gallery feature means that seller requests come in peaks. Most of the time few (if any) requests are sent. However, when a seller wants to make an update, we have to process massive amounts of requests as fast as possible.

Although overprovisioning gives us the ability to instantly start handling these peaks, we have to pay for a monstrous instance that sleeps most of the time. The benchmark that we used was 100 K product pages. Treating a single product requires about 5 MB RAM. That means that the instance should have about 500 GB RAM to support this amount of product updates at our required speed.

One type of EC2 instance closely matches this load, the r4.16xlarge. As you can see from the AWS Simple Calculator shown in the following screenshot, this amounts to over $3,000 a month!

Now, for startups in an initial stage (pre-Series A funding) that’s too much to pay for a single feature. Needless to say, we couldn’t afford it.

Auto Scaling allows us to “pay for what we use,” but launching new instances takes about five minutes, which results in an unacceptable user experience.

So…

Overprovisioning – too expensive

Auto Scaling – too slow

Is there a better solution out there?

Guess what? We found one.

AWS Lambda to the rescue!

We used AWS Lambda in the past for other microservices in our application, and when we considered it as a solution to our problem we found that AWS Lambda offers everything we were looking for. It lets us run as many concurrent functions as we want,* and we pay only when a Lambda function is running. Additionally, the price for running a Lambda function is low. Using the same 100 K listing benchmark as before, the monthly cost totals to a mere $13.

AWS Lambda gives us the best of both worlds: unlimited computing power instantly!

* There is a cap to the number of concurrent Lambda functions that you can have running, but asking nicely for an increase from the AWS support team will get you more Lambda functions up and running than you’ll know what to do with.

How did we implement it?

We designed an architecture that allows us to handle as many requests as we want using AWS Lambda. It is divided into three layers of Lambda invocations:

1. Orchestration Lambda function
2. Page Group Lambda function
3. Page Lambda function

Orchestration Lambda

This is the Lambda that starts it all. This Lambda function does several things:

• Initializes all the required data and makes sure that the user input is valid.
• Gets the number of page requests to be made. For the sake of reducing call times, eBay paginates product information requests. This means that in order to receive all of a certain seller’s products, we need to tell eBay how many products we want returned for each call (up to 200 products per page), and eBay responds with the number of pages to be requested.
• Invokes as many concurrent Page Group Lambda functions as needed.

Page Group Lambda function

We bundle several pages together to be treated by a single Lambda function. This Lambda function invokes concurrent Page Lambda functions to treat each page in the page group. We do this to reduce the overhead of Lambda invocation. Yes, we can call thousands of Lambda functions to run in parallel, but the act of invoking thousands of asynchronous functions sequentially takes too long to meet our performance requirements.

Page Lambda function

Each Page Lambda function handles one eBay page that contains a number of the seller’s products. It inserts the cross-selling gallery into each product’s description, and sends the updated product information back to eBay.

This architecture empowers us to process a virtually unlimited amount of product pages simultaneously.

A few things we learned along the way

Invest time in finding the right solution, it might save you time and money later on.

AWS Lambda wasn’t our go-to solution for our feature. We had little experience with it, and our use case is probably not what Lambda functions were made for. But sometimes, if you understand the problem at hand, if you know your available resources, and if you use a little “outside of the box” thinking, you might find the most fitting solutions in places you didn’t think were relevant.

The Serverless Framework is awesome! 

We use the Serverless Framework to write, check, and deploy our AWS Lambda functions with ease. If you want to work with AWS Lambda, you want to use the Serverless Framework. Serverless does all the AWS Lambda configuration for you and lets you deploy changes to your Lambda functions in seconds. But the best thing is that it allows you to invoke your Lambda function locally, making testing as easy as it can be and development much faster.

Make sure your Lambda functions are testable.

Local invoke, for us, is the best feature the Serverless Framework has to offer, so make sure you get the maximum out of it. Invoking locally doesn’t require deploying your Lambda functions, so testing is much faster. Try keeping your Lambda functions testable separately from the rest of the feature flow so that you can use your local Lambda functions. For example, we created test inputs that had the same format as an Invoke call to make sure our local Lambda functions work exactly as their remote versions will.

Use stages for environment separation.

The obvious use case for stages is to separate production code from development code, but you can take it a step further by using different stages for different features. If you have several people working on the same Lambda function, you might want each person to deploy his code to a different stage, thus avoiding deployment override when doing final testing.

Wrap it up!

As a startup, we’re used to doing things lean, but lean doesn’t always have to be about minimum effort to get something done. In our case, the lean way led us to build a far superior solution. We started with a $3,000 sub-par solution. With the help of AWS Lambda, we ended up with an excellent implementation for a fraction of the cost.

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.

Cybereason is an endpoint security company. Instead of treating attacks like isolated incidents, Cybereason looks at them as part of a larger, complex campaign. Cybereason’s three co-founders Lior Div, Yossi Naar, and Yonatan Striem-Amit spent years conducting cyber-offensive operations for the Israeli government and came to the realization that it was people not computers who planned the attacks, and adjusted their strategy to consider how a human mind would react. However, they observed that many security companies weren’t incorporating this “people” perspective into their products. Instead, security technology focused on prevention by building taller and bigger walls. Human ingenuity, which means that attackers eventually figure out how to get around those walls, wasn’t considered. Cybereason is founded on the principle that defending a company from advanced threats requires thinking like the people who are attacking you. By applying an offensive mindset to defense, there’s an opportunity for businesses to detect threats sooner and stop the damage earlier.

Cybereason’s technology collects and cross-correlates data from thousands of endpoints and uses behavioral detection to discover attackers who have already infiltrated a company’s network. This data is automatically queried to find the slightest traces of malicious behavior. It’s used to flag other attacker activity, and leveraged to form a complete attack story. In addition to giving companies greater visibility into what’s happening on their endpoints, this approach turns an adversary’s tactics into a weakness that can expose an entire hacking operation.

Visiting @cybereason demoing their real time cyber attack detection & response service. #StartupsOnAir https://t.co/fj7Dp5nSGQ

— AWS startups (@AWSstartups) February 8, 2017

Interested in learning more about Cybereason? Drop by their website or twitter page!

The social good sector focuses on creating a positive impact on an individual or society. Over the last 10 years, we’ve seen a 20% growth in the nonprofit sector alone. It’s not news that the social good sector is growing rapidly.

Lots of startups in this sector are leveraging innovative technology to solve our greatest challenges, but at the same time, they face a lot of unique challenges. These startups often have to manage a large user base that is not necessarily active at all times, but can spike abruptly based on current affairs. Another challenge is managing a magnitude of international volunteers who come-and-go: these users need access to documents with different confidentiality levels, across multiple networks and devices, from varying locations around the world. Accounts may remain dormant for years before a sudden need arises to access extremely sensitive donor information.

Access, permission models, and data storage are just a few of the problems that companies in the social sector face. It takes time to understand the challenges and even longer to solve them. Some common barriers we hear against cloud adoption are high migration costs, suspicion of true data security, and the lack of technical know-how.

The situation is complicated with no one-size-fits-all solution. That’s why AWS is very excited to see a growing number of social good startups trust and pick us to support their technology. In this post, we dive a little deeper into why Descomplica, a Brazilian EdTech startup, decided to migrate to AWS from another cloud platform.

Descomplica is based in Rio de Janeiro. Their mission is to make learning frictionless and easy. Having realized that high school students are tech-savvy, mobile, and constantly online, Descomplica has built out a thorough education platform that gives students content (like study plans and course materials) and different ways to consume the material (like live-stream content and SMS-based study tools). Descomplica raised more than $14M, attracting venture firms like Social Capital and Valor Capital.

Descomplica’s platform is in high demand. Brazil is the third largest market for social networks after the US and India. The company scaled very quickly and now has a library of 15,000+ videos with over 8 million streams every month. Initially, the significant increase in the number of users and amount of content being loaded caused a lot of unexplained crashes, which made the platform increasingly unreliable from a customer standpoint. Apart from complications with user management systems and billing, the lack of documentation and resources also made it difficult for Descomplica’s team to build sustainably for quick growth.

To fix these problems, Descomplica partnered with AWS to migrate all their services to the AWS platform. The migration took only one month. Descomplica was able to automate the entire deployment of their application using their ongoing integration services, and they acquired a new, reliable system of user permissions and access keys. They chose AWS because of our ease-of-use, deployment, and support. They stayed with us because of our reliability.

As we know, every minute and dollar that a social good startup invests in technology is time and money that’s not put towards their cause. We understand this at AWS and therefore partner very closely with all our customers to architect properly, securely and cost-efficiently. Our goal is to take care of the technological front so startups like Descomplica can focus on their true mission: delivering high-quality education to students who can’t afford top educational institutions. And that is why social good startups are moving to AWS.

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.

Michael Barrett, CEO and co-founder of Stealth Security, joined PayPal in 2006 as its first Chief Information Security Officer where he built an award-winning security organization that defended the company’s website and digital infrastructure against cyberattacks and threats. By 2013 he noticed a consistent pattern; He wanted to buy security products, but couldn’t because they simply didn’t exist on the market. At the same time, he noticed that new more sophisticated types of automated web attacks were evading his traditional security tools and taking more and more of his team’s time and resources. Uncertain what the ideal solution would be, but sensing the market opportunity, he left PayPal and began building a world class founding team from some of the largest payments and security technology firms.

Stealth Security helps companies proactively defend their online businesses and customer data from automated attacks that evade traditional security and anti-fraud tools, such as credential verification, fake account creation, content theft and scraping, and web DDoS. Its next generation WAF is an enterprise-class solution that is purpose-built for protecting websites, mobile apps, and enterprise APIs from all types of automated attacks and unwanted traffic. It is also the industry’s first solution that can dynamically adapt to new attack patterns. Using real-time network traffic analysis, behavioral analytics, real-time threat intelligence, and machine learning, it accurately detects and mitigates attacks with no effect on legitimate user traffic.

Chatting w/ @StealthSecInc who applies netsec techniques w/ ML to prevent web attacks. Join @mkosut and chat! https://t.co/ADd5nzwBeM

— AWS startups (@AWSstartups) January 23, 2017

Technical Recap:

“It’s a natural fit for anyone who is running their infrastructure in AWS.”

-Nikunj Bansal (Principal Engineer), @nikunj_stealth

Stealth Security is a deployed solution that can also run within AWS. In fact, they do all of the building and testing of their solution in AWS. “It’s a natural fit for anyone who is running their infrastructure in AWS,” proclaimed Nikunj Bansal, principal engineer at Stealth Security who referred to the process as a “very seamless integration.”

Let’s talk environment. Stealth Security runs on Amazon EC2. Additionally, they heavily rely on Amazon S3 and Docker for their storage and container needs. Looking ahead, Stealth Security is trying to move toward a solution that is more deeply integrated with AWS, so that anyone who is using services like Amazon CloudFront can use their solution right away without having to make any big configurations. Moving forward, they are preparing to switch to Lambda, as it would increase their compute efficiency and give them virtually infinite scalability.

Michael Barret, CEO and founder of Stealth Security, follows his own triangle model of website security when it comes to protecting a website’s traffic. He has broken down the world of protecting web services into three layers, or types of attacks:

1.     Infrastructure

2.     Syntactic

3.     Semantic

Barret believes that understanding the nature of a web transaction should directly influence the correct course of action. First, you need to understand the intent. Then, you determine if the transaction is automated or not. Next, you figure out the nature of the transaction. Finally, you  decide on the course of action.

Interested in learning more about Stealth Security and their ways of cyber security? You can check out their website here and follow them on Twitter here.

This post is part of the Startups on Air series. Startup Evangelist Mackenzie Kosut visits different startups and learns who they are, what they do, and how they use AWS.

Wellpepper is a platform for digital patient treatment plans that helps patients to follow instructions, empowers them to self-manage their healthcare outside the clinic, and connects them to their healthcare providers if they need additional support.

Co-founders Anne Weiler and Mike Van Snellenberg identified the problem of a lack of continuity of care when Anne’s mom contracted a rare autoimmune disease. After six months in the hospital, she was discharged with no instructions and had to wait over a month for a follow-up visit. This lack of continuity of care at such a crucial time was the impetus for Wellpepper.

Wellpepper solves this problem with actionable care plans (having drawn insights from over 250,000 patient actions), that are built from reusable building blocks. Patient instructions are broken down into simple tasks, educational materials, and custom video, which enable patients to record their experiences. Healthcare organizations can track patient results in real-time against their own best practices and protocols.

With @Wellpepper who's improving patient engagement. Join us and talk about healthcare! #PatientEngagement https://t.co/nAkjhMofSo

— AWS startups (@AWSstartups) January 20, 2017

Technical Recap:

“One of the nice things about using AWS in a HIPAA model is that it’s a shared responsibility model.”

-Mike Van Snellenberg (CTO & Co-Founder)

Wellpepper wraps all of their services within a virtual private cloud (VPC), and use many of the AWS services that are HIPAA-eligible, such as EC2, S3, and EBS. They leverage an ELB elastic load balancer, which handles SSL termination for public traffic. Their app tier, which is written in Node.js, serves dynamic content and runs APIs and application services. Their static web tier houses their content and portals. As far as deployments go, Wellpepper is in the midst of migrating to AWS CodeDeploy  and AWS CloudFormation.

“One of the nice things about using AWS in a HIPAA model is, that it’s a shared responsibility model”, exclaimed Mike, who uses it over un-encrypted files in the back-end and manually encrypted files in the static web tier. He went on to explain how easy it is replicate from shared tendency over to dedicated tendency (minus their web tier).

Wellpepper recently underwent a successful HIPAA audit and shared some of the steps they take to secure their environment; In terms of a shared security model, AWS manages from the hypervisor down to the physical facility, and it is on us to build security into our application. Wellpepper utilizes a simple password based authentication and OAUTH.

For those of you who are new to HIPAA compliance, Mike has a few reassuring words: “HIPAA is not as scary as you’d think. It’s just a lot of general, good security practices.” That said, he recommends getting comfortable with HIPAA before diving into a serious project.

There are a lot of good services in AWS that you can leverage that make architecting and scaling your infrastructure easy. For example, when you encrypt your EBS volumes, you’ve technically met your encryption requirements for data at rest. If you need services that currently aren’t HIPAA-eligible, you can still run your own compliant instances on EC2 with encrypted EBS.

Interested in learning more about Wellpepper and staying up to date with their latest endeavors? Follow them on Twitter here.

Sunday morning I was looking at a large folder on my laptop containing hundreds of images. Thumbnails are wonderful, but what I really wanted was an easy way to search my folder quickly for photos that contained picture of cliffs.

Starting in OS X Mavericks, you can use the Tags feature to find tagged files in the Finder window. I wanted to know how difficult it would be to have my laptop send photos to Amazon Rekognition, have each photo analyzed using the deep visual learning of Amazon Rekognition , and then apply these identified objects as tags to my files that I could then open in Finder.

This would give me the ability to search in Finder or Spotlight (a MacOS search feature) by using Tag:<term>. Want to find all of your photos of cats? Tag:Cat would instantly return these results to you.

After finding a snippet of code for the writexattrs function online, it was just a matter of passing the image to Amazon Rekognition, then looping the Tag results and writing them to the file. In about 30 minutes I had 50 lines of code and a working prototype.

The code is available here to play with: https://github.com/mkosut/rekognition_osx_tagfile

That worked fine for processing a large folder of images. To improve performance, a team member submitted a pull request which resized the images prior to uploading and runs the process across multiple threads. What I really want is a way to have these images get auto-tagged when they are added to the folder.

Enter MacOS Automator. Automator provides an easy interface to watch for folder activity and run an action when a new file is written. It’s similar to how AWS Lambda can run any time a file is modified in Amazon S3.

This workflow waits for new files to write into the “TagMe” folder, and passes them to the rek_osx_tagfile.py script with the filename as a parameter.

Now for the final test:

Success!

The one big realization I had while playing with this hack is that AWS can be used to extend the capabilities of virtually anything. Here I have a simple underpowered laptop, yet I’m able to augment the capabilities of it by tapping into the enormous deep learning of Amazon Rekognition to visually inspect my images. All possible with a minimal amount of code!