February 20, 2025

Blog NivelEpsilon

The easy way to persistent storage in ECS Fargate

Running containers in ECS Fargate is great until you need persistent storage. At first, it seems straightforward: mount an EFS volume, and you’re done. But then you hit a roadblock. The container fails to start because the expected directory in EFS doesn’t exist.

What do you do? You could manually create the directory from an EC2 instance, but that’s not scalable. You could try scripting something, but now you’re adding complexity. That’s where I found myself, going down the wrong path before realizing that AWS already had a built-in solution that simplified everything. Let’s walk through what I learned.

The problem with persistent storage in ECS Fargate

When you define a task in ECS Fargate, you specify a TaskDefinition. This includes your container settings, environment variables, and any volumes you want to mount. The idea is simple: attach an EFS volume and mount it inside the container.

But there’s a catch. The task won’t start if the mount path inside EFS doesn’t already exist. So if your container expects to write to /data, and you set it up to map to /my-task/data on EFS, you’ll get an error if /my-task/data hasn’t been created yet.

At first, I thought, Fine, I’ll just SSH into an EC2 instance, mount the EFS drive, and create the folder manually. That worked. But then I realized something: what happens when I need to deploy multiple environments dynamically? Manually creating directories every time was not an option.

A Lambda function as a workaround

My next idea was to automate the directory creation using a Lambda function. Here’s how it worked:

The Lambda function mounts the root of the EFS volume.
It creates the required directory (/my-task/data).
The ECS task waits for the directory to exist before starting.

To integrate this, I created a custom resource in AWS CloudFormation that triggered the Lambda function whenever I deployed the stack. The function ran, created the directory, and ensured everything was in place before the container started.

It worked. The container launched successfully, and I automated the setup. But something still felt off. I had just introduced an entirely new AWS service, Lambda, to solve what seemed like a simple storage issue. More moving parts mean more maintenance, more security considerations, and more things that can break.

The simpler solution with EFS Access Points

While working on the Lambda function, I stumbled upon EFS Access Points. I needed one to allow Lambda to mount EFS, but then I realized something, ECS Fargate supports EFS Access Points too.

Here’s why that’s important. Access Points in EFS let you:
✔ Automatically create a directory when it’s first used.
✔ Restrict access to specific paths and users.
✔ Set permissions so the container only sees the directory it needs.

Instead of manually creating directories or relying on Lambda, I set up an Access Point for /my-task/data and configured my ECS TaskDefinition to use it. That’s it, no extra code, no custom logic, just a built-in feature that solved the problem cleanly.

The key takeaway

My first instinct was to write more code. A Lambda function, a CloudFormation resource, and extra logic, all to create a folder. But the right answer was much simpler: use the tools AWS already provides.

The lesson? When working with cloud infrastructure, resist the urge to overcomplicate things. The easiest solution is often the best one. If you ever find yourself scripting something that feels like it should be built-in, take a step back because it probably is.

Secure and simplify EC2 access with AWS Session Manager

Accessing EC2 instances used to be a hassle. Bastion hosts, SSH keys, firewall rules, each piece added another layer of complexity and potential security risks. You had to open ports, distribute keys, and constantly manage access. It felt like setting up an intricate vault just to perform simple administrative tasks.

AWS Session Manager changes the game entirely. No exposed ports, no key distribution nightmares, and a complete audit trail of every session. Think of it as replacing traditional keys and doors with a secure, on-demand teleportation system, one that logs everything.

How AWS Session Manager works

Session Manager is part of AWS Systems Manager, a fully managed service that provides secure, browser-based, and CLI-based access to EC2 instances without needing SSH or RDP. Here’s how it works:

An SSM Agent runs on the instance and communicates outbound to AWS Systems Manager.
When you start a session, AWS verifies your identity and permissions using IAM.
Once authorized, a secure channel is created between your local machine and the instance, without opening any inbound ports.

This approach significantly reduces the attack surface. There is no need to open port 22 (SSH) or 3389 (RDP) for bastion hosts. Moreover, since authentication and authorization are managed by IAM policies, you no longer have to distribute or rotate SSH keys.

Setting up AWS Session Manager

Getting started with Session Manager is straightforward. Here’s a step-by-step guide:

1. Ensure the SSM agent is installed

Most modern Amazon Machine Images (AMIs) come with the SSM Agent pre-installed. If yours doesn’t, install it manually using the following command (for Amazon Linux, Ubuntu, or RHEL):

sudo yum install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

2. Create an IAM Role for EC2

Your EC2 instance needs an IAM role to communicate with AWS Systems Manager. Attach a policy that grants at least the following permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:StartSession"
      ],
      "Resource": [
        "arn:aws:ec2:REGION:ACCOUNT_ID:instance/INSTANCE_ID"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": [
        "arn:aws:ssm:REGION:ACCOUNT_ID:session/${aws:username}-*"
      ]
    }
  ]
}

Replace REGION, ACCOUNT_ID, and INSTANCE_ID with your actual values. For best security practices, apply the principle of least privilege by restricting access to specific instances or tags.

3. Connect to your instance

Once the IAM role is attached, you’re ready to connect.

From the AWS Console: Navigate to EC2 > Instances, select your instance, click Connect, and choose Session Manager.

From the AWS CLI: Run:

aws ssm start-session --target i-xxxxxxxxxxxxxxxxx

That’s it, no SSH keys, no VPNs, no open ports.

Built-in security and auditing

Session Manager doesn’t just improve security, it also enhances compliance and auditing. Every session can be logged to Amazon S3 or CloudWatch Logs, capturing a full record of all executed commands. This ensures complete visibility into who accessed which instance and what actions were taken.

To enable logging, navigate to AWS Systems Manager > Session Manager, configure Session Preferences, and enable logging to an S3 bucket or CloudWatch Log Group.

Why Session Manager is better than traditional methods

Let’s compare Session Manager with traditional access methods:

Feature	Bastion Host & SSH	AWS Session Manager
Open inbound ports	Yes (22, 3389)	No
Requires SSH keys	Yes	No
Key rotation required	Yes	No
Logs session activity	Manual setup	Built-in
Works for on-premises	No	Yes

Session Manager removes unnecessary complexity. No more juggling bastion hosts, no more worrying about expired SSH keys, and no more open ports that expose your infrastructure to unnecessary risks.

Real-World applications and operational Benefits

Session Manager is not just a theoretical improvement, it delivers real-world value in multiple scenarios:

Developers can quickly access production or staging instances without security concerns.
System administrators can perform routine maintenance without managing SSH key distribution.
Security teams gain complete visibility into instance access and command history.
Hybrid cloud environments benefit from unified access across AWS and on-premises infrastructure.

With these advantages, Session Manager aligns perfectly with modern cloud-native security principles, helping teams focus on operations rather than infrastructure headaches.

In summary

AWS Session Manager isn’t just another tool, it’s a fundamental shift in how we access EC2 instances securely. If you’re still relying on bastion hosts and SSH keys, it’s time to rethink your approach.Try it out, configure logging, and experience a simpler, more secure way to manage your instances. You might never go back to the old ways.

Boost Performance and Resilience with AWS EC2 Placement Groups

There’s a hidden art to placing your EC2 instances in AWS. It’s not just about spinning up machines and hoping for the best, where they land in AWS’s vast infrastructure can make all the difference in performance, resilience, and cost. This is where Placement Groups come in.

You might have deployed instances before without worrying about placement, and for many workloads, that’s perfectly fine. But when your application needs lightning-fast communication, fault tolerance, or optimized performance, Placement Groups become a critical tool in your AWS arsenal.

Let’s break it down.

What are Placement Groups?

AWS Placement Groups give you control over how your EC2 instances are positioned within AWS’s data centers. Instead of leaving it to chance, you can specify how close, or how far apart, your instances should be placed. This helps optimize either latency, fault tolerance, or a balance of both.

There are three types of Placement Groups: Cluster, Spread, and Partition. Each serves a different purpose, and choosing the right one depends on your application’s needs.

Types of Placement Groups and when to use them

Cluster Placement Groups for speed over everything

Think of Cluster Placement Groups like a Formula 1 pit crew. Every millisecond counts, and your instances need to communicate at breakneck speeds. AWS achieves this by placing them on the same physical hardware, minimizing latency, and maximizing network throughput.

This is perfect for:
✅ High-performance computing (HPC) clusters
✅ Real-time financial trading systems
✅ Large-scale data processing (big data, AI, and ML workloads)

⚠️ The Trade-off: While these instances talk to each other at lightning speed, they’re all packed together on the same hardware. If that hardware fails, everything inside the Cluster Placement Group goes down with it.

Spread Placement Groups for maximum resilience

Now, imagine you’re managing a set of VIP guests at a high-profile event. Instead of seating them all at the same table (risking one bad spill ruining their night), you spread them out across different areas. That’s what Spread Placement Groups do, they distribute instances across separate physical machines to reduce the impact of hardware failure.

Best suited for:
✅ Mission-critical applications that need high availability
✅ Databases requiring redundancy across multiple nodes
✅ Low-latency, fault-tolerant applications

⚠️ The Limitation: AWS allows only seven instances per Availability Zone in a Spread Placement Group. If your application needs more, you may need to rethink your architecture.

Partition Placement Groups, the best of both worlds approach

Partition Placement Groups work like a warehouse with multiple sections, each with its power supply. If one section loses power, the others keep running. AWS follows the same principle, grouping instances into multiple partitions spread across different racks of hardware. This provides both high performance and resilience, a sweet spot between Cluster and Spread Placement Groups.

Best for:
✅ Distributed databases like Cassandra, HDFS, or Hadoop
✅ Large-scale analytics workloads
✅ Applications needing both performance and fault tolerance

⚠️ AWS’s Partitioning Rule: The number of partitions you can use depends on the AWS Region, and you must carefully plan how instances are distributed.

How to Configure Placement Groups

Setting up a Placement Group is straightforward, and you can do it using the AWS Management Console, AWS CLI, or an SDK.

Example using AWS CLI

Let’s create a Cluster Placement Group:

aws ec2 create-placement-group --group-name my-cluster-group --strategy cluster

Now, launch an instance into the group:

aws ec2 run-instances --image-id ami-12345678 --count 1 --instance-type c5.large --placement GroupName=my-cluster-group

For Spread and Partition Placement Groups, simply change the strategy:

aws ec2 create-placement-group --group-name my-spread-group --strategy spread
aws ec2 create-placement-group --group-name my-partition-group --strategy partition

Best practices for using Placement Groups

🚀 Combine with Multi-AZ Deployments: Placement Groups work within a single Availability Zone, so consider spanning multiple AZs for maximum resilience.

📊 Monitor Network Performance: AWS doesn’t guarantee placement if your instance type isn’t supported or there’s insufficient capacity. Always benchmark your performance after deployment.

💰 Balance Cost and Performance: Cluster Placement Groups give the fastest network speeds, but they also increase failure risk. If high availability is critical, Spread or Partition Groups might be a better fit.

Final thoughts

AWS Placement Groups are a powerful but often overlooked feature. They allow you to maximize performance, minimize downtime, and optimize costs, but only if you choose the right type.

The next time you deploy EC2 instances, don’t just launch them randomly, placement matters. Choose wisely, and your infrastructure will thank you for it.

February 11, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff 0

Building a strong cloud foundation with Landing Zones

The cloud is a dream come true for businesses. Agility, scalability, global reach, it’s all there. But, jumping into the cloud without a solid foundation is like setting up a city without roads, plumbing, or electricity. Sure, you can start building skyscrapers, but soon enough, you’ll be dealing with chaos, no clear way to manage access, tangled networking, security loopholes, and spiraling costs.

That’s where Landing Zones come in. They provide the blueprint, the infrastructure, and the guardrails so you can grow your cloud environment in a structured, scalable, and secure way. Let’s break it down.

What is a Landing Zone?

Think of a Landing Zone as the cloud’s equivalent of a well-planned neighborhood. Instead of letting houses pop up wherever they fit, you lay down roads, set up electricity, define zoning rules, and ensure there’s proper security. This way, when new residents move in, they have everything they need from day one.

In technical terms, a Landing Zone is a pre-configured cloud environment that enforces best practices, security policies, and automation from the start. You’re not reinventing the wheel every time you deploy a new application; instead, you’re working within a structured, repeatable framework.

Key components of any Landing Zone:

Identity and Access Management (IAM): Who has the keys to which doors?
Networking: The plumbing and wiring of your cloud city.
Security: Built-in alarms, surveillance, and firewalls.
Compliance: Ensuring regulations like GDPR or HIPAA are followed.
Automation: Infrastructure as Code (IaC) sets up resources predictably.
Governance: Rules that ensure consistency and control.

Why do you need a Landing Zone?

Why not just create cloud resources manually as you go? That’s like building a house without a blueprint, you’ll get something up, but sooner or later, it will collapse under its complexity.

Landing Zones save you from future headaches:

Faster Cloud Adoption: Everything is pre-configured, so teams can deploy applications quickly.
Stronger Security: Policies and guardrails are in place from day one, reducing risks.
Cost Efficiency: Prevents the dreaded “cloud sprawl” where resources are created haphazardly, leading to uncontrolled expenses.
Focus on Innovation: Teams spend less time on setup and more time on building.
Scalability: A well-structured cloud environment grows effortlessly with your needs.

It’s the difference between a well-organized toolbox and a chaotic mess of scattered tools. Which one lets you work faster and with fewer mistakes?

Different types of Landing Zones

Not all businesses need the same kind of cloud setup. The structure of your Landing Zone depends on your workloads and goals.

Cloud-Native: Designed for applications built specifically for the cloud.
Lift-and-Shift: Migrating legacy applications without significant changes.
Containerized: Optimized for Kubernetes and Docker-based workloads.
Data Science & AI/ML: Tailored for heavy computational and analytical tasks.
Hybrid Cloud: Bridging on-premises infrastructure with cloud resources.
Multicloud: Managing workloads across multiple cloud providers.

Each approach serves a different need, just like different types of buildings, offices, factories, and homes, serve different purposes in a city.

Landing Zones in AWS

AWS provides tools to make Landing Zones easier to implement, whether you’re a beginner or an advanced cloud architect.

Key AWS services for Landing Zones:

AWS Organizations: Manages multiple AWS accounts under a unified structure.
AWS Control Tower: Automates Landing Zone set up with best practices.
IAM, VPC, CloudTrail, Config, Security Hub, Service Catalog, CloudFormation: The building blocks that shape your environment.

Two ways to set up a Landing Zone in AWS:

AWS Control Tower (Recommended) – Provides an automated, guided setup with guardrails and best practices.
Custom-built Landing Zone – Built manually using CloudFormation or Terraform, offering more flexibility but requiring expertise.

Basic setup with Control Tower:

Plan your cloud structure.
Set up AWS Organizations to manage accounts.
Deploy Control Tower to automate governance and security.
Customize it to match your specific needs.

A well-structured AWS Landing Zone ensures that accounts are properly managed, security policies are enforced, and networking is set up for future growth.

Scaling and managing your Landing Zone

Setting up a Landing Zone is not a one-time task. It’s a continuous process that evolves as your cloud environment grows.

Best practices for ongoing management:

Automate Everything: Use Infrastructure as Code (IaC) to maintain consistency.
Monitor Continuously: Use AWS CloudWatch and AWS Config to track changes.
Manage Costs Proactively: Keep cloud expenses under control with AWS Budgets and Cost Explorer.
Stay Up to Date: Cloud best practices evolve, and so should your Landing Zone.

Think of your Landing Zone like a self-driving car. You might have set it up with the best configuration, but if you never update the software or adjust its sensors, you’ll eventually run into problems.

Summarizing

A strong Landing Zone isn’t just a technical necessity, it’s a strategic advantage. It ensures that your cloud journey is smooth, secure, and cost-effective.

Many businesses rush into the cloud without a plan, only to find themselves overwhelmed by complexity and security risks. Don’t be one of them. A well-architected Landing Zone is the difference between a cloud environment that thrives and one that turns into a tangled mess of unmanaged resources.

Set up your Landing Zone right, and you won’t just land in the cloud, you’ll be ready to take off.

February 10, 2025 by Fernando SRE Cloud stuff DevOps stuff 0

Lower costs with Valkey on Amazon ElastiCache

Amazon ElastiCache is a fully managed, in-memory caching service that helps you boost your application performance by retrieving information from fast, managed, in-memory caches, instead of relying solely on slower disk-based databases. Until now, you’ve had a couple of main choices for your caching engine: Memcached and Redis. Memcached is the simple, no-frills option, while Redis is the powerful, feature-rich one. Many companies, including mine, skip Memcached entirely due to its limitations. Now, there’s a new kid on the block: Valkey. And it’s not here to replace either of them but to give us more options. So, what’s the big deal?

What’s the deal with Valkey and why should we care?

Valkey is essentially a fork of Redis, meaning it branched off from the Redis codebase. It’s open-source, under the BSD 3-Clause license, and developed by a community of developers. Think of it like this: Redis was a popular open-source project, but its licensing changed slightly. So, a group of folks decided to take the core idea and continue developing it with a more open and community-focused approach. That’s Valkey in a nutshell. Importantly, Valkey uses the same protocol as Redis. This means you can use the same Redis clients to interact with Valkey, making it easy to switch or try out.

Now, you might be thinking, “Another caching engine? Why bother?”. Well, the interesting part about Valkey is that it claims to be just as powerful as Redis, but potentially more cost-effective. This is achieved by focusing on performance and resource usage. While Valkey has similarities with Redis, its community is putting in effort to improve some internal aspects. The end goal is to offer performance comparable to Redis but with better resource utilization. This can lead to significant cost savings in the long term. Also, being open source means no hefty licensing fees, unlike some commercial versions of Redis. This makes Valkey a compelling option, especially for applications that rely heavily on caching.

Valkey vs. Redis? As powerful as Redis but with a better price tag

This is where things get interesting. Valkey is designed to be compatible with the Redis protocol. This is crucial because it means migrating from Redis to Valkey should be relatively straightforward. You can keep using your existing Redis client libraries, which is a huge plus.

Now, when it comes to speed, early benchmarks suggest that Valkey can go toe-to-toe with Redis, and sometimes even surpass it, depending on the workload. This could be due to some clever optimizations under the hood in how Valkey handles memory or manages data structures.

But the real kicker is the potential for cost savings. How does Valkey achieve this? It boils down to efficiency. It seems that Valkey might be able to do more with less. For example, it could potentially store more data in the same instance size compared to Redis, meaning you pay less for the same amount of cached data. Or, it might use less CPU power for the same workload, allowing you to choose smaller, cheaper instances.

Why choose Valkey on ElastiCache? The key benefits

Let’s break down the main advantages of using Valkey:

Cost reduction: This is probably the biggest draw. Valkey’s efficiency, combined with its open-source nature, can lead to a smaller AWS bill. Imagine needing fewer or smaller instances to handle the same caching load. That’s money back in your pocket.
Scalable performance: Valkey is built to scale horizontally, just like Redis. You can add more nodes to your cluster to handle increased demand, ensuring your application remains snappy even under heavy load. It supports replication and high availability, so your data is safe and your application keeps running smoothly.
Flexibility and control: Because Valkey is open source, you have more transparency and control over the software you’re using. You can peek under the hood, understand how it works, and even contribute to its development if you’re so inclined.
Active community: Valkey is driven by a passionate community. This means continuous development, quick bug fixes, and a wealth of shared knowledge. It’s like having a global team of experts working to make the software better.

So, when should you pick Valkey over Redis?

Valkey seems particularly well-suited for a few scenarios:

Cost-sensitive applications: If you’re looking to optimize your infrastructure costs without sacrificing performance, Valkey is worth considering.
High-Throughput workloads: Applications that do a lot of reading and writing to the cache can benefit from Valkey’s efficiency.
Open source preference: Companies that prefer using open-source software for philosophical or practical reasons will find Valkey appealing.

Of course, it’s important to remember that Valkey is relatively new. While it’s showing great promise, it’s always a good idea to keep an eye on its development and adoption within the industry. Redis remains a solid, battle-tested option, so the choice ultimately depends on your specific needs and priorities.

The bottom line

Adding Valkey to ElastiCache is like getting a new, potentially more efficient tool in your toolbox. It doesn’t replace Redis, but it gives you another option, one that could save you money while delivering excellent performance. So, why not give Valkey a try on ElastiCache and see if it’s the right fit for your application? You might be pleasantly surprised. Remember, the best way to know is to test it yourself and see those cost savings firsthand.

February 4, 2025 by Fernando SRE Cloud stuff DevOps stuff 0

Avoiding security gaps by limiting IAM Role permissions

Think about how often we take security for granted. You move into a new apartment and forget to lock the door because nothing bad has ever happened. Then, one day, someone strolls in, helps themselves to your fridge, sits on your couch, and even uses your WiFi. Feels unsettling, right? That’s exactly what happens in AWS when an IAM role is granted far more permissions than it needs, leaving the door wide open for potential security risks.

This is where the principle of least privilege comes in. It’s a fancy way of saying: “Give just enough permissions for the job to get done, and nothing more.” But how do we figure out exactly what permissions an application needs? Enter AWS CloudTrail and Access Analyzer, two incredibly useful tools that help us tighten security without breaking functionality.

The problem of overly generous permissions

Let’s say you have an application running in AWS, and you assign it a role with AdministratorAccess. It can now do anything in your AWS account, from spinning up EC2 instances to deleting databases. Most of the time, it doesn’t even need 90% of these permissions. But if an attacker gets access to that role, you’re in serious trouble.

What we need is a way to see what permissions the application is actually using and then build a custom policy that includes only those permissions. That’s where CloudTrail and Access Analyzer come to the rescue.

Watching everything with CloudTrail

AWS CloudTrail is like a security camera that records every API call made in your AWS environment. It logs who did what, which service they accessed, and when they did it. If you enable CloudTrail for your AWS account, it will capture all activity, giving you a clear picture of which permissions your application uses.

So, the first step is simple: Turn on CloudTrail and let it run for a while. This will collect valuable data on what the application is doing.

Generating a Custom Policy with Access Analyzer

Now that we have a log of the application’s activity, we can use AWS IAM Access Analyzer to create a tailor-made policy instead of guessing. Access Analyzer looks at the CloudTrail logs and automatically generates a policy containing only the permissions that were used.

It’s like watching a security camera playback of who entered your house and then giving house keys only to the people who actually needed access.

Why this works so well

This approach solves multiple problems at once:

Precise permissions: You stop giving unnecessary access because now you know exactly what is needed.
Automated policy generation: Instead of manually writing a policy full of guesswork, Access Analyzer does the heavy lifting.
Better security: If an attacker compromises the role, they get access only to a limited set of actions, reducing damage.
Following best practices: Least privilege is a fundamental rule in cloud security, and this method makes it easy to follow.

Recap

Instead of blindly granting permissions and hoping for the best, enable CloudTrail, track what your application is doing, and let Access Analyzer craft a custom policy. This way, you ensure that your IAM roles only have the permissions they need, keeping your AWS environment secure without unnecessary exposure.

Security isn’t about making things difficult. It’s about making sure that only the right people, and applications, have access to the right things. Just like locking your door at night.

January 31, 2025 by Fernando SRE Cloud stuff SRE stuff 0

Unlocking efficiency with Amazon S3 Batch Operations

Suppose you’re a librarian, but instead of books, you’ve got millions, maybe billions, of files stored in the cloud. That’s what it’s like for many folks using Amazon S3 (Simple Storage Service). It’s a fantastic place to keep your digital stuff, but managing those files, especially in bulk, can be a real headache. It’s like trying to reshelve a whole library by hand, one book at a time. Tedious, right? That’s where S3 Batch Operations steps in, like a team of super-efficient robot librarians.

What is Amazon S3 Batch Operations?

Think of S3 Batch Operations as a powerful command center tool that lets you tell S3, “Hey, I need you to do something to a whole bunch of files, not just one.” You create what’s called a “job.” In this job, you specify:

The Inventory: A list of all the objects you want to work on. You can use an S3 inventory report or even a simple CSV.
The Operation: What you want to do with those objects: copy them, tag them, restore them from the archive, process them using lambda functions, and modify their lifecycle retention policies.

Then, you just let it run. S3 Batch Operations takes care of the rest, processing your files automatically.

Key features of Amazon S3 Batch Operations

This isn’t just about doing things in bulk. It’s about doing them smartly. Here’s what makes S3 Batch Operations stand out:

Copying Objects: Need to duplicate objects across buckets or regions? Maybe for backup or to move data closer to your users? Batch Operations handles it. You can specify the destination, storage class, and other settings.
Setting Tags: Tags are like labels on your files. They help you organize, search, and manage your data. Batch Operations lets you add, modify, or delete tags on millions of objects at once. Imagine tagging all your customer invoices with a specific project ID, in one go.
Restoring Objects from Glacier: Glacier is like the deep archive of S3, cheap but slow. Batch Operations can initiate the restoration of objects from Glacier in bulk.
Invoking Lambda Functions: This is where it gets really interesting. You can trigger Lambda functions for each object. Imagine automatically resizing images, converting file formats, or extracting metadata. The possibilities are endless! For example, you can invoke a Lambda function with Batch Operations to analyze web server logs, extract relevant information, and load it into a data warehouse for further analysis.
Applying Retention Policies: Need to comply with regulations that require you to keep data for a certain period, or automatically delete it after a while? Batch Operations can apply or modify retention policies on large datasets.

Some use cases

Let’s get practical. Here are some scenarios where S3 Batch Operations becomes a lifesaver:

Metadata Updates: Suppose you need to change the tags on millions of objects to reflect a new categorization scheme or comply with updated policies. For example, renaming a tag that was used with the category “Client X” to be replaced with a tag with the category “Company Y”. Batch Operations makes this a breeze.
Data Migration: Want to move old files to a cheaper storage class like Glacier to save costs? Batch Operations can automate this, and you can selectively restore files as needed.
Large-Scale Data Processing: Need to run analytics, transform data, or enrich your datasets? Batch Operations, combined with Lambda, lets you do this on a massive scale, automatically.
Disaster Recovery Replication: Set up automatic object replication to another region as part of your disaster recovery strategy.
Compliance and Audits: Easily apply or modify retention policies to comply with regulations like GDPR or HIPAA. No more manual work or worrying about missing something.
Implementing Data Lakes or Data Warehouses: In this use case, Batch Operations is used for data transformation (ETL) tasks and for ingesting and transforming large amounts of unstructured data into a structured format within the data lake. For example, converting JSON files without a standard format to a structured format, such as Parquet.

Benefits of using S3 Batch Operations

Why bother with all this? Because it makes your life easier and your operations more efficient. Let’s break it down:

Automatic Retries: If an operation fails for some reason, S3 Batch Operations will automatically retry it. No need to babysit the process.
Detailed Progress Reports: You get detailed reports on the status of your job. You can see which operations succeeded, which failed, and why.
Operation Status Tracking: You can monitor the progress of your job in real time.
Automatic Scaling: It doesn’t matter if you’re processing a thousand objects or a billion. S3 Batch Operations scales automatically to handle the load.
Time and Resource Savings: Automate tasks that would otherwise take days or weeks to do manually.
Error Reduction: Minimize the risk of human error in managing your data.
Enhanced Operational Efficiency: Optimize your use of AWS resources.
Improved Data Governance: Make it easier to apply policies and comply with regulations.

In a few words

Amazon S3 Batch Operations isn’t just another feature; it’s a game-changer for anyone dealing with large amounts of data in S3. It’s like having a superpower that lets you manage your data with efficiency and precision.

January 30, 2025 by Fernando SRE Cloud stuff DevOps stuff 0

AWS Identity Management – Choosing the right Policy or Role

Let’s be honest, AWS Identity and Access Management (IAM) can feel like a jungle. You’ve got your policies, your roles, your managed this, and your inline that. It’s easy to get lost, and a wrong turn can lead to a security vulnerability or a frustrating roadblock. But fear not! Just like a curious explorer, we’re going to cut through the thicket and understand this thing. Why? Mastering IAM is crucial to keeping your AWS environment secure and efficient. So, which policy type is the right one for the job? Ever scratched your head over when to use a service-linked role? Stick with me, and we’ll figure it out with a healthy dose of curiosity and a dash of common sense.

Understanding Policies and Roles

First things first. Let’s get our definitions straight. Think of policies as rulebooks. They are written in a language called JSON, and they define what actions are allowed or denied on which AWS resources. Simple enough, right?

Now, roles are a bit different. They’re like temporary access badges. An entity, be it a user, an application, or even an AWS service itself, can “wear” a role to gain specific permissions for a limited time. A user or a service is not granted permissions directly, it’s the role that has the permissions.

AWS Policy types

Now, let’s explore the different flavors of policies.

AWS Managed Policies

These are like the standard-issue rulebooks created and maintained by AWS itself. You can’t change them, just like you can’t rewrite the rules of physics! But AWS keeps them updated, which is quite handy.

Use Cases: Perfect for common scenarios. Need to give someone basic access to S3? There’s probably an AWS-managed policy for that.
Pros: Easy to use, always up-to-date, less work for you.
Cons: Inflexible, you’re stuck with what AWS provides.

Customer Managed Policies

These are your rulebooks. You write them, you modify them, you control them.

Use Cases: When you need fine-grained control, like granting access to a very specific resource or creating custom permissions for your application, this is your go-to choice.
Pros: Total control, flexible, adaptable to your unique needs.
Cons: More responsibility, you need to know what you’re doing. You’ll be in charge of updating and maintaining them.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-specific-bucket/*"
        }
    ]
}

This simple policy allows getting objects only from my-specific-bucket. You have to adapt it to your necessities.

Inline Policies

These are like sticky notes attached directly to a user, group, or role. They’re tightly bound and can’t be reused.

Use Cases: For precise, one-time permissions. Imagine a developer who needs temporary access to a particular resource for a single task.
Pros: Highly specific, good for exceptions.
Cons: A nightmare to manage at scale, not reusable.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "dynamodb:DeleteItem",
            "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"
        }
    ]
}

This policy is directly embedded within users and permits them to delete items from the MyTable DynamoDB table. It does not apply to other users or resources.

Service-Linked Roles. The smooth operators

These are special roles pre-configured by AWS services to interact with other AWS services securely. You don’t create them, the service does.

Use Cases: Think of Auto Scaling needing to launch EC2 instances or Elastic Load Balancing managing resources on your behalf. It’s like giving your trusted assistant a special key to access specific rooms in your house.
Pros: Simplifies setup, and ensures security best practices are followed. AWS takes care of these roles behind the scenes, so you don’t need to worry about them.
Cons: You can’t modify them directly. So, it’s essential to understand what they do.

aws autoscaling create-auto-scaling-group \ --auto-scaling-group-name my-asg \ --launch-template "LaunchTemplateId=lt-0123456789abcdef0,Version=1" \ --min-size 1 \ --max-size 3 \ --vpc-zone-identifier "subnet-0123456789abcdef0" \ --service-linked-role-arn arn:aws:iam::123456789012:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling

This code creates an Auto Scaling group, and the service-linked-role-arn parameter specifies the ARN of the service-linked role for Auto Scaling. It’s usually created automatically by the service when needed.

Best practices

Least Privilege: Always, always, always grant only the necessary permissions. It’s like giving out keys only to the rooms people need to access, not the entire house!
Regular Review: Things change. Regularly review your policies and roles to make sure they’re still appropriate.
Use the Right Tools: AWS provides tools like IAM Access Analyzer to help you manage this stuff. Use them!
Document Everything: Keep track of your policies and roles, their purpose, and why they were created. It will save you headaches later.

In sum

The right policy or role depends on the specific situation. Choose wisely, keep things tidy, and you will have a secure and well-organized AWS environment.

January 29, 2025 by Fernando SRE Cloud stuff SRE stuff 0

Deciphering AWS Network Mysteries with Reachability Analyzer

Let’s talk about the cloud, specifically, the tangled web of networks we build inside AWS. You spin up your Virtual Private Clouds (VPCs), toss in some subnets, sprinkle in a few security groups, configure those route tables, and before you know it, you’ve got a more complex network than a Rube Goldberg machine. Everything works great… until it doesn’t. A connection fails, an application times out, and you’re left scratching your head. Where do you even begin to troubleshoot?

This is the exact headache that AWS Reachability Analyzer is designed to cure. It is not the most known tool in the AWS toolbox, but believe me, it’s a lifesaver when diagnosing network connectivity issues. This article will explore what Reachability Analyzer is, how this handy tool works its magic, and why you should use it to keep your AWS network humming along smoothly.

What exactly is AWS Reachability Analyzer?

So, what’s the deal with Reachability Analyzer? Think of it as your network detective. It’s a configuration analysis tool that lets you test the connectivity between a source and a destination within your AWS environment. The beauty of it is that it doesn’t send any live traffic. Instead, it does something much smarter.

This nifty tool analyzes your network configuration, your security groups, Network Access Control Lists (NACLs), route tables, and all that jazz. It then builds a virtual model of your network and simulates the path that traffic would take. This way it determines whether packets starting their journey at the source could reach their intended destination.

Reachability Analyzer is part of the VPC service but tightly integrates with AWS Network Manager. If you’re dealing with a global network spanning multiple regions, Network Manager lets you run these reachability analyses centrally, giving you a bird’s-eye view of connectivity across your entire infrastructure.

It’s essential to understand what Reachability Analyzer doesn’t do. It won’t test your application-level connectivity or tell you anything about latency. It strictly focuses on the network layer, making sure the path is clear, based on your setup. It also does not take into account firewall rules of the OS, or the capacity of the resources to handle the traffic.

The perks of using Reachability Analyzer

Why bother with Reachability Analyzer? Let me break down the key benefits:

Pinpoint Connectivity Problems Fast: No more endless digging through logs or running manual traceroutes. Reachability Analyzer quickly identifies the root cause of connectivity issues, saving you precious time and frustration.
Validate Your Network Setup: It helps ensure your network is configured exactly as you intended and that your security policies are correctly enforced.
Plan Network Changes with Confidence: Before making any changes to your network, you can use Reachability Analyzer to simulate the impact and avoid accidental outages.
Boost Your Security Posture: By uncovering potential configuration flaws, it helps you strengthen your network’s defenses.
Easy Peasy to Use: The interface is intuitive. You don’t need to be a networking guru to use it effectively.
Identify Components Involved: It shows you hop-by-hop the details of the virtual path between the origin and the destination, giving you visibility of the resources involved in the connection.

Reachability Analyzer in Action

Let’s get our hands dirty with some practical examples to see how Reachability Analyzer shines in real-world scenarios:

Scenario 1 – EC2 Instance Can’t Talk to RDS Database

Your application running on an EC2 instance is throwing a tantrum and can’t connect to your RDS database, even though they’re in the same VPC. Reachability Analyzer to the rescue! You set up an analysis between the EC2 instance’s Elastic Network Interface (ENI) and the RDS instance’s ENI.

Bam! Reachability Analyzer might reveal that the RDS security group is the culprit. It’s not allowing inbound traffic from the EC2 instance’s security group on the database port. The problem is identified, and you can fix the security group rule with surgical precision.
Scenario 2 – Testing Connectivity After Route Table Tweaks

You’ve just modified a route table to direct traffic between two subnets through a firewall. Now you need to be sure that connectivity is still working as expected.

Simply create an analysis between an instance in the source subnet and one in the destination subnet. Reachability Analyzer will show you the complete path, including the hop through the firewall. If there’s a hiccup in the route table or the firewall configuration, you’ll spot it immediately.
Scenario 3 – VPN Connectivity Woes

You’ve set up a VPN connection between your VPC and your on-premise network, but your users are complaining that they can’t access resources on-premise. Time to bring in Reachability Analyzer.

Run an analysis from an instance in your VPC to an IP address of a server in your on-premise network. Reachability Analyzer might show you that your subnet’s route table is missing a route to the on-premise network via the Virtual Private Gateway (VGW). Or maybe there is a problem with the configuration of your VPN tunnel. The results will give you the clues you need to troubleshoot the VPN setup.
Scenario 4 – Transit Gateway Validation

You are using a Transit Gateway to connect multiple VPCs, and you need to verify connectivity between them.

Configure tests between instances in different VPCs attached to the Transit Gateway. Reachability Analyzer will show you if the Transit Gateway route tables are correctly configured and if the VPCs can communicate through the resource. It can also help determine if there are asymmetric routing issues, where traffic flows in one direction but not the other.

How to use Reachability Analyzer

Ready to give it a spin? Here’s a simple step-by-step guide:

Access the Tool: Head over to the AWS Management Console, navigate to the VPC section, and you’ll find Reachability Analyzer there. Or, if you are using Network Manager, you can find it in that section.
Create an Analysis:

.- Select your source and destination. This could be an EC2 instance, an ENI, an Internet Gateway, a VPN Gateway, and more.

.- Specify the protocol (TCP or UDP) and optionally, the destination port.

.- If needed and applicable, enter the source IP address or port.

Run the Analysis: Hit the “Create and run analysis path” button and let Reachability Analyzer do its thing.
Interpret the Results:

.- The tool will tell you if the destination is “Reachable” or “Not reachable.”

.- If there’s a problem, it will provide a detailed breakdown of the path, showing you exactly which component is blocking the connection and an explanation of why.

Run the Analysis from Network Manager: If you have a global network, run the reachability analysis from Network Manager for a broader view.

Wrapping Up

AWS Reachability Analyzer is a powerful tool that simplifies network troubleshooting and gives you greater control over your AWS environment. It’s like having X-ray vision for your network. So, next time you encounter a connectivity mystery in your AWS setup, don’t panic. Fire up Reachability Analyzer, and you will have answers in minutes. Try it out, experiment, and unlock the secrets of your network.

January 23, 2025 by Fernando SRE Cloud stuff DevOps stuff SRE stuff 0

Real-Time insights with Amazon CloudWatch Logs Live Tail

Imagine you’re a detective, but instead of a smoky backroom, your case involves the intricate workings of your cloud applications. Your clues? Logs. Reams and reams of digital logs. Traditionally, sifting through logs is like searching for a needle in a digital haystack, tedious and time-consuming. But what if you could see those clues, those crucial log entries, appear right before your eyes, as they happen? That’s where Amazon CloudWatch Logs and its nifty feature, Live Tail, come into play.

Amazon CloudWatch Logs is the central hub for all sorts of logs generated by your applications, services, and resources within the vast realm of AWS. Think of it as a meticulous record keeper, diligently storing every event, every error, every whisper of activity within your cloud environment. But within this record keeper, you have Live Tail. This is a game changer for anyone who wants to monitor their cloud environment.

Understanding Amazon CloudWatch Logs Live Tail

So, what’s the big deal with Live Tail? Well, picture this: instead of refreshing your screen endlessly, hoping to catch that crucial log entry, Live Tail delivers them to you in real time, like a live news feed for your application’s inner workings. No more waiting, no more manual refreshing. It’s like having X-ray vision for your logs.

How does it achieve this feat of real-time magic? Using WebSockets, establish a persistent connection to your chosen log group. Think of it as a dedicated hotline between your screen and your application’s logs. Once connected, any new log event in the group is instantly streamed to your console.

But Live Tail isn’t just about speed; it’s about smart observation. It offers a range of key features, such as:

Real-time Filtering: You can tell Live Tail to only show you specific types of log entries. Need to see only errors? Just filter for “ERROR.” Looking for a specific user ID? Filter for that. It’s like having a super-efficient assistant that only shows you the relevant clues. You can even get fancy and use regular expressions for more complex searches.
Highlighting Key Terms: Spotting crucial information in a stream of text can be tricky. Live Tail lets you highlight specific words or phrases, making them pop out like a neon sign in the dark.
Pause and Resume: Need to take a closer look at something that whizzed by? Just hit pause, analyze the log entry, and then resume the live stream whenever you’re ready.
View Multiple Log Groups Simultaneously: Keep your eyes on various log groups all at the same time.

The Benefits Unveiled

Now, why should you care about all this real-time log goodness? The answer is simple: it makes your life as a developer, operator, or troubleshooter infinitely easier. Let’s break down the perks:

Debugging and Troubleshooting at Warp Speed: Imagine an error pops up in your application. With Live Tail, you see it the moment it happens. You can quickly trace the error back to its source, understand the context, and squash that bug before it causes any major headaches. This is a far cry from the old days of digging through mountains of historical logs.
Live Monitoring of Applications and Services: Keep a watchful eye on your application’s pulse. Observe how it behaves in the wild, in real time. Detect strange patterns, unexpected spikes in activity, or anything else that might signal trouble brewing.
Boosting Operational Efficiency: Less time spent hunting for problems means more time for building, innovating, and, well, maybe even taking a coffee break without worrying about your application falling apart.

Getting Started with Live Tail A Simple Guide

Alright, let’s get our hands dirty. Setting up Live Tail is a breeze. Here’s a simplified walkthrough:

Head over to the Amazon CloudWatch console in your AWS account.
Find CloudWatch Logs and start a Live Tail session.
Select the log group or groups, you want to observe.
If you want, set up some filters and highlighting rules to focus on the important stuff.
Hit start, and watch the logs flow in real time!
Use the pause and resume functions if you need them.

In the Wild

To truly grasp the power of Live Tail, let’s look at some practical scenarios:

Scenario 1 The Case of the Web App Errors: Your web application is throwing errors, but you don’t know why. Using Live Tail you start a session, filter for error messages, and almost instantly see the error and all the context surrounding it, allowing you to pinpoint the cause swiftly.
Scenario 2 Deploying a New Release: You’re rolling out a new version of your software. With Live Tail, you can monitor the deployment process, watching for any errors or hiccups, and ensuring a smooth transition.
Scenario 3 API Access Monitoring: You want to track requests to your API in real-time. Live Tail allows you to see who’s accessing your API, and what they’re requesting, and spot any unusual activity or potential security threats as they occur.

Final Thoughts

Amazon CloudWatch Logs Live Tail is like giving your detective a superpower. It transforms log analysis from a tedious chore into a dynamic, real-time experience. By providing instant insights into your application’s behavior, it empowers you to troubleshoot faster, monitor more effectively, and ultimately build better, more resilient systems. Live Tail is an essential tool in your cloud monitoring arsenal, working seamlessly with other CloudWatch features like Metrics, Alarms, and Dashboards to give you a complete picture of your cloud environment’s health. So, why not give it a try and see the difference it can make? You might just find yourself wondering how you ever lived without it.

January 22, 2025 by Fernando SRE Cloud stuff DevOps stuff 0