Forem: Francois LAGIER

How are people keeping track of their #AWS Reserved Instances purchases?

Francois LAGIER — Mon, 24 Jun 2019 22:19:36 +0000

I'm curious to learn how folks keep track of their RIs.

What number do you keep an eye on and how?
- RI Utilizations? RI Coverage?
Do you use any scripts or tools to do so?

Looking forward to learning new tricks

Chicago AWS Summit: Things to do, eat and see. Recommendations from a local south-sider.

Francois LAGIER — Wed, 22 May 2019 18:03:28 +0000

Originally published by co-founder Tony Chan on cloudforecast.io/blog

Heading to the AWS Summit in Chicago on May 30th and need recommendations on things to eat, see or drink near McCormick Place?

For those who have been to McCormmick place, you already know the area is lacking quality restaurant, bars or things to do. The area surrounding McCormick place, South Loop and Motor Row, is still “up and coming”, but it’s still 3-5 years out from having more viable options for people attending a conference. Do a quick google map search for “restaurants” around the area and you’ll see what I mean.

I have listed a few of my favorite places near McCormick Place, but I recommend venturing off to the surrounding neighborhoods for more options and a unique experience (Bridgeport, Pilsen, Chinatown). I grew up in Bridgeport, was a tour guide in Chinatown in college and still reside in the area. I hope my local knowledge of the “South-side” will make you feel a bit better venturing into uncharted territory for many. This is definitely not a complete list, but it's a starting point of a select few places.

If you need more recommendations or have other places to add, feel free to reach out to me directly, tony@cloudforecaset.io. Happy to help in any way!

Walking distance, <15-20 minute walk. (South Loop and Motor Row).

Places to eat

Pizannos - Sit down restaurant. One of the best restaurants for Chicago style thin crust. They also have deep dish if that is what you are looking for. Crust is buttery and corn meal based similar to Lou’s and Pequods. Google Maps Link
14 Parish - Sit down restaurant. Carribean food within <5 min walk of McCormick Place. This will be a good option if you need a spot for a business meeting. Google Maps Link
Opart Thai - Sit down restaurant. Considered one of the best Thai restaurants in Chicago and a neighborhood staple. Another good option if you need a spot for a business meeting. Google Maps Link
Chef Lucianos - Quick bite. Hole in the wall restaurant for quick take out or lunch. A lot of their dishes are Indian inspired and unique. I recommend the fried chicken or Chicken curry. Google Maps link

Places for a drink

Weather Mark Tavern - Nautical themed dive bar. Great drink menu and daily food specials. Google Maps Link
Reggies Chicago - Another dive bar and neighborhood staple. Live music everyday with a rooftop patio. Very grungy vibe, but a very fun bar.Google Maps Link
Fat Pour: Relatively new place for the area. Wide beer selection but gets pretty busy during conferences due to lack of options around the area. Google Maps Link
Other options: Vu Rooftop bar, Woven and Bound Bar, First Draft’ Further South Loop Options: First Draft, Kaseys Tavern

Coffee shops to work out of

Spoke and Bird
TeaPotBrew Bakery

<15 min rideshare distance (Chinatown, Bridgeport and Pilsen)

Side note: You can get to Chinatown via the 21 Cermak bus which should take less than 10 minutes. Alternatively, it’s about a 20 minute walk.

Places to eat

Chinatown: Chi Cafe - Sit down restaurant. Hong Kong style chinese food. Great stop for a quick lunch. I recommend the Sizziling Beef in Sake Sauce. Google Maps Link
Chinatown: Yummy Yummy Noodles - Sit down restaurant. Small family owned place that is known for their noodle soups. Google Maps Link
Chinatown: Ming Hin - Sit down restaurant. One of the better places for dim sum. Picture menu and ipads for easy ordering. Google Maps Link
Other options in Chinatown: Dolo, Qing Xiang Yuan Dumplings, Happy Lamb Hot Pot
Bridgeport: Ricobenes - Quick bite. Chicago south side staple. Known for their breaded steak sandwiches, vesuvio chicken sandwiches and pizza. Google Maps Link
Bridgeport: Phil’s Pizza - Sit down restaurant. One of the best places in the city for Chicago tavern style pizza. Opens at 4pm. Google Maps Link
Other options in Bridgeport: Freddies, The Duck Inn, Nana’s.
Pilsen: Carnitas don Pedro - Quick bite. Hole in the wall restaurant service the best Michoacana style carnitas in the city. Pig cooked in it’s own fat, what can go wrong? Cash only. I recommend a mix plate of Carnitas to try out a little bit of everything. Not open for dinner. Google Maps Link
Pilsen: Tortillería y Taquerías Atotonilco or El Milagro for tacos.
Other options in Pilsen: HaiSous, S.K.Y., Monnie Burkes or La Vaca.

Places for a drink

Bridgeport: Marias and Kimski - Fun little dive bar with a wide beer selection and korean/polish food. Great option for a business meeting and drinks. Google Maps Link
Bridgeport: Marz Brewery - One of the best breweries in the city with great food. Their beers are unique and everything here is delicious. It’s off the beaten path, but worth going to if you need to find a place for drinks. Google Maps Link
Pilsen: Moody Tongue - 12 layer Chocolate cake and beers. Enough said. Google Maps Link

Coffee shops to work out of:

Bridgeport: Bridgeport Coffee Google Maps Link
Bridgeport: Red Line Cafe Google Maps Link
Bridgeport: Jackalope Google Maps Link
Pilsen: La Catrina Cafe Google Maps Link
Pilsen: Cafe Jumping Bean Google Maps Link

Interview with GitLab CEO, Sid Sijbrandij - Keys to Developing a Self-Hosted Version of Your App.

Francois LAGIER — Thu, 09 May 2019 18:46:35 +0000

Originally published at cloudforecast.io/blog

We had the opportunity to chat with Sid, the CEO of GitLab, on what it takes to offer a self-hosted version of your software a few weeks ago. GitLab is a single application for the entire software development lifecycle. From project planning and source code management to CI/CD, monitoring, and security.

In addition to a SaaS product, GitLab offers a self-managed/self-hosted version of their app that has been a great business model for them. We’ve been working through the idea of offering a self-hosted version of CloudForecast and knew that Sid would be a great resource to learn from.

TL;DR summary:

Leverage third-party software to deploy faster: Look into third party software such as Replicated to help speed up your deployment process.
Support is important: Keep it simple and include support for all your pricing tiers.
Offer a freemium version of your app: Consider a free version of your software with a few limitations in place. That limitation can be a 30-45 day free trial and flexibility to extend further. This will help you get your foot in the door and create sales opportunities.
Focus your messaging around data security: “Data does not leave your network” is the single most important thing you need to focus on while building a self-hosted version of your software.
Build a product that saves time: Engineers do not want to fiddle with tools; they want to build software. Focusing on an out of the box experience that can get them results in 5 minutes or less is very important.

Here are a few highlights from our conversation. We hope this can help your company if you are considering building a self-hosted version of your app. The full interview video is available after this post.

There are a lot of technical challenges involved with building an self-hosted version of your software. We found a third party company called Replicated, that makes it easy for SaaS and software companies to make the move into selling modern, on-prem software.

What are your thoughts with using software like Replicated?

Faster is better, especially if you are not sure if there is a giant market. It makes a lot of sense to go that route. I know the people from Replicated - they are good and they know their stuff. When we first started packaging GitLab, Replicated was not there yet or we were not aware of them at the time.

There are a few lessons that we ran into while doing it on our own and things you need to consider. First of all, it’s A LOT of work to package up your stuff. We have an entire distribution team that is focused on this. We based our packaging on a technology from Chef called Omnibus. The end user experience is great, the team did a great job, but it is a significant investment. That speaks for using a third party tool like Replicated to speed up your process.

Few things to be aware of in the Enterprise space, not everyone uses Docker and Kubernetes. That might be different for your customers. But, we found that a lot of our customers do not like running them in production. They might have other tools that assume a boring Unix app. Examples: "Oh! I want to provision it as expected user", or "I want to run an agent on the system”. They cannot accept a black box but they want more flexibility. With that being said, I think time is the most important thing you have in a startup which makes going with a solution like Replicated makes sense.

How should we consider pricing if we were to go with a self-hosted version of CloudForecast? What are the lessons you’ve learned while trying to figure out a pricing model for GitLab?

We're frequently bought by companies that don't do a consumption pricing model. They want a predictable amount and they know what they will be charged at the end of the month.

They get a budget for it and they have to put in a dollar number when they request it. Making it variable makes it difficult to purchase. It might not make it difficult though if you can figure out a way to lump it into the existing cloud provider bill. Cloud providers are starting to offer marketplaces that allow you to bill for your software. In that case, your offering of variable pricing can lump right into cloud provider bill.

A boring solution would to have a few tiers with fixed pricing based on their monthly spend with their cloud provider. It’s not ideal, but it makes it a lot easier to purchase because they know exactly what they will be billed using your software.

How do you all handle and price support out for GitLab? Any lessons there with approaches you’ve tried out?

You should never sell without support. You should always include support because you’ll end up with a situation like, "Well, I can't use it I have a problem with it and they say well tough luck you didn't buy support.". The reverse can also be true with ONLY selling support. We did that with GitLab in the beginning. People didn’t have any problems and they cancelled their support contracts. It made sense for them since they were able to use the product with no issues.

To handle both scenarios, we just include support if they want support or not. They will pay the same price for either/or. I am a huge proponent of building it in no matter what. There is one subscription pricing and it includes support. There is a scenario with support with a good, better, best model. Example for us: the best model means that you’ll get better support that is more timely, more extensive and with more hand holding.

What is the sales process like selling into enterprise companies? Who should we be talking? Any tips on ways we can start selling into these companies?

GitLab is an open core company so lots of people that we get to sell into start with our open source offering. This has really helped us get our foot in the door early on and helps speeds up the sales cycle because they are using your product. Typical sales cycle on average for GitLab: Less than 10k is about 60 days. 10k - 100k is about 90 days. 100k and more is about 120 days.

If you don’t want to open source your software, you should consider a free-tier version of CloudForecast. There is a whole big thing called “Shadow IT”, where people don’t like going through the process and want to run something that can help them. They’ll frequently use free tools since so they don’t have to expense it.

However, you still have to consider that they might not be able to use the free SaaS version since they cannot share confidential data or credentials. If you had a on-premise, free version of your software, they can use your tool and still be good stewards of the private data. You become an approved vendor since the data is never leaving the network, which becomes less of a problem.

To follow up on a free version of your product, would you recommend maybe offering a limited version of your software? What are some variants you’ve seen that has worked well?

There can be many variants to a free version of your product. For GitLab, we’re open core, so our free version will always be free and then we charge for additional features on top. With a lot of proprietary software, the limited version might be a fixed “time limit” and you cannot continue after X days. It doesn’t have to be 30 days and it can be a whole year as an extreme example.

With someone who has a problem of spending too much with their cloud provider, their boss has tasked them to solve that problem right away. They have to go through a purchasing process of 30-60 days to get the vendor approved when they need a solution right now. They might not object to a 30-45 day free trial to see how the product can work for them. From what I’ve seen, that seems to be the industry standard and it makes a lot of sense. For GitLab, we’ve settled to offer 30 days and if people ask for an extension, we are happy to oblige and extend their free trial.

What are some messaging and important features to consider that resonates to decision maker looking for an on-prem solution?

The most important thing to highlight with messaging is “Data does not leave your network”. Maybe with CloudForecast, focus on getting your first cost report in less than five minutes should be key. You also want to highlight average percentage someone can save. Highlighting pricing is also very important. We’ve found that the pricing page is the most popular page on any website.

With your experience at Gitlab, what are your customers looking for and considering as an on-prem solution?

GitLab wins because we're a single application for the entire DevOps life cycle. We save them time because they don't have to combine a chain of other applications together and spend a lot of time integrating them all. All this leads to a subpar experience anyways since they are all still separate apps.

You’ll start to understand quickly that people have very limited time. They have this assignment to save cost and they need to get results quickly. People want to make software, not string 50 different DevOps tool to get it. That out-of-the-box experience that can get you results in 5 minutes or less is very important. I’d encourage you to show a video of you downloading and installing your software, them putting in their AWS credentials and the result is getting a super cool cost report. That is insightful. If you can make that video in less than three minutes, that is awesome.

Do you have a rough idea how long it takes from signing up to installing it and having a working GitLab on your servers? Is there any manual processes involved or is it fully automated process that takes less than 10 minutes?

Five minutes including registering the subdomain is what we are shooting for. In previous years I went online and I live streamed myself doing it. I learned a lot from that.

Not a customer and interested in trying us out? Sign up today and get started with a risk-free 30 day free-trial with us: Start 30 Day Free-trial

Please reach out to us if you have any feedback for us or have suggestions on what we should build next. We would love to hear from you: hello@cloudforecast.io

Watch out for Unexpected S3 cost when using Athena.

Francois LAGIER — Mon, 29 Apr 2019 17:39:59 +0000

Originally published at cloudforecast.io/blog

Following up on my last blog post (Using Parquet on Athena to Save Money on AWS), I wanted to share another thought about Athena, specifically how the S3 bucket is being used by Athena to store query results.

On the first use of Athena, AWS will automatically create a new bucket to store the query results (bucket name aws-athena-query-results-<ACCOUNTID>-<REGION>). Athena will store a raw result file (QueryId.csv) and a metadata file (QueryId.csv.metadata).

By storing the data using the QueryId, it allows you to access previous query's result without re-running them (saving you money since you don't need to rescan the data).

However, you are the owner of the bucket and therefore responsible for the storage on this bucket and here is a couple of reasons why it could cost you a LOT of money:

#1 All the queries are being stored! ALL OF THEM!

Athena store every query results in the bucket. Query data will just accumulate forever costing more and more $$$.

#2 Your data may be compressed but the results are not

S3 is storing the results in raw CSV. Your data may be compressed (GZIP, Snappy, ...) but the results will be in raw CSV. As an example, I ran an accidental SELECT * FROM flights.parquet_snappy_data on a 84M dataset using Parquet which resulted on a 977MB file on S3.

How to fix this?

It's actually pretty easy. If (and only if) you don't plan to re-use old query results, make sure to setup Lifecycle on your bucket using a Transition or Expiration actions. For example, you could delete query results after 1 or 7 days. At CloudForecast, we actually don't persist QueryIds since it's not useful to us so we expire the S3 files after 1 day.

Feel free to reach out if you have any questions at francois@cloudforecast.io or by Twitter: @francoislagier. Also, follow our journey @cloudforecast

Using Parquet on Athena to Save Money on AWS

Francois LAGIER — Mon, 15 Apr 2019 17:00:45 +0000

Originally published at cloudforecast.io/blog

To show you how you can optimize your Athena query and save money, we will use the ‘2018 Flight On-Time Performance’ dataset from the Bureau of Transportation Statistics (bts.gov). We will also drop a few interesting facts about US Airports ✈️queried from the dataset while using Athena.

All datasets and queries used in this post can be found in our Github repo.

Let's start with some terminology

Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Pricing is based on the amount of data scanned by each query.

Apache Parquet is a columnar storage format available to any project in the Hadoop ecosystem, regardless of the choice of data processing framework, data model or programming language.

If pricing is based on the amount of data scanned, you should always optimize your dataset to process the least amount of data using one of the following techniques: compressing, partitioning and using a columnar file format. We will demonstrate the benefits of compression and using a columnar format.

Using compressions will reduce the amount of data scanned by Athena, and also reduce your S3 storage. It's a Win-Win for your AWS bill. Supported formats: GZIP, LZO, SNAPPY (Parquet) and ZLIB.

Instead of using a row-level approach, columnar format is storing data by columns. This allows Athena to only query and process the required columns and ignore the rest. If you want to learn more about columnar, check out Wikipedia and/or the "The beauty of column-oriented data" article by Maxim Zaks

Getting familiar with the data

While using the ‘2018 Flight On-Time Performance’ dataset, we will use three different types of files to compare performance with the data processed: CSV, GZip, and Parquet files.

The files downloaded from the Bureau of Transportation Statistics are simple CSV files with 23 columns (such as FlightDate, Airline, Flight #, Origin, Destination, Delay, Cancelled, ...)

Same data, 3 versions:

Raw CSV:
- Description: No compression, just a plain set of CSV files
- Files: 12 ~55MB files (one for each month)
- Total dataset size: ~666MBs
GZip CSV:
- Description: Simple CSV files compressed using GZip to compress them.
- Files: 12 ~10MB Gzipped CSV files (one for each month).
- Total dataset size: ~126MBs
Compressed Parquet:
- Description: We converted to the CSV file to parquet using Spark. The same process could also be done with (AWS Glue)
- Files: 12 ~8MB Parquet file using the default compression (Snappy).
- Total dataset size: ~84MBs

Find the three dataset versions on our Github repo.

Creating the various tables

Since the various formats and/or compressions are different, each CREATE statement needs to indicate to Athena which format/compression it should use.

Raw CSVs

CREATE EXTERNAL TABLE IF NOT EXISTS flights.raw_data (

    year SMALLINT,

    month SMALLINT,

    day_of_month SMALLINT,

    flight_date STRING,

    op_unique_carrier STRING,

    flight_num STRING,

    origin STRING,

    destination STRING,

    crs_dep_time STRING,

    dep_time STRING,

    dep_delay DOUBLE,

    taxi_out DOUBLE,

    wheels_off STRING,

    arr_delay DOUBLE,

    cancelled DOUBLE,

    cancellation_code STRING,

    diverted DOUBLE,

    air_time DOUBLE,

    carrier_delay DOUBLE,

    weather_delay DOUBLE,

    nas_delay DOUBLE,

    security_delay DOUBLE,

    late_aircraft_delay DOUBLE

)

ROW FORMAT DELIMITED

FIELDS TERMINATED BY ','

ESCAPED BY '\"'

LINES TERMINATED BY '\n'

LOCATION 's3://INSERT_BUCKET_NAME/raw'

TBLPROPERTIES (

    'skip.header.line.count'='1',

    'serialization.null.format'=''

);

Gzipped CSVs

Athena automatically detects the gzip format (based on the ".gz" suffix) so we can re-use the query from above. See the full query here.

Parquet Files using Snappy

Using both STORED AS PARQUET and "parquet.compress"="SNAPPY", Athena will be able to process our data flawlessly.

CREATE EXTERNAL TABLE IF NOT EXISTS flights.parquet_snappy_data (

    year SMALLINT,

    month SMALLINT,

    day_of_month SMALLINT,

    flight_date STRING,

    op_unique_carrier STRING,

    flight_num STRING,

    origin STRING,

    destination STRING,

    crs_dep_time STRING,

    dep_time STRING,

    dep_delay DOUBLE,

    taxi_out DOUBLE,

    wheels_off STRING,

    arr_delay DOUBLE,

    cancelled DOUBLE,

    cancellation_code STRING,

    diverted DOUBLE,

    air_time DOUBLE,

    carrier_delay DOUBLE,

    weather_delay DOUBLE,

    nas_delay DOUBLE,

    security_delay DOUBLE,

    late_aircraft_delay DOUBLE

)

STORED AS PARQUET

LOCATION 's3://INSERT_BUCKET_NAME/parquet'

tblproperties ("parquet.compress"="SNAPPY")

Picking a couple of queries to play with

Query #1: Top route in the U.S. in 2018 alongside the number of airlines providing flights for it.

Spoiler Alert: It's Chicago O'Hare International to New York LaGuardia with 6 unique airlines offering the route

SELECT 

    origin, 

    destination, 

    count(*) as total_flights, 

    count(distinct op_unique_carrier) as uniq_airlines

FROM flights.parquet_snappy_data

GROUP BY origin, destination

ORDER BY total_flights DESC

LIMIT 1

Query #2: Best airport to fly out from to avoid any major delay (> 30 minutes)

Spoiler Alert: Honolulu International Airport has less than 4% flight delayed, giving you one more reason to visit Hawaii. Newark Airport had an average of 16.2% flights delayed (>30 minutes).

SELECT

    origin,

    percent_delayed as "% Delayed (> 30)",

    total_flights as "Total Flights"

FROM (

    SELECT

        origin,

        DENSE_RANK() OVER (ORDER BY percent_delayed desc) AS worst_rank,

        DENSE_RANK() OVER (ORDER BY percent_delayed asc) AS top_rank,

        percent_delayed,

        total_flights

    FROM (

        SELECT

            origin,

            sum(CAST (dep_delay > 30 as DOUBLE)) / count() as percent_delayed,

            count() as total_flights

        FROM flights.parquet_snappy_data

        GROUP BY 1

        HAVING COUNT(*) > 10000

    ) as t1

) as t2

WHERE top_rank <= 1

OR worst_rank <= 3

Comparing performances

For this category, I ran each query 10 times and averaged the numbers. We will use the Raw dataset as our baseline.

Query #1
- Raw: 665.71 MB scanned in 2.60 seconds. $0.00333 per query
- GZip: 125.54 MB scanned in 2.08 seconds. $0.00063 per query (-81% savings).
- Parquet: 8.29 MB scanned in 1.26 seconds. $0.000050 per query (-98% savings).
Query #2
- Raw: 665.71 MB scanned in 2.60 seconds. $0.00333 per query.
- GZip: 125.54 MB scanned in 2.08 seconds. $0.00063 per query (-81% savings).
- Parquet: 8.29 MB scanned in 0.81 seconds. $0.000062 per query (-98% savings).

Conclusions

Thanks to Parquet’s columnar format, Athena is only reading the columns that are needed from the query. This reduces the query time by more than 50+% and reduces the query price by 98%.

If you have any questions about Athena, Parquet or CloudForecast, feel free to ping me via email francois@cloudforecast.io or by Twitter: @francoislagier.

How we saved over $1,000 by building CloudForecast.io with Serverless and AWS Lambda.

Francois LAGIER — Wed, 03 Oct 2018 15:58:58 +0000

In a previous blog post, we described our journey to launch CloudForecast
and some of the questions every startup face. In this post, we will answer the question “What’s the right way to build this product with our resources?”

The “$100 Startup” concept

I’ve been obsessed with a book called “$100 Startup” by Chris Guillebeau for over a year now. In his book, Chris advises his readers to get their product out fast while being cost-effective to limit the damage if your idea fails (definitely possible, unfortunately!). We try to apply this advice on every side of our business including our technical decisions.

Our goals/requirements

With the $100 startup concept in mind, we started by listing our requirements that were important to us while building CloudForecast:

Ship it out fast: We were excited to build CloudForecast to help companies save $$$ on AWS. We wanted to put it in front of our clients ASAP to keep our excitement going. Spending time debugging config, deploy process, etc. will not make the end product better. We were looking for an out of the box solution that we can grow with and allowed us to focus on our MVP the right away.
Cost effective: As an early startup, we wanted to avoid fixed costs by building a system that will scale seamlessly based on our client base.

AWS Lambda + Serverless = Easy + Focus + Cost Effective

With our next steps, we brainstormed on how can we achieve our goals and requirements. We discussed managing our own instances, using containers and half a dozen other ideas but we wanted something simple so we decided to use a Serverless solution (or FaaS). While there are few downsides (e.g cold starts, …), we believe going Serverless better suited our use case (zero administration, pay-per-execution with no idle cost and auto-scaling).

For the dev setup and deploy process, we decided to use Serverless Framework with AWS Lambdas for the following reasons:

We can focus on writing our product and let Serverless manage the rest (permission, event management)
Easy to configure and easy to deploy
Serverless supports multiple platforms (GCP, AWS, … ) which could prevent headaches in the future. We picked AWS Lambdas to start with since our clients data will be stored in S3. It was a logical decision in order to reduce the reduce the network cost
Great documentation and community (Github, Gitter, Slack)

Our original requirements were fairly simple: We needed 4 AWS lambda functions each on their own cron job, and each lambda would need to talk to various AWS products (RDS, DynamoDb, SQS et al.). All that with an easy way to manage multiple environments (dev vs prod) easily with an easy/effective way to manage resource permissions.

Here is how we do it:

We used 4 functions with external JSON files variables based on the environment:

Used the iamRoleStatements to configure all the permissions

With these two code snippets, we were able to set up most of our architecture. 4 functions that will interact with each other through SNS. Two functions will run check on a cron schedule (via the ‘schedule.rate’ params) to check a file need to be reprocessed and trigger another function via an SNS. This configuration will be able to scale effortlessly while keeping our cost under control. We are able to fully silo-ed our environments using iamRoleStatements to configure the permissions. We used an external variable to manage environment variables from a simple YAML file.

We considered running a couple of small instances to do a job which would cost us at least $1k for the year. Meanwhile, the AWS Lambda cost is meaningless since we are only running tens of thousands of functions a day.

What’s Next?

Using Serverless helped us get CloudForecast.io off the ground quickly. We saved our first clients thousands of dollars by giving them visibility into their AWS spend.

We are in the process of integrating AWS Athena into CloudForecast for our next project. Integrating with AWS Athena will enable new features that will allow end users to dive deeper into their AWS spend. Every company has unique spending patterns, and this will allow them to fully understand where their $$$ is going. We will write more about our Athena integration soon.

If you have any questions related to this post or what we do at CloudForecast.io, feel free to reach out to me at francois@cloudforecast.io. We would love to hear from you!

-Francois & the CloudForecast Team

Special Thanks to Kyle Galbraith for reviewing this draft. Check out his weekly Newsletter, Learn By Doing. Learn by Doing is a free weekly curated cloud, blockchain, and coding newsletter delivered to your inbox every week.