In the last decade, cloud computing has emerged as the dominant solution for delivering reliable, scalable, and cost-effective IT infrastructures to enterprises. Here at kreuzwerker, we can share many success stories of how we helped our customers to boost productivity and performance of their businesses by migrating their IT systems to the cloud.
Among the pioneers of the cloud revolution, Amazon Web Services (AWS) is today the de-facto leader in the cloud computing market. Crucial to the success of AWS is the range and quality of the services provided, its ‘pay-as-you-go’ pricing model, and by far the simplest and most user-friendly UI for DevOps. Thanks to these features, building complex cloud infrastructures using AWS can be done in a breeze, making the creation and modification of web resources stunningly easy. Perhaps, a little too easy, given the challenges and costs of maintaining a growing number of resources healthy and compliant.
Our daily experience at kreuzwerker reminds us how complicated this issue can get, and yet how often it is overlooked. This is especially true for mid-large enterprises, in which the vast number of applications deployed over multiple AWS accounts and operated by different teams can make cloud governance maddening, to say the least.
AWS Config: The Good, the Bad, and the Ugly
Knowing the importance of maintaining a fully functional and compliant cloud infrastructure, three years ago AWS released AWS Config, its solution for cloud governance. AWS Config includes an automatic resource compliance checker, which makes it easy to define the desired compliance policies as a collection of Config Rules. For example, a Config Rule may require that all Amazon Elastic Compute Cloud (EC2) instances must be tagged with an “AdminMail”, or that no Security Groups within a given Virtual Private Cloud allows unrestricted ingress access to the SSH protocol. If, during its life cycle, an AWS resource fails to satisfy any of the defined Config Rules, then AWS Config flags the resource as non-compliant, and a notification to some designated recipients can be sent right away.
AWS Config comes with a set of predefined Config Rules. These include common compliance checks, such as checking whether an AWS resource (e.g., an EC2 instance) has a given tag (e.g., “AdminMail”). In addition to predefined rules, which are limited in number and allow only minimal customisation, AWS Config supports the definition of custom rules. Note that the logic to evaluate the compliance of an AWS resource against a custom Config Rule must be provided as an Amazon Lambda function.
All in all, when it comes to cloud governance, AWS Config can be a great help. Nevertheless, there are some unattractive aspects and limitations that we would like to comment on.
Config Rule’s Scope: AWS Config does not adequately support the definition of Config Rules on resources spanning different regions or AWS accounts, which instead is quite commonplace to large sized enterprises. Keeping in mind that custom rules need to be deployed as Lambda functions, deployment and maintenance (like collecting Lambda function logs) of those can be painful in a multi-region or multi-account setup.
Notification Control: AWS Config can be easily configured to send updates about the compliance state of the monitored resources, by using Amazon SNS. However, there is no off-the-shelf solution for customising the notification’s content and format, nor fine-grained control over the notification’s recipients (all notifications are sent to the same Amazon SNS topic). Such desirable features must be manually implemented and integrated, for example, as additional Lambda functions.
Compliance Enforcement: AWS Config does not directly modify the state of non-compliant resources, but simply flags them as non-compliant and notifies the designed recipients to take the necessary actions. Although this is a wise choice for most cases, these are some scenarios whereby automating corrective actions could save time and effort. For example, revoking non-compliant ingress rules in a Security Group automatically.
Cost, of course, as adding Config Rules carries a non-negligible price.
The Case for a new Cloud Governance Tool
What we hope emerges from our discussion is the need for a flexible and unifying tool for designing, evaluating, and enforcing compliance rules on AWS cloud infrastructures. Driven by this need, and building on the many lessons learned from our customers and partners, we at kreuzwerker felt it was the time to develop our own solution.
But this shall be the subject of our next post ; )
Stay tuned!
PS. have you already registered to the DevOpsDays Berlin 2017? We can’t wait to meet you there to discuss this and other exciting topics!
Image credits for the cover image go to movietimes.com