Show HN: Cloudyali.io – Complete AWS Cloud Asset Inventory Service (Live Demo)
cloudyali.io
cloudyali.io
CloudYali is a service to instantly discover/inventory AWS Cloud assets across accounts and regions.
I have worked in AWS cloud for last 6 years, and many times I had to get an inventory of assets in one place. The tools I found were not adequate, including AWS Config.
Two major issues I found that needs to be fixed: 1. Coverage: Many these tools cover a limited set of AWS Resources. e.g. AWS Config covers merely ~103 resources across ~230 AWS services. The coverage is less than 20%. 2. Usability: These tools are either designed at regional or account level. Eg. AWS Config is at regional level, and requires configuration changes to make it work across regions.
CloudYali, is designed to work across multiple accounts and regions by default. To begin with we have added support for ~250 resources (and will add more in going time).
It is also possible to search for the resources based on Account IDs, regions, resource types. (Search based on resource attributes is in development currently)
CloudYali, also maintains the resource configuration change history and shows a visual timeline for the changes. Which means, you can compare the configuration changes in UI head-to-head.
CloudYali, also tracks the asset lifetimes, so that you can clearly see what assets are Live/Active and what assets are Deleted (and what time)
CloudYali is easy to setup and is a readonly service.
We have now launched a Live Demo of the service with real AWS inventory data, discovered and inventoried by CloudYali. The Live Demo link is available on the landing page.
We are looking for cloud engineers who are willing to try our service and provide feedback.
As a token of appreciation we are giving two months of service to early users at no cost.
Thank you!
Do we get the source code for everything in your package?
Do we at least get object code that we can run behind our “firewall” that doesn’t reach out to your servers, and thus risk exposing sensitive information?
Or are you selling a third-party service that collects all the most sensitive information it can possibly collect about our services, and then stores all that collected information in an opaque database somewhere that we have no direct access to and no control of? What happens when there is a breach in your systems and all your records of all your customers are exposed?
Currently it is third party service collecting the data, we reduct the sensitive information. The data is encrypted at rest and we follow best security rules.
Though our existing model is SaaS based, we are contemplating to separate the control plane into SaaS model, while keeping data plane within the users account. We want to work with our users feedback for this.
Please do try and share your valuable feedback.Thanks!
As we know AWS Config, when debuted in 2014 it promised to be the configuration auditor for AWS. The mandate for any team working in AWS workload management, is security and cost effectiveness along with operational efficiency. This requires a great deal of visibility into the cloud workloads. These workloads consists of cloud assets (or resources) from multiple AWS services. As a configuration auditor, AWS Config is supposed to provide a complete visibility into the cloud assets, keep the configuration history of changes and help in achieving the regulatory compliance.
Today AWS has more than 200 services, and more than 500 cloud assets types. In 2017, AWS Config supported ~26 services and 72 resource types. In 2021, the coverage has reached barely 103 resource types. This is ~20% coverage across all the asset types. These assets have relationships which may cross the service boundaries. These relationships are important to be understood, from security point of view (lateral movement attacks). Similarly you need to know about all your assets from cost point of view. You never know if someone accidentally started any expensive service, say macie and you realise it only when the monthly bills arrive. Problem with AWS Config is lack of coverage and even slower addition of newer resource types into coverage.
Yet another issue is usability. AWS Config is a regional service, which needs to be configured across all regions and accounts. This is a sizeable effort. Recently only AWS Config started with Organizations support. When you’re in midst of incident resolution, the important t for any cloud team is access to historical information about the configuration changes. AWS Config UI and CLI is not something you want to deal with at that moment.
For CloudYali, the mission is to provide visibility across all the cloud with usability in mind. CloudYali works on multiple accounts and all regions by default. This means, by default you are looking at the cloud assets across your whole cloud. We have currently added a support for ~ 250 asset types (and we will keep adding).
CloudYali, also maintains the lifetime of the assets, and the history of configuration changes. It is like applying version control to the cloud. The configuration changes are visualised on the timeline, where you can choose to see configuration attributes at any given time. We clearly mark the assets as Live/Active or Deleted if asset no longer exists. It is also possible to filter assets based on the accounts, regions, or time duration so that it is easier to pinpoint assets. This makes troubleshooting easier for cloud operations. Consider for example, rules in load balancer, min/max for auto-scaling group. These things are often changed manually during production issues and if you don't have backups, it's quite easy to mis-configure and then spend time trying to recall previous values. CloudYali intends to be helpful in such scenarios.
I hope this answers your query.
Thanks,