Efficient Power Management in AWS
Author: Nicholas M. Hughes
AWS facilitates the implementation of DevSecOps practices by providing scalable and secure cloud infrastructure, supporting automation, and offering a suite of security services and features that can be integrated into the development lifecycle. Yet given the complexities of AWS, efficient power management is essential to reap all the benefits of this comprehensive cloud computing platform. It’s not merely about keeping systems operational; it’s a strategic orchestration of resources to ensure optimal performance and cost-effectiveness.
Let’s delve into the mechanisms that make this possible, exploring the typical workflows and unveiling strategies to enhance power management in AWS.
Introduction: Unpacking AWS power management
In AWS infrastructure, power management is a critical component that ensures resources, such as ECS/EC2, are utilized efficiently. It involves a series of coordinated processes and workflows aimed at optimizing resource availability and performance based on specific operational needs and schedules. The goal is to achieve a balance, ensuring resources are available when needed, without incurring unnecessary costs due to underutilization or over-provisioning.
Exploring the typical power management flow
Many folks have implemented a solution such as the one that follows. It generally involves a mechanism that uses Time Triggers and Lambda functions, which work together to manage the start/stop instances and scaling of containers based on predefined tags and schedules.
A Time Trigger, provided by AWS CloudWatch, acts on a specific schedule. This will be the minimum time interval.
When the Time Trigger is activated, it invokes a Lambda function, which is tasked with the overall “Power Control” logic.
The Power Lambda function has two core responsibilities:
● Read tags from the infrastructure, which are pertinent to the power control process.
● Perform power or scaling operations as an action based on the tags and inherent logic in the function.
4. The ECS/EC2 infrastructure, Amazon's container and compute services which run workloads and applications, could be tagged with specific days of the week and times of day to start/stop instances or scale containers as appropriate.
As an example, given the tags shown below, the instances or containers would be available from 10:00 am UTC until 10:00 pm UTC every weekday. If they are found running outside of those times due to manual start-up, the EC2 instances would be stopped or the ECS tasks scaled down at the next designated stop time.
● START_DAYS = M T W R F
● START_TIME = 1000
● STOP_DAYS = M T W R F S U
● STOP_TIME = 2200
External Customer Application Startup Flow
With the previous workflow, manual startup outside of the controlled process would generally require access to the AWS account in question. However, it’s not feasible or recommended to provide that type of access to all users of an application. So, how can we provide users with the ability to start up applications at will?
That’s exactly what we set out to solve for one of our customers. And before you ask, 'Why would anyone need to allow their users to start a system?' let me sum up...
Say you have development systems that you don’t need running all of the time and you don’t want to give AWS access to all of your development team. Or maybe you have pre-production or staging systems where you want to perform user acceptance validation before rolling updates to production. Or maybe you just think this is a really cool solution and you don’t need a good reason to deploy it... Well, read on!
Let’s assume we have an existing endpoint app.foo.com defined as a Simple DNS Record in Amazon Route53, which points to the load balancer providing access to our application.
We’d convert that record to a Failover type, which allows us to point to our application when it’s healthy, and then fail over to a static site in S3 when it’s not.
If the primary infrastructure (ALB leading to ECS/EC2) is healthy:
● The request gets directed to the load balancer, which handles the application.
● The ECS/EC2 infrastructure processes the request and returns the appropriate response.
3. However, if the health check detects that the primary infrastructure is unhealthy:
● The request is rerouted to the backup path, starting with the Content Delivery Network (CDN), which is designed to serve content with low latency and high transfer speeds. This step is mostly here so we can provide TLS on the static site.
● The static site from S3 is shown, and we’re able to provide basic content and JavaScript to a user’s browser. In this case, our static site invokes a Lambda function when we press a “Start” button on the page.
● The associated infrastructure which should be hosting the primary path is then started or scaled up as appropriate.
4. Once the application is back up, it will take a few minutes for the health checks to report the application is healthy and then possibly a few more minutes for the DNS TTL to expire. Then the browser can be refreshed and the application will be shown normally.
Conclusion: Innovating with External Customer Application Startup Flow in AWS power management
In wrapping up, it's essential to spotlight the innovative approach of the External Customer Application Startup Flow in AWS power management. This methodology is not just a step, but a leap forward in enhancing user accessibility and autonomy. It ingeniously allows users to initiate system startups without needing comprehensive access to the AWS account, striking a balance between user empowerment and system security.
By enabling a mechanism where users can activate applications at will, it brings a layer of flexibility and responsiveness to system management. It ensures that necessary systems, like development or pre-production environments, are available precisely when needed, enhancing overall workflow efficiency and user productivity. This approach exemplifies a thoughtful innovation in AWS power management, showcasing a commitment to improving user experience and operational agility.
If either of these automation projects caught your eye or sparked an idea, let’s chat! We can discuss how to tailor these concepts to fit your organization’s unique DevSecOps needs and challenges, ensuring you get the maximum benefit from your automation efforts.