Building a Serverless Web App with AWS

Going Serverless with AWS

The first lesson of going serverless with AWS is that you’re not truly going serverless in the literal sense. You’re resigning from the overhead and responsibility of provisioning, maintaining and administering servers and handing the responsibility for the AWS. It almost sounds too good to be true, right? 

How Can I Move to a Serverless Architecture?

AWS offers a robust collection of products that can be used to replace the functions that servers are currently carrying out in your applications. A handful of these services will be detailed in this blog but there are plenty more to explore. ParkMyCloud provides a convenient list of services categorized by use case.

So what exactly is AWS Serverless? Using AWS Serverless means to build a serverless application using AWS’s fully-fledged army of services. This concept can seem a bit abstract at first. To provide a tangible example, let’s say that you’re thinking about building a serverless web application. The architecture below provides an example of how this can be accomplished using AWS services. AWS provides a good tutorial here that serves as a guide to creating your first AWS Serverless web application with this architecture.



AWS Serverless Services

The components shown in the example above are described in more detail below. Keep in mind that this architecture is only one example of how AWS services can be combined to build a serverless application.

Simple Storage Service(S3)

S3 provides a place to store data hosted by AWS. To get started, create a bucket which is a structure that serves as a container for related resources. Then upload your data to the bucket and choose a region for Amazon to store your data in. You can conveniently choose a region located near your end-users to reduce latency, if applicable. 

Amazon Cognito

Amazon Cognito handles the user registration process and uses the user pool paradigm to manage user data and workflow. A user pool is a user directory that contains all user information. Amazon Cognito handles all processes related to users, including the implementation of a registration flow, sending registration emails, provisioning JWTs and more. Add two-factor authentication or SAML with the click of a button. These processes are fully customizable in the AWS Cognito interface. 

Amazon API Gateway

Amazon API Gateway allows you to quickly create and publish APIs. API management and maintenance become simple since AWS takes care of most of the dirty work. APIs created with AWS Gateway can effortlessly process hundreds of thousands of concurrent API calls providing excellent reliability and capacity. 

AWS Lambda

AWS Lambda allows you to write code that lives on servers managed by AWS. Lambda functions can be automatically triggered by other AWS services or can be called from a web or mobile app. For example, you could create an API using Amazon API Gateway which then triggers a Lambda function to execute a post action on a database. The use cases for AWS Lambda are endless and extend far beyond the scope of the web application architecture outlined above. Check out the Youtube playlist found here to see how big companies are using AWS Lambda.

Simplifying Development with AWS SAM

While AWS provides great interfaces for the implementation of each of their services, it’s much more convenient to be able to set services up and running from the command line. AWS SAM makes this possible. Define your serverless application by using a template that specifies all functions, API’s permissions, configurations, and events. Then use the AWS SAM CLI to package and deploy your application. The CLI also allows you to deploy and debug Lambda functions locally rather than having to use the AWS web interface for manipulation.


Is Going Serverless Worth It?

Quick! Let’s start transitioning all of our web applications to be serverless. Not so fast. Developing serverless applications will require shifts in development flow and time invested in gaining deeper understandings of AWS services. It may be overwhelming to take on the development of an entire serverless application at once. One of the positives of using AWS services is that they can be implemented independently. Transitioning just one API or implementing Amazon Cognitio could be a great first step to exploring what AWS Serverless has to offer.

Almost all AWS services use an elastic cost model meaning that you only pay for what you use,  similar to how you might pay for your water or electric utilities at home. Services scale in size to account for varying resource utilization over time. This model could prove to be very beneficial for applications or jobs that only use resources a few times a month. Rather than paying a monthly fee for a server, you pay for what you use, when you use it. Read more about the AWS service pricing model here.

The Bottom Line

The opportunities that AWS Serverless provides are endless and may alleviate a lot of the overhead that can result from provisioning, managing and maintaining servers. Since every application is different, it comes down to whether the elastic pricing and time saved by letting go of server management can be beneficial in your situation. 

How To Build a More Secure Web App

Securing Your Web App

At Woodridge Software, security is something that we take very seriously. As technology continues to rapidly evolve, it seems like hackers’ methods of attacking modern software are evolving at an even faster pace. Unfortunately, the average software developer has little to no understanding of the miscellaneous attacks that are used by hackers, nor do they completely understand how to help prevent them. For my latest tech seminar, I decided to review our current methods of securing web apps, as well as areas where we can continue to improve.

The Most Common Attacks on Web Apps

The web has become the largest source of information and it houses the interfaces to an unimaginable amount of data. Due to its ease of access, it has become one of the leading mechanisms for modern cyber attacks.

SQL Injection

via @

Nearly every business has some sort of web application. Whether it be on a private intranet or available to the public, it is important that all of the software developers involved in the making of a web app are security-aware. Among the most common attacks are cross-site scripting (XSS), cross-site request forgeries (CSRF), and SQL injection (SQLI). In order best to understand how to prevent these attacks, it’s important to understand how they can occur. The best way to do that is to simply do some research and write up small examples that illustrate the attacks. They don’t have to be cutting-edge examples – just enough to get the point across. From there, the example should guide you on how to prevent these attacks. Most modern web frameworks have tools built-in for mitigating such attacks, and understanding how these attacks occur will help you to understand how these tools are implemented in order to properly use them.

Cryptography Vulnerabilities

Every developer needs a basic understanding of cryptography.

Cryptography security


Specifically, the differences between asymmetric and symmetric cryptography, a high-level understanding of cryptographically secure random number generators, cryptographic hashes, digital signatures, and message authentication codes. Any modern web application will most likely have some form of encryption (typically, communication over HTTPS, password identifiers stored via cryptographic hash, and sensitive information stored via encryption with some form of integrity check such as using an HMAC). It’s also considered a best practice to implement at-rest encryption on both your physical and cloud resources. Improper usage of cryptography (or no usage) is a sure way of putting your data at risk.

Sessions and Tokens

Whether you’re using cookies for your web app session, or a JSON Web Token (JWT) for a mobile API, keeping these secure is a top priority. All cookies that store a session identifier should have the secure flag set (so they can only be sent over HTTPS) and the HttpOnly flag set so that the client-side JavaScript code cannot access it. JWTs should always implement a blacklist using something like Redis, and the JWT’s should have all the necessary claims set such as nbf (not before) and exp (expiration). Ideally, JWT’s should have a short lifetime, maybe even only one request.


This, of course, is not a comprehensive list and is merely an overview of a few important things to consider when building your next web app. Other things worth mentioning are rate-limiting requests (especially on login and registration), utilizing a Content Security Policy (CSP), ensuring your web application server is configured properly, security logs, etc. At Woodridge, we are no strangers to securing web apps. In fact, we can even help you take your existing applications and get them up to par to pass your next penetration test, which you should be performing at least once a year!

Lorenzo Gallegos is a senior software developer at Woodridge Software, a custom software development firm located near Denver, Colorado. Woodridge specializes in Web, Android, and iOS development and works with a variety of clients ranging from startups to Fortune 500 companies.

Browser Compatibility

Maintaining code and appearance for your web app across multiple browsers is not always trivial. Different browsers may only implement certain features and sometimes different browsers will implement the same feature differently. You want to support as many users as possible, but doing so can increase development costs. So how do you choose which browsers you need to support?

Costs and Benefits of Supporting Multiple Browsers

If you choose to support multiple browsers, you may encounter bugs that appear in one browser which are absent in all others. There may be differences in how the developer or designer needs to apply a design to the different browsers. This leads to additional development and maintenance time, which has a corresponding cost. In addition, if your web application has hundreds or thousands of users, not supporting an important browser can increase the number of support emails and calls.

If you have a web app for use by a small number of employees, you might only need to support the latest version of a single browser. This can lower development and maintenance costs. On the other hand, if you’re running an online store and rely upon a large number of sales, making sure your website supports most browsers can bring in more customers. You can choose to not do so and make suggestions, such as “This website is optimized for Google Chrome”, but there’s no guarantee the user will switch from their preferred browser. Even if they do switch, having to do so is inconvenient. So, if you don’t have a small enough group of users to justify supporting a single browser, you need to consider which browsers are worth the additional cost.

Google Analytics

If your web-app is already out in the wild and you use Google Analytics, you can view the browser breakdown for your current users. For our website, it looks like Chrome, Safari, and Firefox are the big three, with IE/Edge also seeing users.


Using tools like Google Analytics provides you with real data that is specific to your user base. With these types of tools, you can quickly get an idea of which browsers you need to support for your users.

Browser Statistics

If you don’t have information through a tool like Google Analytics, a good approach is to target the browsers that are currently the most commonly used. There are a few places you can look for this information, such as Stat Counter and W3Counter. It’s worth the time to examine a few different sites for this information – they all have different sources for their data. The provided percentages may also represent different data. For example, the percentage of users using a specific browser vs. the number of webpages viewed by a particular browser.

For January 2017, Stat Counter shows:


And W3Counter shows:


According to both tests, Chrome and Safari are the important browsers to support. But Stat Counter shows UC Browser third (a browser which, before today, I have not heard of), whereas W3Counter doesn’t show it at all. So, it’s important to compare multiple resources to get an accurate picture of the most common browsers. You can start by supporting the two or three most common browsers and increase support for others over time.

Technological Challenges

On the development side, browsers vary in support for different standards and features. This may result in having to use multiple code and style implementations for different browsers. Supporting older versions of browsers can prevent developers from using newer versions of ECMAScript (used for controlling interactive behavior on a webpage – information on support for the newest version can be found here). There are also new CSS standards and features for designers which may only be usable on newer browsers, such as FlexBox. So, supporting older versions of browsers limits the newer features available to your development team. These newer features may speed up development time, and the absence of some of these features can make certain tasks impossible or finicky for a particular browser. It’s important to have a discussion with your development team about which features of your web app are possible with the browsers you want to support.


There’s a lot to consider when choosing which browsers to support – costs, user base, and technology constraints. Typically, we find it easy to maintain Chrome, Firefox, and Safari (and for some of our customers, we also make sure our code is compatible with older versions of Internet Explorer if their users require it). When choosing which browsers your website or web app will support, it is important to make your decision based upon the best information you have available.

Implementing High Scalability With AWS

Over the past few years, as AWS has become the defacto standard for Woodridge Software’s back end systems, we have deployed dozens of mobile applications. Most applications are mission-critical to our customers, however, the total number of users varies widely. Some of our apps have maybe 10 or so users, others have 100,000+ per day. In this blog, we’ll discuss some of the similarities in the deployments of small and large scale applications and the strategies we use to help scale to our larger implementations.

Goals for Implementing Large Scale Mobile and Web Apps

Database Scalability

Database scalability is the ability to consistently handle the growth of data that an application will house during its lifetime. You can host any relational database on Amazon such as mySQL or PostGres or use noSQL databases such as Mongo. Amazon also has its own versions of both, Aurora is its relational database and DynamoDB is its version of noSQL. AWS has implemented autoscaling services for most relational databases using service they call RDS(Relational Database Service) these help you scale your database, however, we have found that using Aurora often is the easiest to implement. The same is true for DynamoDB where AWS guarantees throughput and single-digit millisecond latency. The choice of using a noSQL or SQL database is of course chosen based on the data being stored for the mobile app.

Minimize System Bottlenecks

System bottlenecks occur when several resources all have to rely on one resource. If that one resource becomes overwhelmed with requests then it can cause a severe decrease in system performance or even a loss of availability.

Fault Tolerance and Availability

Fault-tolerance allows a system to keep operating at normal (or close to normal) behavior in the case of a failure. Hardware failure, power loss, and physical damage caused by natural disasters are some of the most common non-software reasons for system failure. In order for a system to remain fault-tolerant, it must be able to continue functioning with a complete loss of a resource.

Ease of Maintenance

Ease of maintenance is often lost when providing a highly-scalable and reliable system due to an increase in number machines, resources that require specific attention, a more complicated codebase, and possibly having to build and maintain dedicated server farms.


Cost is often hard to balance when trying to provide a reliable web system because it is difficult to predict how many resources are needed, and you often end up paying for far more than is actually ideal.


  1. Single machine dedicated to the entire system


    • Cost


    • The entire system is a system bottleneck and single point of failure
    • System maintenance can cause a temporary loss of availability
    • Back-ups kept on this machine are useless if there is a hardware failure that cannot be recovered from
    • Backups stored on separate machines must be kept safe in order to guarantee no loss of data (and should preferably be kept in a separate location to mitigate the risk of physical damage and complete loss of data)

    Recommended Usage

    • Small-scale applications that can afford to experience system downtime
  2. Machines dedicated to single tasks (application server, database server, etc)


    • Database-only operations won’t impact application-only operations (and vice versa)


    • Each machine now becomes a bottleneck, and loss of one machine could mean a complete loss of availability
    • If all machines are in one location, a power outage or physical damage can lead to a complete loss of availability or even a complete loss of the system
    • Maintenance to a single machine could lead to a loss of availability

    Recommended Usage

    • Small to medium-scale applications that utilize database-only or application-only operations that can afford occasional system downtime.

  3. Groups of machines dedicated to single tasks


    • Database-only operations won’t impact application-only operations (and vice versa)


    • Harder to maintain and higher cost
    • If the machines are in the same location then there is still a possibility of a loss of availability during a natural disaster or power loss. A natural disaster could also cause a loss of the entire system. This is mitigated by having servers located in multiple data centers in the US and/or globally
    • If database sharding is performed (split the database into unrelated chunks that live on different machines), backups become harder to maintain, and deciding how to divide the database properly is more challenging. Also, there needs to be backup machines in place just in case one machine fails. Adding new machines as the data grows is more cumbersome to implement.
    • Possible increase in the codebase complexity
    • While the drawbacks exist this method is necessary for high availability/high scalability deployments. Fortunately, there are systems and processes in place to assist with managing this method

    Recommended Usage

    • Large-scale systems that require high-availability and maximum fault-tolerance

Best Practices

Best practices for large-scale cloud applications utilize many AWS (Amazon Web Services), Google, and Apple utilities to provide the ideal web system.

  • Amazon EC2 – Resizable machines most commonly used for web systems and applications that can be placed into multiple availability zones to guarantee high-availability and fault-tolerance even in the extreme case of an entire Amazon availability zone going down.
  • Amazon Elastic Load Balancer – Automatically distributes network traffic to healthy/available EC2 instances. This service provides automatic scaling to accommodate the amount of network traffic and prevent system bottlenecks.
  • Amazon Auto Scaling – Can be used to automatically increase/decrease the amount of EC2 servers in the system to prevent system bottlenecks and maintain high availability and fault-tolerance. This also allows ease of maintenance because single machines can be added, removed, or upgraded without any loss of availability.
  • Amazon S3 – File storage that includes automatic scaling and automatic backups with replicated data across multiple availability zones to ensure fault-tolerance and high-availability.
  • Amazon Aurora – A high-performance database engine that provides automatic scaling and backups with replicated data across multiple availability zones to guarantee fault-tolerance and high availability. This is a great choice if your mobile app is best suited to a relational database
  • DynamoDB – However, if a noSQL backend is a better option, Amazon’s version called DynamoDB is a great choice. With single digit latency, it’s a good option for mobile, gaming, and IoT applications.
  • Google and Apple – Mobile applications are distributed directly through Google and Apple to provide high-availability and ease of distributing the application to millions of users.

Utilizing these services and utilities also has other benefits including additional security mechanisms and no need to maintain physical machines. Amazon, Apple, and Google’s facilities are all safe and secure with top of the line disaster-recovery mechanisms in place including physical security, power backups, etc. The automatic scaling provided by Amazon also ensures that the system only ever includes necessary resources, which keeps costs to a minimum.

Closing Remarks

This blog is just a high-level overview of the systems we put in place, but hopefully, it takes some of the mystery out of what Amazon is delivering. Those of us in the software development industry know well how Amazon is helping make our lives easier. Many of these services we used to have to set up manually, with countless cron jobs and monitoring. In the custom software world we work in, this used to mean more cost for our customers and lower reliability. By leveraging these services we can reduce our costs and keep our mobile apps humming along. Now if only Amazon had a way to update mobile code for each new iOS & Android release, that would be something… Then again we don’t want our business to be too easy.


E-Commerce Overview

In this slideshow, Zack provides an overview of e-commerce, covering online transactions flows, payment gateways, merchant accounts, e-commerce platforms, and PCI compliance.

Slide Summary

  1. E-commerce Overview, Zack Jones . July 14, 2015
  2. Topics
    • Online transaction flow
    • Payment Gateway
    • Merchant Accounts
    • E-commerce Platforms
    • PCI compliance
  3. Online transaction flow
    • Cart/Store
    • Checkout
    • Payment Gateway
    • Merchant Bank’s
    • Processor
    • Card Issuing Bank
    • Merchant Account
    • CC Interchange
  4. Payment gateways
    • Service that processes credit card transactions (Shopify Payments, PayPal,, Stripe, etc.)
    • Typically charge ~ 2.9% + $0.30 per transaction
    • Rates depend on volume of sales, and what kind of product is being sold
  5. Merchant accounts
    • Temporary bank account that holds the money from credit card transactions until it is transferred to you business bank account
    • The money is generally held in the merchant account for 2-7 days
  6. Dedicated vs. Aggregate merchant accounts

    Dedicated (, PayLeap)

    • More in depth credit check and underwriting process
    • Can negotiate better rates
    • More control over when money gets transferred out of the account

    Aggregate (Stripe, PayPal)

    • Application process is much simpler and faster
    • Less control over the account
    • Can’t negotiate the rates
  7. E-commerce platforms
    • Broad spectrum of options available
      • Hosted store
      • Hosted cart & payment
      • Hosted payment
      • Merchant store
    • Some popular platforms include: Shopify, Magento, Bigcommerce, Squarespace
  8. PCI Data Security Standard (PCI-DSS)
    • A standard created by the PCI to prevent the compromise of cardholder information and credit card fraud.
    • 12 major sections
    • 226 specific requirements
  9. PCI-DSS
    1. Install and maintain a firewall configuration to protect cardholder data
    2. Do not use vendor-supplied defaults for system passwords and other security parameters
    3. Protect stored cardholder data
    4. Encrypt transmission of cardholder data across open, public networks
    5. Use and regularly update anti-virus software
    6. Develop and maintain secure systems and applications
    7. Restrict access to cardholder data by business need-to-know
    8. Assign a unique ID to each person with computer access
    9. Restrict physical access to cardholder data
    10. Track and monitor all access to network resources and cardholder data
    11. Regularly test security systems and processes
    12. Maintain a policy that addresses information security


  10. PCI-DSS validation
    1. > 6 million X X
    2. 1-6 million X X
    3. 20,000 – 1 million Maybe X
    4. < 20,000 Maybe X

    Level 1 & 2 merchants must have an annual audit by a certified Qualified Security Assessor (QSA)

    They must also have their network scanned quarterly by an Approved Scanning Vendor (ASV)

    Level 3 & 4 merchants are eligible to use the Self-Assessment Questionnaire (SAQ)


  11. PCI-DSS SAQ validation
    All cardholder data functions outsourced A
    Cardholder functions performed locally, but no cardholder data stored C
    Cardholder functions performed locally, and cardholder data stored D

    To qualify for SAQ-A no sensitive information can ever touch the website!

    Sensitive information includes the card number, expiration date, and card code.

    If the site does handle cardholder information a quarterly network audit is required.

  12. Sources & Useful Links

    Payment Gateways


    PCI Compliance

    • (This series is a solid overview)

    E-Commerce Platforms