Want to level up your AWS knowledge? Explore our tutorials and step-by-step guides written by AWS experts. Learn AWS best practices and solutions to the most difficult problems.

AWS Guides and Tutorials | Spacelift Blog

Author title

🎉Spacelift raises $51M Series C to redefine the future of infrastructure

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

Product

Why Spacelift

How it Works

Spacelift platform

Terraform

Ansible

OpenTofu

See all integrations

Integrations

vs Terraform Cloud

vs Terraform Enterprise

vs Atlantis

vs Generic CI/CD

Compare

Register now

introducing-saturnhead-ai-blog-image

Introducing Saturnhead AI Blog Image

Introducing Saturnhead AI

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

Blog

blog-2

partners

Partners

partners-2

events

Events

events-2

eBooks, webinars, cheat sheets and tools to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Resource Library

users

Users

users-2

Case Studies

Essential content and resources to help you achieve IaC excellence

chat-3

media guide

chat-hover

media guide hover

Mission Guides

539-infra-automation-report-1

539.infra automation report

The Infrastructure Automation Report, 2025

About Us

Contact Us

Accessibility

About

cheatsheets-2

Test

See more

Test webinar name

How it works

Open Tofu

Kubernetes

388-terraform-yamlencode

terraform yamlencode

Using Terraform YAML Functions: Yamldecode & Yamlencode

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

What is AWS Security Token Service (STS)?

James Walker

AWS Security Token Service (STS) is an AWS facility for requesting temporary user credentials with limited privileges. It allows you to acquire short-term access to privileged roles in a controlled manner.
STS is ideal when you must briefly interact with sensitive resources in your AWS account, but don&#8217;t want to set up a dedicated IAM identity. The credentials issued by STS function identically to regular IAM access keys, but aren&#8217;t stored against users and have a limited lifespan – typically a few minutes or hours, with up to 36 hours permissible.
In this article, we will cover:
<ol>
<li><a href="https://spacelift.io/blog/aws-sts#what-is-aws-security-token-service-sts">What is AWS Security Token Service (STS)?</a></li>
<li><a href="https://spacelift.io/blog/aws-sts#when-to-use-aws-sts">When to Use AWS STS?</a></li>
<li><a href="https://spacelift.io/blog/aws-sts#how-does-aws-sts-work">How Does AWS STS Work?</a></li>
<li><a href="https://spacelift.io/blog/aws-sts#example-using-aws-sts-to-assume-a-role">Example: Using AWS STS to Assume a Role</a></li>
</ol>

AWS <a href="https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html" target="_blank" rel="nofollow noopener">Security Token Service (STS)</a> provides a mechanism for issuing existing users with temporary credentials that grant access to additional resources. The credentials are generated dynamically, aren&#8217;t stored against the user, and have a short lifetime. After an issued set of credentials expires, the user must make another request to STS to re-obtain their privileges if they still require them.
Using STS-issued temporary credentials helps you increase the protection for your AWS account. You can assign users a reduced set of permissions, then allow them to acquire short-term access to sensitive resources on a per-occasion basis.
<h3>What&#8217;s the Difference Between STS and IAM Roles?</h3>
STS and IAM roles complement each other. STS credentials are typically used to delegate access to the <a href="https://spacelift.io/blog/aws-iam-roles" target="_blank" rel="noopener">IAM roles</a> in your AWS account. A role is an AWS identity that includes one or more permission policies granting access to specific AWS features.
You can directly assign roles to your AWS users, but this creates a risk of over-privileged accounts. For example, deleting an S3 bucket could be a sensitive but rare operation for your organization. Choosing to directly assign a role with the &#8220;delete bucket&#8221; permission means anyone with access to the credentials can always delete a bucket though.
STS allows authorized users to assume these privileged roles on the occasions that they actually need them. Instead of permanently holding the bucket deletion role, users are able to temporarily acquire the required privileges, then have them automatically expire. This maintains security by allowing a minimal set of privileges to be persisted against the user account.

STS is central to several different AWS authorization flows. Here are four common use cases that it facilitates.
<ol>
<li>Short-lived access to privileged AWS resources</li>
<li>Accessing AWS within applications</li>
<li>Identity federation scenarios</li>
<li>Cross-account and delegated access</li>
</ol>
<h3>Short-lived access to privileged AWS resources</h3>
STS is suitable for any situation where you need to acquire short-term access to privileged AWS resources or features. It allows your existing users to assume a sensitive role without having to set up a dedicated IAM identity or run the risk of forgetting to revoke the credentials later on.
You can use STS to improve the security posture for your AWS accounts by preventing the direct assignment of these roles to your users. Instead, configure <a href="https://aws.amazon.com/blogs/security/how-to-use-trust-policies-with-iam-roles" target="_blank" rel="nofollow noopener">STS policies</a> for your users so they can request the role at the time they need it.
<h3>Accessing AWS within applications</h3>
STS helps you manage credentials that are required by apps and tools that integrate with your AWS account. It&#8217;s best to avoid distributing regular IAM credentials, as these provide long-term access to the privileges they&#8217;re assigned.
With STS, you get to assign your app a locked-down credential that it can use to assume additional privileges. If you need to change or revoke those privileges, you can do so without having to supply new credentials to the application.
<h3>Identity federation scenarios</h3>
STS facilitates <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html" target="_blank" rel="nofollow noopener">identity federation</a> scenarios for AWS accounts. The mechanism allows users to log in to AWS through an external OIDC or SAML provider, such as Azure or Google, then receive access to existing AWS resources without having to create dedicated IAM credentials first.
To configure this workflow, you&#8217;ll need to <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create.html" target="_blank" rel="nofollow noopener">register an IAM identity provider</a> that sets up a trust relationship with the external platform. Users can then sign in with the provider to receive access to your AWS account via STS-issued credentials.
<h3>Cross-account and delegated access</h3>
STS also enables cross-account access sharing. This is designed for organizations that use multiple AWS accounts but want to maintain a central index of user identities in one of the accounts.
STS allows you to <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html" target="_blank" rel="nofollow noopener">delegate temporary access</a> to IAM users belonging to other accounts held by your organization. This avoids the need to set up dedicated IAM identities in each of the AWS accounts, which would be a management overhead that could cause security oversights.

<ul>
<li><a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">SaaS not an option? Install Spacelift Self-Hosted on AWS</a></li>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Why DevOps Engineers Recommend Spacelift</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">11 Ways to Improve Your Infrastructure Orchestration</a></li>
</ul>

There are five main steps involved in a successful STS transaction that allows a user to assume an IAM role. 
Here&#8217;s how it works:
<ol>
<li style="font-weight: 400;" aria-level="1">The role is created. An AWS administrator creates an IAM role that includes the permissions the user will require.</li>
<li style="font-weight: 400;" aria-level="1">An administrator configures a trust policy for the target user and role. Once a trust policy has been created, the user can call the STS service to request credentials for that role. Without an applicable trust policy, STS will refuse to issue credentials for the role.</li>
<li style="font-weight: 400;" aria-level="1">When the role&#8217;s privileges are required, the user calls the STS API and requests to assume the role. STS validates the request by checking that an appropriate trust policy exists.</li>
<li style="font-weight: 400;" aria-level="1">STS dynamically generates a new set of credentials and issues them to the user&#8217;s application within an API response. The credentials are not stored against the user and will only be valid until they expire.</li>
<li style="font-weight: 400;" aria-level="1">The user calls the AWS API they need to interact with, this time supplying their temporary credentials. Access will be granted until the credentials expire.</li>
</ol>
Let&#8217;s see this workflow in action by setting up a demo that uses STS to temporarily acquire access to S3 storage buckets.

We will use the<a href="https://aws.amazon.com/cli" target="_blank" rel="nofollow noopener"> AWS CLI</a> for this tutorial. Before continuing, ensure you&#8217;ve got the CLI installed and connected to your AWS account.
<h3>1. Create an S3 bucket</h3>
First, create an AWS bucket to use for the tutorial. We&#8217;re calling ours <code>spacelift-sts-demo</code>:

<h3>2. Create an IAM user</h3>
Next, create a new IAM user for the tutorial. This is the user who’ll use STS to gain temporary access to S3. 
Our user is called <code>spacelift-demo</code>:

Note down the <code>Arn</code> value that&#8217;s displayed in the response – you&#8217;ll need it later in this guide, as it&#8217;s the user&#8217;s unique AWS ID.
Next, create an access key for your new IAM user, which will allow you to authenticate as that identity:

Note down the <code>AccessKeyId</code> and <code>SecretAccessKey</code> values displayed in the response.
Next, open a new terminal window and change the <code>AWS_ACCESS_KEY_ID</code> and <code>AWS_SECRET_ACCESS_TOKEN</code> environment variables to the values displayed in the previous access key generation response. 
This will configure the AWS CLI to authenticate as your new IAM user:

Try to list the S3 buckets available to the account:

Access denied! The brand new IAM user doesn&#8217;t have any roles or privileges, so it can&#8217;t perform the action. 
Let&#8217;s set up STS and use it to acquire short-term access rights.
<h3>3. Allow the user to assume roles with STS</h3>
The ability for a user to assume roles through STS is itself gated on an IAM permission – <code>sts:AssumeRole</code>. Consequently, the demo user must be assigned a role that includes this permission.
Create an IAM policy document JSON file that defines the role:

Save the file as <code>sts-role.json</code> in your working directory, then use the AWS CLI to add it to your account:

Copy the value of the <code>Arn</code> field shown in the response, then substitute it into the following command. This will assign the role to your IAM user, allowing the identity to assume other roles through STS.

<h3>4. Create the role that your user will assume</h3>
Next, create an IAM role that gives users read-only access to S3 data. This is the role your user will assume through STS.
Copy the following JSON and save it to <code>s3-readonly-role.json</code>:

Use the AWS CLI to create the <a href="https://spacelift.io/blog/iam-policy" target="_blank" rel="noopener">policy</a>:

Once again, note down the <code>Arn</code> that&#8217;s displayed, as you&#8217;ll need it in the next step.
<h3>5. Create a trust policy that allows your user to assume the role</h3>
The next step is to set up an IAM trust policy that connects your IAM user and your role. The trust policy will allow the user to assume the rule through STS.
Copy the following policy file to <code>user-trust-policy.json</code>, then replace the <code>Principal.AWS</code> value with the ARN of your IAM user, which you noted in Step 1:

Then add the trust policy to your account:

Creating this trust policy role allows the specific user identified in the <code>Principal</code> field to assume the roles it refers to. 
However, we haven&#8217;t connected any roles to the trust policy yet – run the following command to achieve this after substituting the value of the <code>--policy-arn</code> flag with the ARN of your <code>s3-readonly</code> role:

The role that permits access to the S3 buckets is now attached to the trust policy role. In turn, the trust policy is associated with the IAM user you created. As a result, that user can now use STS to assume the S3 role.
<h3>6. Using STS to assume the role</h3>
Switch back to your second terminal, where you&#8217;re authenticated as the IAM user.
Run the following command to assume the role through STS. You must input the ARN of the trust policy role created in the previous step, as well as a session name that uniquely identifies this use of the assumed role:

The response data shows that STS has provided a new set of credentials with a default lifetime of 1 day. To generate credentials with a specific lifetime, include the <code>--duration-seconds</code> flag when you run the <code>sts assume-role</code> command:

Next, update your shell environment variables to make the AWS CLI now authenticate with your temporary STS credentials. Unlike regular credentials, you must also supply the session token included in the STS response, which provides an additional layer of security protection:

Finally, you should now be able to successfully list your S3 buckets while authenticated with your temporary credentials:

You&#8217;ve used STS to assume a role that grants the privileges to interact with S3! If you check the identity that&#8217;s presented to AWS, it will report the temporary user ID assigned to your STS session:

AWS STS provides controlled short-term access to privileged roles, without requiring the use of dedicated IAM identities. With STS, you can safely assume a role to access sensitive resources. Your access will automatically expire, and no credentials will be stored.
STS is also used to integrate tools and services which require temporary access to your AWS account. <a href="https://docs.spacelift.io/integrations/cloud-providers/aws" target="_blank" rel="noopener">Spacelift</a> can integrate with STS to automatically assume IAM roles for your Spacelift <a href="https://docs.spacelift.io/concepts/run" target="_blank" rel="noopener">runs</a> and <a href="https://docs.spacelift.io/concepts/run/task" target="_blank" rel="noopener">tasks</a>, facilitating the use of authenticated AWS sessions without any manual configuration.
Here you can <a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">learn more about self-hosting Spacelift in AWS</a>, to ensure your organization’s compliance, control ingress, egress, internal traffic, and certificates, and have the flexibility to run it within GovCloud. You can also <a href="https://docs.spacelift.io/integrations/cloud-providers/aws" target="_blank" rel="noopener">see Spacelift integration with AWS</a>, with our Cloud Integrations section and our update to support account-level AWS integrations.

<span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

AWS Cost Optimization: Strategies, Best Practices, and Tools

How to Run Kubernetes on AWS - Tutorial

AWS S3 Cp [Copy] Command Overview with Examples

Flavius Dinu

AWS STS definition and overview. See an example of how to assume a role with AWS STS.

215-aws-sts

What is AWS STS - Security Token Service?

Sumeet Ninawe

Scaling AWS infrastructure is essential to accommodate increasing environment demands. It helps maintain high service reliability and optimizes AWS resource utilization. Even better, the process isn’t as complex as most people think.
AWS has excellent service capabilities to enable high scalability among infrastructure components and cloud-hosted applications. We will explore Amazon tools and features that are perfect for scaling the existing AWS infrastructure.
In this article, we will cover:
<ol>
<li><a href="https://spacelift.io/blog/aws-scaling#first-step-analyzing-the-aws-infrastructure">First step: Analyzing the infrastructure</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#scaling-aws-web-servers">Scaling Web Servers</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#scaling-aws-databases">Scaling AWS databases</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#scalable-eventdriven-architecture">Scalable event-driven architecture</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#how-to-scale-aws-lambda">How to scale AWS Lambda</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#benefits-of-scaling-aws-infrastructure">Benefits of scaling</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#example-scaling-aws-ec2-instances-with-terraform">Example: Scaling AWS infrastructure with Terraform using count</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#scaling-kubernetes-clusters">Scaling Kubernetes clusters</a></li>
<li><a href="https://spacelift.io/blog/aws-scaling#best-practices-for-scaling-aws-infrastructure">Best practices for scaling AWS infrastructure</a></li>
</ol>

Before scaling the infrastructure horizontally or vertically, we first need to analyze it. This helps us identify bottlenecks or performance issues that can limit the effectiveness of scaling efforts. We can also identify underutilized resources for optimization and evaluate the infrastructure’s scalability requirements.
<a href="https://spacelift.io/blog/aws-monitoring-tools" target="_blank" rel="noopener">Monitoring the AWS infrastructure</a> is essential for gathering key insights and metrics. It helps optimize performance, identify potential issues, and ensure the infrastructure’s security and compliance. This information enables data-driven decisions to enhance resource utilization and reduce costs.
AWS CloudWatch is the best service for monitoring and scaling AWS infrastructure. We can also use various third-party tools including Splunk, NewRelic, and Datadog to monitor AWS infrastructure. Each of these tools has different capabilities and is suitable for different types of AWS infrastructure.
<h3>Identify bottlenecks</h3>
Infrastructure bottlenecks are events that cause various service disruptions, such as:
<ol>
<li style="font-weight: 400;" aria-level="1">Network congestion due to insufficient bandwidth</li>
<li style="font-weight: 400;" aria-level="1">Loss of user engagement and data</li>
<li style="font-weight: 400;" aria-level="1">Delays in infrastructure resource deployments</li>
<li style="font-weight: 400;" aria-level="1">Physical failure of the servers, routers, databases, apps, etc.</li>
<li style="font-weight: 400;" aria-level="1">Outdated hardware or software components</li>
</ol>
Bottlenecks can occur at any point in the infrastructure, resulting in slower processing time and reduced productivity. Addressing infrastructure bottlenecks is crucial to reducing system downtime.
Tools like AWS Trusted Advisor, New Relic, Datadog, or CloudWatch help identify the source of the bottlenecks and implement best practices such as hardware upgrades, software optimization, additional capacity provisioning, etc.
<h3>Leverage AWS CloudWatch</h3>
AWS CloudWatch is a powerful AWS monitoring and logging service for collecting and analyzing data on infrastructure resource utilization, software performance, and network traffic. Use the methods below to leverage AWS CloudWatch to scale any AWS infrastructure.
<ul>
<li style="font-weight: 400;" aria-level="1">Monitoring logs: Use CloudWatch’s real-time monitoring and alerting capabilities to fetch monitor logs and resource utilization reports from security metrics. Refer to the logs to identify potential issues that might impact resource availability and performance.</li>
<li style="font-weight: 400;" aria-level="1">Key metrics: AWS CloudWatch has a centralized dashboard to view all existing AWS resources and applications. Define key performance indicators (KPIs) and other metrics that are relevant to the service. Monitor the thresholds of AWS resources for scaling and create scaling policies accordingly with the help of the defined metrics.</li>
<li style="font-weight: 400;" aria-level="1">CloudWatch alarms: Use the AWS Management Console or CloudWatch API to create and configure alarms in CloudWatch that notify us whenever metrics reach predefined threshold levels.</li>
<li style="font-weight: 400;" aria-level="1">Infrastructure scaling policies: Create or define separate infrastructure scaling policies to define the precautionary actions that need to be taken when an alarm is triggered. To configure the policies, we can use the AWS Auto Scaling service or the AWS EC2 Auto Scaling service.</li>
</ul>

Scaling AWS web servers ensures proper handling of web traffic with improved application performance and availability. It distributes the workload to handle an increasing number of incoming requests without affecting the availability of websites and web apps. 
<h3>AWS vertical scaling (scaling up/down)</h3>
Vertical scaling in AWS involves increasing or decreasing the capacity of a single resource, such as upgrading an instance to a more powerful one or reducing its capacity.
<ul>
<li style="font-weight: 400;" aria-level="1">Scaling up: Increasing the power of an individual resource. For example:
<ul>
<li style="font-weight: 400;" aria-level="2">Moving from a t3.medium EC2 instance to a m5.large instance with more CPU and memory.</li>
<li style="font-weight: 400;" aria-level="2">Adding more storage to an EBS volume</li>
<li style="font-weight: 400;" aria-level="2">Using a more powerful RDS database instance</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">Scaling down: Decreasing the power of a resource when demand decreases &#8211; for example:
<ul>
<li style="font-weight: 400;" aria-level="2">Downgrading an EC2 instance from m5.large to t3.small</li>
<li style="font-weight: 400;" aria-level="2">Reducing the allocated storage or instance type for an RDS database</li>
</ul>
</li>
</ul>
<h3>AWS horizontal scaling (scaling out/in)</h3>
Horizontal scaling of AWS infrastructure involves adding or removing multiple resources to distribute the load across a larger system. It’s typically implemented by adding or removing instances or servers.
<ul>
<li style="font-weight: 400;" aria-level="1">Scaling out: Adding more instances to handle the increased load &#8211; for example:
<ul>
<li style="font-weight: 400;" aria-level="2">Adding more EC2 instances to an Auto Scaling Group</li>
<li style="font-weight: 400;" aria-level="2">Adding more nodes to an RDS Aurora cluster</li>
<li style="font-weight: 400;" aria-level="2">Increasing the <a href="https://spacelift.io/blog/kubernetes-scaling" target="_blank" rel="noopener">number of containers in a Kubernetes cluster</a></li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">Scaling in: Removing instances or nodes when demand decreases &#8211; for example:
<ul>
<li style="font-weight: 400;" aria-level="2">Reducing the number of EC2 instances in an Auto Scaling Group</li>
<li style="font-weight: 400;" aria-level="2">Removing nodes from a distributed system like Amazon ElastiCache</li>
</ul>
</li>
</ul>
<h3>Horizontal vs. vertical scaling in AWS</h3>
&nbsp;

horizontal-vs-vertical-scaling

horizontal vs vertical scaling

Let’s see how these broad ways of scaling web servers compare:
<table>
<tbody>
<tr>
<td></td>
<td>Vertical scaling</td>
<td>Horizontal scaling</td>
</tr>
<tr>
<td>Definition</td>
<td>Increasing/decreasing the size or capacity of a single resource</td>
<td>Adding/removing multiple resources to distribute the workload</td>
</tr>
<tr>
<td>Key actions</td>
<td>Upgrade or downgrade instance type or size</td>
<td>Add or remove instances or servers</td>
</tr>
<tr>
<td>Scalability limit</td>
<td>Limited by the maximum capacity of the resource</td>
<td>Theoretically unlimited with proper design</td>
</tr>
<tr>
<td>Downtime</td>
<td>May require downtime for upgrades</td>
<td>Can be achieved without downtime</td>
</tr>
<tr>
<td>Complexity</td>
<td>Simple to implement and manage</td>
<td>More complex; requires distributed systems</td>
</tr>
<tr>
<td>Application suitability</td>
<td>Best for monolithic or single-node applications</td>
<td>Ideal for distributed or stateless applications</td>
</tr>
<tr>
<td>Fault tolerance</td>
<td>Lower, as it depends on a single resource</td>
<td>Higher, due to distributed architecture</td>
</tr>
<tr>
<td>AWS example</td>
<td>Upgrading an EC2 instance type or RDS class</td>
<td>Auto Scaling EC2 instances or adding Aurora replicas</td>
</tr>
</tbody>
</table>
To summarize, vertical scaling enhances the capacity of a single resource to handle increased demand, whereas horizontal scaling expands capacity by adding multiple resources, enabling distributed load management.
Choose the type of scaling based on your AWS infrastructure setup and application requirements. Vertical scaling can be a quick solution for resource-intensive applications with occasional or predictable traffic peaks. However, for handling long-term growth, high availability, and unpredictable traffic patterns, horizontal scaling provides a more robust and scalable approach.

<h3>What is AWS Auto Scaling?</h3>
AWS Auto Scaling is a service that automatically increases or decreases the number of compute resources, such as EC2 instances, based on the current demand for your application.
For example, if the web server’s memory usage is over 90%, the Amazon EC2 Autoscaling service will dynamically add a new server instance. It will also remove the extra instance once the memory optimization is below the threshold value. 
The primary goal of Auto Scaling is to ensure that the application performs well and remains cost-efficient by scaling resources up or down as needed.

auto-scaling-group

auto scaling group

It is also possible to schedule Auto Scaling based on certain conditions on web servers. This offers us enough flexibility to scale in or scale out AWS infrastructure components during the scheduled runtimes. The system gets to the normal phase once the schedule is complete. 
Read more about deploying the <a href="https://spacelift.io/blog/terraform-autoscaling-group" target="_blank" rel="noopener">AWS auto-scaling group with Terraform</a>.
<h4>Key features of AWS Auto Scaling</h4>
Here are the key features of AWS Auto Scaling:
<ul>
<li style="font-weight: 400;" aria-level="1">Automatic scaling: Automatically adjusts the capacity of your AWS resources (e.g., EC2 instances, DynamoDB tables, Aurora databases) based on predefined conditions or actual demand.</li>
<li style="font-weight: 400;" aria-level="1">Dynamic scaling: Adjusts resources in real-time based on changing demand patterns. For example, it can add or remove EC2 instances based on CPU utilization or application metrics.</li>
<li style="font-weight: 400;" aria-level="1">Predictive scaling: Uses machine learning to predict future traffic patterns and adjusts capacity proactively to handle expected increases or decreases in demand.</li>
<li style="font-weight: 400;" aria-level="1">Resource scaling: Ensures that you’re not over-provisioning or under-provisioning resources, helping to optimize costs while maintaining performance.</li>
<li style="font-weight: 400;" aria-level="1">Scalability across multiple services: Supports various AWS resources, such as:
<ul>
<li style="font-weight: 400;" aria-level="2">Amazon EC2 instances</li>
<li style="font-weight: 400;" aria-level="2">Spot Fleet instances</li>
<li style="font-weight: 400;" aria-level="2">Amazon ECS (Elastic Container Service) tasks</li>
<li style="font-weight: 400;" aria-level="2">DynamoDB tables and indexes</li>
<li style="font-weight: 400;" aria-level="2">Aurora replicas</li>
</ul>
</li>
</ul>
<ul>
<li style="font-weight: 400;" aria-level="1">Health monitoring: Automatically replaces unhealthy instances or resources to maintain application availability.</li>
<li style="font-weight: 400;" aria-level="1">Scaling policies: Offers several scaling policies</li>
<li style="font-weight: 400;" aria-level="1">Target tracking scaling: Automatically adjusts capacity to maintain a target utilization metric (e.g., CPU usage).</li>
<li style="font-weight: 400;" aria-level="1">Step scaling: Scales resources in steps based on alarms triggered by CloudWatch metrics.</li>
<li style="font-weight: 400;" aria-level="1">Scheduled scaling: Increases or decreases capacity at specific times.</li>
<li style="font-weight: 400;" aria-level="1">Cost-optimization: Helps reduce costs by dynamically allocating just the right amount of resources, avoiding both underutilization and overprovisioning.</li>
</ul>
<h4>Auto Scaling use cases</h4>
Generally speaking, AWS Auto Scaling makes it easier to build highly available and scalable applications while minimizing operational overhead and costs. It can also be useful in the following scenarios:
<ul>
<li style="font-weight: 400;" aria-level="1">Handling unpredictable traffic spikes, such as during flash sales or marketing campaigns.</li>
<li style="font-weight: 400;" aria-level="1">Scaling applications to meet seasonal demand changes (e.g., holiday shopping).</li>
<li style="font-weight: 400;" aria-level="1">Maintaining consistent performance for applications with cyclical workloads (e.g., daily or weekly traffic patterns).</li>
<li style="font-weight: 400;" aria-level="1">Dynamically scaling compute resources to handle large-scale data processing tasks, such as rendering videos or running analytics pipelines, and de-scales once the jobs are completed.</li>
<li style="font-weight: 400;" aria-level="1">Automatically scaling development or testing instances up during working hours and down during off-hours to minimize costs while maintaining developer availability.</li>
</ul>

AWS Auto Scaling is more agile, cost-efficient, and automated compared to traditional scaling methods, making it ideal for dynamic and modern application environments. Traditional scaling methods, while still useful in some on-premises scenarios, lack the automation and flexibility needed to handle rapidly changing workloads.

<h3>Scaling with Application Load Balancer (ALB)</h3>
Application Load Balancer (ALB) is an AWS service that allows us to divide the application load between multiple AWS EC2 instances or Lambda functions. Here are the main types of AWS services that support ALB:
<ol>
<li style="font-weight: 400;" aria-level="1">EC2 instances</li>
<li style="font-weight: 400;" aria-level="1">EKS (Elastic Kubernetes Service)</li>
<li style="font-weight: 400;" aria-level="1">ECS (Elastic Container Service)</li>
</ol>
ALB is suited for handling HTTP or HTTPS traffic. It takes only a few minutes to set up the ALB in web servers and balance the traffic load between AWS EC2 instances.
Read more: <a href="https://spacelift.io/blog/terraform-alb" target="_blank" rel="noopener">How to Manage Application Load Balancer (ALB) with Terraform</a>.

Amazon Relational Database Service (RDS) is a collection of AWS-managed services that simplify database setup, scaling, and management in the cloud. Amazon supports all the popular relational database management systems and offers excellent scalability features.
<h3>Scaling AWS with Amazon RDS Multi-AZ</h3>
Amazon RDS Multi-AZ enhances the availability of the Amazon RDS database instances, making them ideal for handling production workloads. Below are some important reasons for using RDS Multi-AZ to scale AWS infrastructure.
<ul>
<li style="font-weight: 400;" aria-level="1">Automatic failover: This feature ensures the high availability of AWS databases by performing automatic database failovers within 60 seconds with no manual intervention and zero data loss.</li>
<li style="font-weight: 400;" aria-level="1">Protect database performance: This feature ensures that I/O activity is not suspended during the ongoing backup of the database standby instance.</li>
<li style="font-weight: 400;" aria-level="1">Enhanced durability: AWS RDS Multi-AZ synchronous replication can hold the data on standby database instances side-by-side with the primary instance.</li>
<li style="font-weight: 400;" aria-level="1">Increased availability: It allows us to deploy a standby database instance in another AZ and achieve excellent fault tolerance during instance failure.</li>
</ul>
The Multi-AZ feature of AWS RDS places a standby database instance in another availability zone to ensure high availability during hardware failures. Enabling this through the RDS dashboard is straightforward.
Learn <a href="https://spacelift.io/blog/terraform-aws-rds" target="_blank" rel="noopener">how to create an AWS RDS Instance using Terraform</a>.
<h3>Scaling AWS with RDS Read replicas</h3>
Amazon RDS Read Replicas are clone servers of the primary database server with similar features and capabilities. Being a secondary database instance, RDS Read Replicas offer enhanced read performance for Amazon RDS database instances by elastically scaling out the primary instance. 
Both primary and secondary database servers are auto-synced in real time to maintain data synchronization. However, it is possible to route web app traffic that only needs to read from the database to the Read Replicas directly, reducing the primary database instance’s workload.
Read replicas are available in Amazon Aurora and AWS RDS for MariaDB, MySQL, Oracle, PostgreSQL, and SQL Server.

<ul>
<li><a href="https://spacelift.io/blog/kubernetes-on-aws" target="_blank" rel="noopener">How to Run Kubernetes on AWS</a></li>
<li><a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">SaaS not an option? Install Spacelift Self-Hosted on AWS</a></li>
<li><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
</ul>

<h3>Scaling AWS with Aurora</h3>
Amazon Aurora offers unparalleled high availability and performance at a global scale with end-to-end PostgreSQL and MySQL compatibility. This relational database combines the capabilities of traditional enterprise databases with its simple yet cost-effective open-source databases. Amazon Aurora is perfect for:
<ol>
<li style="font-weight: 400;" aria-level="1">Modernizing the operations of enterprise applications like ERP, CRM, etc.</li>
<li style="font-weight: 400;" aria-level="1">Supporting reliable and multi-tenant SaaS applications with DB flexibility.</li>
<li style="font-weight: 400;" aria-level="1">Developing and deploying distributed applications at scale across different regions.</li>
<li style="font-weight: 400;" aria-level="1">Instantaneous serverless scaling to reduce operational expenses.</li>
</ol>
Compared to RDS, Amazon Aurora has built-in DR (disaster recovery) and HA (high availability) capabilities. It is easy to migrate from commercial database engines like SQL or Oracle to relational database instances. Aurora is perfect for scaling small to medium workloads in AWS infrastructure.

Event-driven architecture (EDA) is a design pattern in which decoupled components of a system communicate with each other by producing and consuming events. In AWS, this architecture leverages managed services to build scalable, reliable, and loosely coupled systems. It is also one of the strategies used in scaling AWS infrastructure in the following contexts:
<ul>
<li style="font-weight: 400;" aria-level="1">It can handle asynchronous communication between AWS services that are distributed across multiple servers and regions.</li>
<li style="font-weight: 400;" aria-level="1">Its main components are events generated by various sources, such as users, system components, and external components.</li>
<li style="font-weight: 400;" aria-level="1">It promotes loose service coupling and reduces dependencies across AWS resources without affecting the rest of the system. </li>
<li style="font-weight: 400;" aria-level="1">It supports high fault tolerance so that AWS resources can communicate asynchronously.</li>
</ul>
AWS several services: such as Lambda and Simple Queue Service (SQS), enable EDA events to trigger the execution of specific code.
<h3>SQS to implement loose coupling</h3>
SQS is a fully managed message queuing service that enables us to decouple and scale various microservices, serverless applications, and distributed systems within the AWS infrastructure. We can use SQS to decouple the system components so that they can work and scale independently. 
<h3>Leverage serverless architecture using Lambda</h3>
AWS Lambda is Amazon’s serverless computing service, enabling us to run code without provisioning any physical servers. The Lambda function can automatically scale our AWS-based applications by considering the incoming traffic, so we don’t need to consider capacity planning.

Scaling AWS Lambda happens by default. When you make multiple requests behind the scenes, Lambda automatically creates more instances of your function to handle your load. The scaling experience is seamless, as Lambda adjusts the number of instances based on the number of incoming events.
Lambda functions are very useful for real-time data processing and event-driven applications.

Some of the benefits of scaling your AWS infrastructure include:
<ul>
<li style="font-weight: 400;" aria-level="1">Improved performance and availability: Distributing workloads across multiple AWS instances or servers ensures all applications remain available.</li>
<li style="font-weight: 400;" aria-level="1">Cost optimization: Scaling allows us to use AWS resources more efficiently, avoiding overprovisioning of cloud resources. Learn more about <a href="https://spacelift.io/blog/aws-cost-optimization" target="_blank" rel="noopener">AWS Cost Optimization</a>.</li>
<li style="font-weight: 400;" aria-level="1">Increased flexibility: AWS provides enough capabilities to scale up or scale down the infrastructure to match the demand.</li>
<li style="font-weight: 400;" aria-level="1">Reduced downtime: Scaling ensures that all infrastructure components are up and running even during unexpected spikes in traffic, reducing the risk of service downtime and outages.</li>
<li style="font-weight: 400;" aria-level="1">Automatic scaling: AWS offers auto-scaling capabilities so that the infrastructure scales automatically based on predefined policies. </li>
<li style="font-weight: 400;" aria-level="1">Geographic scalability: AWS allows infrastructure scaling across different regions globally. Hence, we can deploy resources in multiple regions to reduce latency.</li>
</ul>

Does your organization have extra compliance concerns? Spacelift has you covered with the possibility of <a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">self-hosting it in AWS</a>. You can also <a href="https://docs.spacelift.io/integrations/cloud-providers/aws" target="_blank" rel="noopener">read about Spacelift integration with AWS</a>, with the new Cloud Integrations section and update to support account-level AWS integrations.

<a href="https://spacelift.io/blog/terraform-infrastructure-as-code" target="_blank" rel="noopener">Terraform IaC</a> enables us to create, change, and scale AWS infrastructure by defining resources with a loop using <a href="https://spacelift.io/blog/terraform-count-for-each" target="_blank" rel="noopener"><code>for_each</code> or <code>count</code></a>. 
Here&#8217;s a Terraform code example with which we can create multiple EC2 instances using <code>count</code>.

In the example above, the number of EC2 instances to be created can be declaratively mentioned using the count attribute. Creating an input variable to adjust this number helps update the number of instances dynamically.
Similarly, we can also use <code>for_each</code> construct to create multiple resources with similar configurations dynamically.
The example below implements an input variable “bucket_names” along with a <code>for_each</code> attribute to create multiple <a href="https://spacelift.io/blog/terraform-aws-s3-bucket" target="_blank" rel="noopener">S3 buckets</a>.

Learn more about <a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener">best practices when managing Terraform at scale</a>.

The <a href="https://spacelift.io/blog/kubernetes-cheat-sheet" target="_blank" rel="noopener">kubectl CLI</a>, Kubernetes dashboard, and Kubernetes API are some of the most commonly used tools for scaling Kubernetes clusters to manage varying demands.
Scaling a Kubernetes cluster using these tools requires monitoring to identify changes in demand and act accordingly. <a href="https://spacelift.io/blog/kubernetes-hpa-horizontal-pod-autoscaler" target="_blank" rel="noopener">Horizontal Pod Autoscaler (HPA)</a> helps automatically perform Kubernetes cluster scaling tasks. However, it is not a continuous process and needs to be scheduled, making it difficult to scale the pods accurately.
Auto scalers worth considering include <a href="https://spacelift.io/blog/karpenter-vs-cluster-autoscaler" target="_blank" rel="noopener">Cluster Autoscaler and Karpenter</a>.
<h3>Cluster Autoscaler</h3>
The Kubernetes Cluster Autoscaler is a Kubernetes deployment component that monitors demand, manages pod creation, and provides additional nodes for scaling purposes.
It monitors resource utilization and workload,  provisioning additional nodes to spin more pods if required and deprovisioning them when demand subsides. In this way, it adjusts cloud resources automatically for optimum cost benefits.
<h3>Karpenter</h3>
Karpenter is an open-source serverless auto-scaling solution for Kubernetes. It is designed to work natively with Kubernetes and all the major cloud providers, making it easy for organizations to adopt for running their workloads on Kubernetes.
Its automatic node-scaling capabilities enable organizations ​​to run their workloads cost-effectively, on demand. Karpenter uses Kubernetes API to manage nodes and workloads, making it easy to deploy and use.

<ol>
<li style="font-weight: 400;" aria-level="1">Leverage Auto Scaling: AWS Auto Scaling allows dynamic adjustments of resources like EC2 instances and ECS tasks based on demand. Use target tracking, step scaling, and predictive scaling policies to handle traffic variations while maintaining performance and cost efficiency.</li>
<li style="font-weight: 400;" aria-level="1">Design for stateless applications: Stateless applications store state externally in services like DynamoDB, S3, or ElastiCache. Combined with Elastic Load Balancers (ELB), this design enables seamless horizontal scaling by eliminating dependencies between application instances.</li>
<li style="font-weight: 400;" aria-level="1">Monitor and optimize resource utilization: AWS CloudWatch provides real-time insights into resource usage metrics, such as CPU and memory utilization. Tools like AWS Compute Optimizer and Cost Explorer help identify underutilized resources, ensuring cost-effective scaling.</li>
<li style="font-weight: 400;" aria-level="1">Adopt purpose-built databases and caching: Use workload-specific databases (e.g., DynamoDB for NoSQL or RDS for relational data) to optimize performance. Integrate Amazon ElastiCache for caching frequently accessed data to reduce database load and latency.</li>
<li style="font-weight: 400;" aria-level="1">Enable fault tolerance and high availability: Multi-AZ deployments for services like RDS and DynamoDB ensure high availability. Health checks in Auto Scaling groups and load balancers automatically detect and replace failed instances, maintaining application uptime.</li>
<li style="font-weight: 400;" aria-level="1">Adopt infrastructure as code (IaC): Tools like AWS CloudFormation, OpenTofu and Terraform allow you to define and manage infrastructure configurations as code. This ensures consistent, scalable, and reproducible deployments and simplifies updates and scaling adjustments.</li>
</ol>

Spacelift is an infrastructure orchestration platform that increases your infrastructure deployment speed without sacrificing control.
With Spacelift, you can provision, configure, and govern with one or more automated workflows that orchestrate Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes. 
You don’t need to define all the prerequisite steps for installing and configuring the infrastructure tool you are using, nor the deployment and security steps, as they are all available in the default workflow.
Spacelift offers a unique set of infrastructure orchestration capabilities, such as:
<ul>
<li style="font-weight: 400;" aria-level="1">Policies (based on Open Policy Agent) — You can control how many approvals you need for runs, the kind of resources you can create, and the kind of parameters these resources can have, and you can also control the behavior when a pull request is open or merged.</li>
<li style="font-weight: 400;" aria-level="1">Multi-IaC workflows — Combine Terraform with Kubernetes, Ansible, and other IaC tools such as OpenTofu, Pulumi, and CloudFormation, create dependencies among them, and share outputs</li>
<li style="font-weight: 400;" aria-level="1">Build self-service infrastructure — You can use <a href="https://docs.spacelift.io/concepts/blueprint/" target="_blank" rel="noopener">Blueprints</a> to build self-service infrastructure; simply complete a form to provision infrastructure based on Terraform and other supported tools.</li>
<li style="font-weight: 400;" aria-level="1">Integrations with any third-party tools — You can integrate with your favorite third-party tools and even build policies for them. For example, you can <a href="https://spacelift.io/blog/integrating-security-tools-with-spacelift" target="_blank" rel="noopener">Integrate security tools</a> in your workflows using Custom Inputs.</li>
<li style="font-weight: 400;" aria-level="1">Drift detection and remediation</li>
</ul>
Spacelift enables you to create private workers inside your infrastructure, which helps you execute Spacelift-related workflows on your end. The <a href="https://docs.spacelift.io/concepts/worker-pools">documentation</a> provides more information on configuring private workers.
Check out this video where we explore the issues related to managing IaC at scale:

managing-iac-at-scale-youtube

Managing IaC at Scale youtube

If you want to learn more about what you can do with Spacelift, check out this <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">article, </a><a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">create a free account today,</a> or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo with one of our engineers</a>.

Scaling AWS infrastructure is essential to ensure that web applications, servers, and databases can handle increased traffic and workload demands. By analyzing the infrastructure and leveraging AWS services like Aurora, CloudWatch, and Autoscaling Groups, we can effectively scale our web servers and databases. 
Additionally, event-driven architecture and serverless technologies such as Lambda Function and SQS can help us implement loose coupling and improve scalability. We can leverage Terraform’s for_each/count loops to dynamically create or destroy multiple resources. In this post, we also discussed how Karpenter and AWS Cluster Autoscaler automate the scaling of AWS infrastructure.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation, and controls to simplify and accelerate the provisioning of cloud-based infrastructures.

Building a Scalable Infrastructure: Strategies & Best Practices

How to Build on AWS with CDK for Terraform (CDKTF)

How to Use AWS for Infrastructure as Code (IaC)

Learn how to scale your AWS infrastructure with services like AWS Auto Scaling and more. Horizontal vs. vertical scaling explained.

207-scaling-aws

How To Scale Your AWS Infrastructure

Scaling AWS Infrastructure: Auto Scaling & Other Services

AWS Cost optimization - best practices and tools

Cloud adoption is a de facto standard today. Key reasons for this are convenience, the facility to scale up and scale down resources on demand, and the ability to pay only for the resources you consume.
Although cloud computing has many benefits, enterprises sometimes end up paying more for their services due to a lack of appropriate planning, architecture, and optimization and improper monitoring of resource consumption.
In this post, we explore AWS cost optimization strategies and best practices for cost-efficient utilization of cloud resources.
We will cover:
<ol>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#overview-of-cloud-pricing-models">Overview of cloud pricing models</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#general-cloud-cost-optimization-strategies">General cloud cost optimization strategies</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#aws-design-principles-for-cost-optimization">AWS design principles for cost optimization</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#practical-tips-for-aws-cost-optimization">Practical tips for cost optimization</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#best-practices-for-aws-cost-optimization">Cost optimization best practices</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/aws-cost-optimization#aws-cost-management-tools">AWS cost management tools</a></li>
</ol>

In general, IAAS cloud pricing models are based on three fundamental aspects — compute, storage/database, and network utilization. For example, AWS varies its services to optimize costs based on business needs.
<ol>
<li style="font-weight: 400;" aria-level="1">Compute:  AWS offers Amazon Elastic Compute Cloud (EC2), Amazon Container Services (ECS), Amazon Kubernetes Services (EKS), AWS lambda, etc. Attributes like availability, managed/shared/dedicated tenancy, and workload nature differ for each of these services., potentially affecting costs.
<ul>
<li style="font-weight: 400;" aria-level="2">Example compute cost calculation: $ per seconds /minutes/hours/…/days</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">Storage/databases: AWS offers Amazon Simple Storage Service (S3), Amazon Elastic Block Storage (EBS),  Amazon Elastic File System (EFS), Amazon Glacier, etc., as storage solutions. Database services include Amazon RDS, Amazon DynamoDB, Aurora, etc. This flexibility allows customers to move data to less frequently accessed storage classes to save costs.
<ul>
<li style="font-weight: 400;" aria-level="2">Example storage/database cost calculation: $ per Mb/Gb/Tb</li>
</ul>
</li>
<li style="font-weight: 400;" aria-level="1">Network: Costs associated with network bandwidth consumption mainly depend on two aspects — the speed of the connection and the amount of data transferred (inbound/outbound).
<ul>
<li style="font-weight: 400;" aria-level="2">Example network consumption cost calculation: $ per data transfer/ No. of API requests</li>
</ul>
</li>
</ol>
The examples above provide a high-level overview of how cost calculations are made based on the three core infrastructure components.
Each service is associated with a complex pricing model, making it difficult to arrive at a final figure for the costs associated with any given cloud architecture.
Thankfully, AWS provides a <a href="https://calculator.aws/#/" target="_blank" rel="nofollow noopener">pricing calculator</a> to create estimates for each service depending on the customization options chosen.

Effectively managing cloud costs doesn’t just save money — it ensures your infrastructure runs efficiently. A robust cloud cost optimization strategy typically revolves around four main pillars:
<ol>
<li>Right-sizing resources: Adjust resources to perfectly match your workload needs.</li>
</ol>
<ul>
<li style="list-style-type: none;">
<ul>
<li style="font-weight: 400;" aria-level="2">Ensure that cloud resources including virtual machines, storage, and databases are appropriately sized to meet current needs.</li>
<li style="font-weight: 400;" aria-level="2">Analyze usage patterns and adjust resources to avoid over-provisioning or under-utilization.</li>
<li style="font-weight: 400;" aria-level="2">Scale resources dynamically to match workload requirements.</li>
</ul>
</li>
</ul>
<ol start="2">
<li>Optimizing storage: Use the right type of storage for your data and regularly review unused or infrequently accessed files.</li>
</ol>
<ul>
<li style="list-style-type: none;">
<ul>
<li style="font-weight: 400;" aria-level="2">Use tiered storage to manage costs (e.g., move infrequently accessed data to cheaper storage tiers).</li>
<li style="font-weight: 400;" aria-level="2">Compress and deduplicate data to save space and cost.</li>
<li style="font-weight: 400;" aria-level="2">Clean up unused or redundant data regularly.</li>
<li style="font-weight: 400;" aria-level="2">Leverage lifecycle policies for automated storage transitions.</li>
</ul>
</li>
</ul>
<ol start="3">
<li>Leveraging reserved instances and savings plans: Commit to long-term resource use for lower rates.</li>
</ol>
<ul>
<li style="list-style-type: none;">
<ul>
<li style="font-weight: 400;" aria-level="2">Evaluate your consistent workloads to determine eligibility.</li>
<li style="font-weight: 400;" aria-level="2">Choose the right Savings Plan or Reserved Instance model (e.g., 1-year, 3-year plans).</li>
<li style="font-weight: 400;" aria-level="2">Balance commitments with flexibility to adapt to future needs.</li>
</ul>
</li>
</ul>
<ol start="4">
<li>Monitoring and automation: Continuously track usage and automate optimizations.</li>
</ol>
<ul>
<li style="list-style-type: none;">
<ul>
<li style="font-weight: 400;" aria-level="2">Monitor resource usage and expenses with tools like AWS Cost Explorer, Azure Cost Management, or Google Cloud Cost Management.</li>
<li style="font-weight: 400;" aria-level="2">Automate policies to turn off idle resources and scale workloads during off-peak times.</li>
<li style="font-weight: 400;" aria-level="2">Use cost anomaly alerts to detect and address overspending quickly.</li>
</ul>
</li>
</ul>
Note that this is not an exhaustive list of principles but a suggested approach for <a href="https://spacelift.io/blog/cloud-cost-optimization" target="_blank" rel="noopener">cloud cost optimization</a>.

Cost optimization in Amazon Web Services (AWS) involves strategies and practices aimed at reducing your cloud spending while maintaining performance and functionality. It ensures that you only pay for what you use and that your cloud infrastructure is cost-efficient. AWS provides tools, services, and best practices to help achieve cost optimization.
&nbsp;
AWS cost optimization supports sustainable growth and maximizes the value of your cloud investment. By rightsizing instances and leveraging tools like Reserved Instances or Savings Plans, you can significantly reduce costs while maintaining performance.

AWS’ well-architected framework provides a set of best practices and guidelines for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. Cost optimization is one of the five pillars of this framework. It aims to achieve the desired outcomes with justified costs.
In this section, we discuss design principles that guide us in optimizing costs.
<ol>
<li style="font-weight: 400;" aria-level="1">Monitor resource consumption</li>
<li style="font-weight: 400;" aria-level="1">Adopt a consumption-based pricing model</li>
<li style="font-weight: 400;" aria-level="1">Use the right compute instances</li>
<li style="font-weight: 400;" aria-level="1">Use the right storage classes</li>
<li style="font-weight: 400;" aria-level="1">Leverage AWS Cost Explorer for analysis</li>
</ol>
<h3>1. Monitor resource consumption</h3>
Tracking and monitoring always precede optimization efforts. Monitoring provides context and understanding for why certain costs need to be optimized, shedding light on overspending. Several tools provided by AWS and other third-party services help uncover unnecessary expenditures:
<ol>
<li style="font-weight: 400;" aria-level="1">CloudWatch Metrics provides various metrics and the ability to set alarms when a certain threshold is met. With CloudWatch Metrics, we monitor compute resource consumption, database storage capacities, and various other metrics.</li>
<li style="font-weight: 400;" aria-level="1">AWS Cost Explorer provides a detailed analysis of cloud spend by service.</li>
<li style="font-weight: 400;" aria-level="1">Third-party tools that monitor AWS cloud costs provide reporting on cloud resource consumption and price associated with it.</li>
</ol>
Read more: <a href="https://spacelift.io/blog/aws-monitoring-tools" target="_blank" rel="noopener">Top 19 AWS Monitoring Tools &amp; 8 Best Practices</a>
<h3>2. Adopt a consumption-based pricing model</h3>
Instead of reserving resources to serve uneven or occasional traffic, adopt consumption-based resource allocation by leveraging auto-scaling capabilities. This helps reduce costs by avoiding overprovisioning of resources and paying for unused resources.
Cloud-native services are better at supporting cost optimization and finer control over cloud resource utilization.
For example, AWS Fargate or Lambda functions create additional compute instances only when they are needed and in a quicker way than EC2 instances. 
<h3>3. Use the right compute instances</h3>
It is possible to classify workloads as critical and non-critical. Provisioning compute instances with general configuration on shared resources for less critical workloads may make sense. Limiting the provisioning of dedicated servers to critical workloads only helps optimize costs.
The steps to identify and provision appropriate compute resources based on utilization and criticality are summarized below:
<ol>
<li style="font-weight: 400;" aria-level="1">Analyze the resource usage with AWS CloudWatch to identify which resources are underutilized.</li>
<li style="font-weight: 400;" aria-level="1">Identify optimal resource levels that will suffice your business needs.</li>
<li style="font-weight: 400;" aria-level="1">Resize resources either by modifying resources or adjusting the number of running instances.</li>
<li style="font-weight: 400;" aria-level="1">Automate the above process to maintain the right sizing of the resources. </li>
</ol>
The table below summarizes various types of EC2 instances and associated features.

<table>
<tbody>
<tr>
<td>Type</td>
<td>Description</td>
<td>Price</td>
<td>When to use</td>
</tr>
<tr>
<td>On-demand Instances</td>
<td>Pay for the compute capacity only when the instance is running.</td>
<td>$$$$ </td>
<td>Dev, Test, and Prod Environments;
Critical/Real-time business</td>
</tr>
<tr>
<td>Reserved instances</td>
<td>Pay for the compute with the discount because you commit to  one or three years’ usage, for example.</td>
<td>$$$</td>
<td>Prod Environments
Critical/Real-time business</td>
</tr>
<tr>
<td>Spot instances</td>
<td>Bid for the unused compute capacity of the AWS.</td>
<td>$$</td>
<td>Workload processing is flexible, has no critical time deadline, and can handle interruptions.</td>
</tr>
<tr>
<td>Dedicated hosts</td>
<td>Pay for dedicated physical servers to run instances. You control physical server.</td>
<td>$$$$$$  </td>
<td>Applications with licensing requirements.
To meet compliance requirements.
Need control over the underlying hardware.
Security requirements.</td>
</tr>
<tr>
<td>Dedicated instances</td>
<td>Run the instances on the dedicated physical server. You don’t control the underlying physical server.</td>
<td>$$$$$</td>
<td>Applications with licensing requirements.
To meet compliance requirements.
Security requirements.</td>
</tr>
</tbody>
</table>

Additionally, choosing Amazon’s Savings plan on EC2 can give you significant cost savings (72%) in exchange for a commitment of one to three years.
<h3>4. Use the right storage classes</h3>
AWS EC2 instances often use Elastic Block Storage (EBS) to persist data. Pricing of volumes usually depends on the size and type of EBS volumes. EBS pricing depends on performance characteristics, size, I/O, region, etc. The table below summarizes various types of EBS volumes along with the use case.

<table>
<tbody>
<tr>
<td>EBS type</td>
<td>Description</td>
<td>Price</td>
<td>When to use</td>
</tr>
<tr>
<td>General purpose SSD</td>
<td>This is the default volume provided to AWS EC2. It has high performance (IOPS) because it is an SSD drive.</td>
<td>$$$</td>
<td>Workloads that require a balance of price and performance. Can be used in boot volumes or small and mid-sized databases</td>
</tr>
<tr>
<td>Provisioned IOPS SSD</td>
<td>This has the highest performance and most expensive SSD drive.</td>
<td>$$$$</td>
<td>High-performance workloads where you need very low latency and very high throughputs,e.g., heavy transactional databases and high-performance computing</td>
</tr>
<tr>
<td>Throughput Optimized HDD</td>
<td>This is a regular HDD with a lower cost compared with SSD drives but is specially designed for throughput-intensive workloads.</td>
<td>$$</td>
<td>Sequential workloads such as ETL, data warehouses, log processing, and data analytics where you need high throughput</td>
</tr>
<tr>
<td>Cold HDD</td>
<td>This is the lowest-cost HDD for less frequently accessed workloads.</td>
<td>$  </td>
<td>Infrequent access workloads, such as backups, disaster recovery, and long-term archival storage</td>
</tr>
</tbody>
</table>

Similarly, various classes of S3 storage offer lower prices by compromising on aspects like availability, redundancy, and retrieval of historical data. Depending on consumption patterns, data can be moved to colder storage solutions, which, in turn, reduces storage costs over time.
<h3>5. Leverage AWS Cost Explorer for analysis</h3>
AWS Cost Explorer is a cost analysis tool that displays cost division based on service in a granular and detailed manner. Use Cost Explorer to track spending over time and identify areas for cost optimization.
Generate custom reports to provide insights into cost drivers, usage patterns, and trends. As a best practice, it is always suggested to use tags while provisioning various cloud resources for billing purposes. Cost Explorer is a tool that culminates those tagging efforts into meaningful reports and actions.

AWS can be expensive because its pricing is based on a model that charges for actual resource usage, which can quickly scale up with high workloads or inefficient configurations. Many services have complex pricing structures, and unexpected costs can arise from data transfer, storage, or underutilized resources. Implementing cost optimization strategies like right-sizing resources, leveraging reserved instances, and monitoring usage can help control and reduce AWS costs.

This section includes tips for optimizing costs for some commonly used services.
<h3>Optimizing AWS S3 cost</h3>
Amazon S3 is an object storage service that facilitates use cases like data backup and restore, data archival, data lake, and other enterprise application storage. S3 stores data in buckets similar to the directories in your local system. The actual data you store in S3 as a fundamental unit is called an object, which is similar to files. 
Storage classes are one of the primary determinants of Amazon S3 pricing. Each object is associated with a storage class. It is important to identify which storage class should be assigned to the object.

<table>
<tbody>
<tr>
<td>Storage class</td>
<td>Description</td>
<td>Price</td>
<td>When to use</td>
</tr>
<tr>
<td>S3 standard</td>
<td>This is a general-purpose, default storage class.</td>
<td>$$$$$$$  </td>
<td>Very frequent access to the data is needed with low latency and high durability</td>
</tr>
<tr>
<td>S3 standard-IA</td>
<td>Use this when you need infrequent access to the objects, but when accessed, it needs the same low latency and high throughput as S3 standard.
It is up to 48% cheaperthan S3 Standard.</td>
<td>$$$$</td>
<td>TBD</td>
</tr>
<tr>
<td>S3 One zone- IA</td>
<td>This is the same as S3-IA but it stores data in 1 availability zone.
It costs up to 20% lless  than Standard-IA.</td>
<td>$$$$$</td>
<td>Data that is infrequently accessed and does not need availability and resiliency.</td>
</tr>
<tr>
<td>S3 Intelligent -tiering</td>
<td>This monitors your data access patterns and moves the objects in the different tiers.
<ol>
<li style="font-weight: 400;" aria-level="1">If frequently accessed -&gt; S3 Standard</li>
<li style="font-weight: 400;" aria-level="1">If not accessed consecutively for 30 days -&gt; S3-IA</li>
<li style="font-weight: 400;" aria-level="1">If not accessed consecutively 
90 days -&gt; S3 Glacier Instant Retrieval</li>
<li style="font-weight: 400;" aria-level="1">If not accessed consecutively 180 days -&gt; S3 Glacier Deep Archival</li>
</ol>
</td>
<td>$$$$</td>
<td>For unpredictable data access patterns when cost optimization is preferable toadding all the data to S3 standard.</td>
</tr>
<tr>
<td>S3 Glacier Instant retrieval</td>
<td>This is up to 68% cheaper than S3-IA.</td>
<td>$$$</td>
<td>For archival of long-term data that is rarely accessed but requires retrieval in milliseconds.</td>
</tr>
<tr>
<td>S3 Glacier Flexible retrieval</td>
<td>This is up to 10% cheaper than S3 Glacier Instant Retrieval.</td>
<td>$$</td>
<td>Hard data is accessed once or twice a year but requires retrieval in minutes and hours.</td>
</tr>
<tr>
<td>S3 Glacier Deep Archive</td>
<td>This is the cheapest storage class. You can store data as digital preservation for almost 7-10 years. Data from this class takes almost 12 hours to retrieve.</td>
<td>$</td>
<td>Accessed once or twice a year
Need to store the data for a very long-term retention policy.</td>
</tr>
</tbody>
</table>

If you’re unsure about the data access pattern and volume of the data, then use either S3 analytics or S3 storage lens to get insights into the usage. This will help you identify the data that should be in a particular storage class and when.
You can also leverage the S3 lifecycle rules to automatically transition your data based on these insights.
<h3>Optimizing Amazon EBS cost</h3>
Here are some practical tips for optimizing EBS usage:
<ol>
<li style="font-weight: 400;" aria-level="1">Unattached volumes – After terminating EC2 instances, you might not need their attached volumes. Unattached volumes incur the same cost as those attached to an EC2 instance. Best practice is to take the volume’s backup as a snapshot and then remove the volume. </li>
<li style="font-weight: 400;" aria-level="1">Snapshot policies — If the EBS volume is hosting a database, it creates many incremental snapshots. These snapshots may incur substantial AWS S3 costs. Instead, implement a retention policy for deleting the older snapshots to save S3 costs.</li>
</ol>
<h3>Optimizing data transfer charges</h3>
AWS services like Amazon EC2, Amazon RDS, and Amazon S3 do not offer free inbound data transfer. However, outbound data transfer is chargeable. Always monitor the amount of data transferred from these resources to the public internet and limit it where it makes sense.
If the outbound data is static and repetitive, consider using Amazon CloudFront. This is a CDN service designed for caching and serving static content, reducing outbound costs compared with EC2 machines.
AWS also charges for data transfer between regions and availability zones. These are important considerations when designing and architecting systems to be deployed in the cloud.
<h3>Optimizing RDS costs</h3>
AWS RDS costs are optimized based on factors including:
<ol>
<li style="font-weight: 400;" aria-level="1">Right-sizing the instance by choosing appropriate CPU, memory, and storage requirements</li>
<li style="font-weight: 400;" aria-level="1">Using read replicas helps offload read traffic from primary database instances.</li>
<li style="font-weight: 400;" aria-level="1">Writing efficient queries and improving database schemas also help in the processing and retrieval of data sets</li>
<li style="font-weight: 400;" aria-level="1">Using reserved instances to get discounts wherever possible</li>
<li style="font-weight: 400;" aria-level="1">Using database engine features appropriately, like backups, AZ, and read replicas</li>
</ol>

<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">SaaS not an Option? Install Spacelift Self-Hosted on AWS</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/devops-best-practices" target="_blank" rel="noopener">16 DevOps Best Practices to Follow</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Infrastructure Drift Detection and How to Fix It</a></li>
</ul>

<h3>Optimizing DynamoDB costs</h3>
AWS DynamoDB costs can be optimized based on factors including: 
<ol>
<li style="font-weight: 400;" aria-level="1">Choosing the appropriate capacity (On-demand or provisioned, or reserved capacity)</li>
<li style="font-weight: 400;" aria-level="1">Choosing the right table class (Standard or Standard infrequent access)</li>
<li style="font-weight: 400;" aria-level="1">Using the TLL feature to automatically delete expired data</li>
<li style="font-weight: 400;" aria-level="1">Reviewing secondary index usage and deleting any unused or unnecessary indexes</li>
<li style="font-weight: 400;" aria-level="1">Reviewing backup retention periods</li>
</ol>
<h3>Adopting IaC</h3>
<a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as code (IaC)</a> is a way to manage and provision resources using code. <a href="https://spacelift.io/blog/terraform-infrastructure-as-code" target="_blank" rel="noopener">Terraform</a>, <a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi</a>, and AWS CDK are some examples of IAC. Adopting IAC for managing cloud resources will have several benefits, some of which are outlined below:
<ol>
<li style="font-weight: 400;" aria-level="1">IaC enables you to automate the provisioning, configuration, and management of our resources. This automation can help you reduce the time and effort required to manage your infrastructure, reducing costs..</li>
<li style="font-weight: 400;" aria-level="1">IaC enables versioning of infrastructure.</li>
<li style="font-weight: 400;" aria-level="1">Use templates to standardize. Ensure that infrastructure is consistent across environments to reduce errors and increase efficiency.</li>
</ol>
<h3>Leveraging serverless architecture</h3>
Serverless architecture allows applications to run while the cloud provider manages the underlying infrastructure. AWS cloud services typically used in serverless designs are AWS Lambda, AWS API gateway, AWS DynamoDB, AWS SNS, AWS step functions, AWS S3, and AWS Cognito.
Leveraging serverless reduces operational costs. Furthermore, you are charged only as long as it takes for your code to execute, providing a more cost-effective pricing model than paying for idle instances or containers.
However, serverless is not always a superior alternative to using EC2 instances or containers. It requires you to rethink your infrastructure and redesign solutions.

These best practices enable you to reduce your AWS costs while maintaining optimal performance and scalability:
<ol>
<li style="font-weight: 400;" aria-level="1">Identify the type of EC2 instance based on the requirement. Provision reserved instances for production (or sub-production) environments.</li>
<li style="font-weight: 400;" aria-level="1">Opt for the AWS savings plan, which also provides great discounts (72%) on Amazon EC2, Amazon Fargate, and Amazon Lambda.</li>
<li style="font-weight: 400;" aria-level="1">Shutting down or terminating, dev, and testing EC2 machines when not in use (after working hours and on weekends).</li>
<li style="font-weight: 400;" aria-level="1">Automate right-sizing of resources by leveraging auto-scaling and CloudWatch events.</li>
<li style="font-weight: 400;" aria-level="1">Use appropriate S3 storage classes for the objects. Use S3 lifecycle rules to transition the rarely accessed data to lower-cost tiers.</li>
<li style="font-weight: 400;" aria-level="1">Delete very old snapshots of the EBS. You should have the lifecycle for snapshots.</li>
<li style="font-weight: 400;" aria-level="1">Always destroy unattached EBS volumes. Take snapshots before destroying them.</li>
<li style="font-weight: 400;" aria-level="1">Release unattached elastic IP addresses after terminating EC2 instances.</li>
<li style="font-weight: 400;" aria-level="1">Make cloud optimization part of your DevOps lifecycle.</li>
<li style="font-weight: 400;" aria-level="1">Use serverless solutions for low-traffic applications and short tasks.</li>
<li style="font-weight: 400;" aria-level="1">Avoid data transfer between AZs and regions. Keep services in the same region and AZ.</li>
<li style="font-weight: 400;" aria-level="1">Provision Amazon CloudFront distributions for repetitive and static outbound data.</li>
</ol>

These tools are used for cost optimization of AWS resources:
<ol>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/premiumsupport/technology/trusted-advisor/" target="_blank" rel="nofollow noopener">AWS Trusted Advisor</a> – a web-based service provided by AWS that offers real-time guidance to help you optimize your AWS environment according to AWS best practices. It evaluates the AWS account and provides a way to optimize infrastructure, improve security, reduce costs, and monitor service quotas.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/" target="_blank" rel="nofollow noopener">AWS Cost Anomaly Detection</a> – a feature within the AWS Cost Management suite that utilizes machine learning to monitor and identify unexpected increases in your AWS spending. It can identify unusual spending trends and their underlying causes, empowering teams to respond promptly.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/aws-cost-management/aws-cost-explorer/" target="_blank" rel="nofollow noopener">AWS Cost Explorer</a> – a user-friendly tool that allows you to visualize, understand, and manage your AWS costs and usage over time. It provides an interactive dashboard to visualize and manage AWS resources, enabling users to view, analyze, and optimize infrastructure for cost and usage.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/compute-optimizer/" target="_blank" rel="nofollow noopener">AWS Compute Optimizer</a> – a service that leverages machine learning to analyze the configuration and utilization metrics of your AWS resources, such as Amazon EC2 instances, Auto Scaling groups, Amazon EBS volumes, AWS Lambda functions, and Amazon ECS services on AWS Fargate. It provides recommendations to optimize resource usage based on historical usage patterns.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://calculator.aws/#/" target="_blank" rel="nofollow noopener">AWS Pricing Calculator</a> – a free, web-based tool that enables you to estimate the costs of AWS services for your planned use cases by specifying the service information in detail.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/autoscaling/" target="_blank" rel="nofollow noopener">AWS Auto Scaling</a> – a service that monitors your applications and automatically adjusts capacity to maintain steady, predictable performance at the lowest possible cost. It allows you to automatically adjust the capacity of AWS resources based on the demand of your application providing cost optimization opportunities.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://aws.amazon.com/cloudwatch/" target="_blank" rel="nofollow noopener">AWS CloudWatch</a> – a monitoring and observability service that captures and presents real-time logs, metrics, and event data on automated dashboards to optimize infrastructure and application management.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://github.com/alexcasalboni/aws-lambda-power-tuning" target="_blank" rel="nofollow noopener">AWS Lambda Power Tuning</a> &#8211; an open-source tool designed to help you visualize and fine-tune the memory and power configurations of your AWS Lambda functions. It helps optimize the performance and cost-effectiveness of AWS Lambda functions by using machine learning to analyze and optimize a Lambda function’s configuration parameters, such as memory allocation, timeout settings, and concurrency levels.</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/terraform-cost-estimation-using-infracost" target="_blank" rel="nofollow noopener">Infracost</a> – a third-party open-source tool that provides cloud cost estimates for infrastructure as code (IaC) projects, particularly those using Terraform. This is a key insight from the cost optimization perspective. <a href="https://docs.spacelift.io/vendors/terraform/infracost.html" target="_blank" rel="noopener">It is integrated with Spacelift</a> and is available in the free tier!</li>
</ol>

<a href="https://spacelift.io/how-it-works" target="_blank" rel="noopener">Spacelift</a> is an infrastructure orchestration platform that increases your infrastructure deployment speed without sacrificing control. With Spacelift, you can provision, configure, and govern with one or more automated workflows that orchestrate Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes. 
You don’t need to define all the prerequisite steps for installing and configuring the infrastructure tool you are using, nor the deployment and security steps, as they are all available in the default workflow.

orbica-blog-banner

With Spacelift, you get:
<ul>
<li style="font-weight: 400;" aria-level="1">Integration with <a href="https://docs.spacelift.io/vendors/terraform/infracost.html" target="_blank" rel="noopener">Infracost</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/policy" target="_blank" rel="noopener">Policies</a> to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/stack-dependencies.html" target="_blank" rel="noopener">Stack dependencies</a> to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your EC2 instances using Terraform and combines it with Ansible to configure them</li>
<li style="font-weight: 400;" aria-level="1">Self-service infrastructure via <a href="https://docs.spacelift.io/concepts/blueprint.html" target="_blank" rel="noopener">Blueprints</a>, enabling your developers to do what matters – developing application code while not sacrificing control</li>
<li style="font-weight: 400;" aria-level="1">Creature comforts such as <a href="https://docs.spacelift.io/concepts/configuration/context.html" target="_blank" rel="noopener">contexts</a> (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code</li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.spacelift.io/concepts/stack/drift-detection.html" target="_blank" rel="noopener">Drift detection</a> and optional remediation</li>
</ul>
Spacelift was built with DevOps/platform engineers in mind, but it developed to become the go-to platform for software engineers, too, because they can increase their velocity with self-service infrastructure that implements all your organization’s guardrails. It greatly enhances collaboration among engineers, offering them a central location to make infrastructure-related decisions.
If you want to learn more about what you can do with Spacelift, check out this <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">article</a>.
Does your organization have extra compliance concerns? Here you can <a href="https://spacelift.io/blog/introducing-spacelift-self-hosted" target="_blank" rel="noopener">learn more about self-hosting Spacelift in AWS</a>, to ensure your organization’s compliance, control ingress, egress, internal traffic, and certificates, and have the flexibility to run it within GovCloud.

Enterprises are concerned about spending excessively on AWS resources. In this post, we covered various scenarios and discussed various approaches for limiting expenditure on AWS by leveraging the flexibility of resource consumption and associated pricing that AWS provides.
We also explored some of the best practices and AWS cost optimization tools that help with cloud cost management. The points we discussed are not exhaustive, and every organization&#8217;s use cases differ vastly. It is important to observe these principles continuously to optimize infrastructure costs.
If you are interested in a product that can orchestrate provisioning, configuration, and governance, across your infrastructure, Spacelift is the answer. <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">Create a free account</a> with Spacelift today, or <a href="https://spacelift.io/schedule-demo" target="_blank" rel="noopener">book a demo</a> with one of our engineers.

Explore AWS cost optimization strategies and principles. Discover best practices for AWS cost reduction and efficient usage of cloud resources.

What is AWS STS – Security Token Service?

Get the newsletter

Recent posts

Scaling AWS Infrastructure: Auto Scaling & Other Services

AWS Cost Optimization: Strategies, Best Practices, and Tools

AWS IAM Roles – Everything You Need to Know & Examples

AWS IAM Policies : Creating an IAM Policy & Best Practices