Skip to main content

7 posts tagged with "aws"

View All Tags

· 6 min read
Anja Freihube

Cloud tagging strategies and policies are hailed as one of the most efficient ways to keep your cloud infrastructure controllable. But are they really?

Generally, the idea is that every piece of cloud service gets tagged (or labeled, in case of GCP) by the developers or maintainers who work with it. This could be accomplished with infrastructure-as-code (IaC) tools (such as Terraform), with a command-line interface (CLI), or in the cloud UI.

Tagging policies could require that each resource needs tags identifying the owner, cost center, product, project, and/or any other metadata. By being diligent about tagging, resources can be managed via their tags and nothing gets overlooked.

In theory, this is the correct way to manage resources; in practice, however, this hardly ever works as intended. Each tag created is a tag that requires maintenance. Tagging policies may change over time and people can make mistakes (in AWS, for example, tag keys are case sensitive). And, to properly use tagging on a greenfield cloud account is one thing; to retroactively apply tags to sprawling cloud infrastructure is quite another (especially when utilizing a multi-cloud strategy, where you'd need to repeat any operation over multiple interfaces).

· 7 min read
Anja Freihube

"It [is] the best of times, it [is] the worst of times." Software engineers working with AWS have any cloud service imaginable at their fingertips and developer velocity could hardly be higher. But, even the most shiny of coins has two sides.

While developers can spin up compute instances, databases, and less tangible things like Lambda functions or virtual identities as they wish—at some point, someone will ask, "What is all of this?" And as they hack away in the CLI trying to get an overview of the resources in all of their AWS accounts, they will inevitably get frustrated. While Amazon has been a pioneer in cloud computing and offers the largest array of services, there are some things that aren't so ideal. Namely, API consistency.

In this post, I describe a few of the challenges and quirks with the AWS API and why we're building Resoto. (Spoiler alert: It is so that you don't have to!)

· 6 min read
Matthias Veit

Resoto uses a directed graph to represent your infrastructure resources as nodes and relationships between them as edges. A load balancer for example is represented as node with edges pointing to all target compute instances. The compute instance might have a volume attached, where we would see an edge between the instance node and the volume node.

The nodes represent the actual resources. The edges define the relationship between the nodes. It is possible and highly likely, that one resource has multiple relationships to other resources.

Sheep Jumping on a Graph

· 4 min read
Matthias Veit

Retrieving information about resources you have deployed in your Amazon Web Services (AWS) infrastructure means tediously navigating the AWS Management Console or using the AWS Command Line Interface. This approach works well in a single account setup, but best practice is to set up a multi-account environment. And as the number of accounts grows, navigating your infrastructure and finding resources via the Console or the CLI becomes increasingly difficult.

Furthermore, the relationships between your resources are also relevant: an EBS volume is mounted to an EC2 instance running in a VPC and reachable via an ALB load balancer, for example. Developers create resources using tools such as Terraform, CDK, or CloudFormation… or sometimes even the console or CLI. How can you see everything that is running in your cloud?

Left: Sheep Spinning Up Cloud Resources; Right: Confused Sheep with Abacus