DEV Community: Sachith Fernando

My 12-Month Sprint to AWS Community Builder 2025

Sachith Fernando — Wed, 30 Apr 2025 03:46:58 +0000

Twelve months ago I hit Publish on my very first AWS blog post. Today I’m writing this as a AWS Community Builder, a member of the AWS Emerging Talent Community. Here’s everything that happened in between and what I learned along the way.

April 2024 – “Let’s try this blogging thing”

Date	Article	Views
14 Apr 2024	Serverless Computing and Containers in AWS – a side-by-side comparison of Lambda & Fargate	47

I’d spent weeks tinkering with Lambda function for a university project, and friends kept asking, “When would you ever choose containers instead?” Turning that answer into an article felt terrifying…right up until the moment I pressed Publish. The post didn’t break the internet, but it did break my fear of writing blogs about AWS.

Highlight posts

Date	Article	Views
16 Jun 2024	Amazon RDS Multi-AZ Deployments vs Read Replica	376
8 Dec 2024	Connecting AWS RDS to Spring Boot	1 695

Metric snapshot: 13 AWS-focused posts · 4 076 total views · 145 reactions

The December post took off after someone shared it in an enterprise Slack channel—proof that depth plus timing can out-perform follower counts.

Badges that opened doors (Jun → Nov 2024)

Badge	Date earned
Getting Started with AWS Database	Jun 2024
Getting Started with AWS Storage	Jul 2024
Getting Started with AWS Compute	Nov 2024

In November 2024 an email arrived:

“As an AWS Educate badge earner you qualify for the **AWS Emerging Talent Community…”

Free certification preparations, career guidance, and earn points by completing content that I can use for rewards in the ETC!

The email that changed everything (5 Mar 2025)

At 12:39 PM the subject line lit up:

“🚀 Welcome to the AWS Community Builders Program”

I re-read it three times before noticing my category: Data.

A few days later the welcome pack landed on my doorstep:

Why diversity is more than a checkbox

I’m originally from Sri Lanka, and moving to Melbourne, Australia, for my master’s forced me to adapt to new customs, time zones, and accents. That experience taught me how to explain tech ideas so people from any background can follow along. AWS’s selection criteria explicitly call out diversity, and it’s more than lip service, the Slack channels hum with accents from Lagos to Lima to Lahore.
Unique backgrounds aren’t just tolerated, they are accelerators.

Balancing code, class & content

🎓 Studies: full-time Master (Coursework) in Information Technology
💼 Part-time job: IT Support Technician (kept the bills paid and my troubleshooting sharp)
⏳ Hardest part: Time management, learning to schedule writing sprints between lectures and night shifts. My trick: 25-minute Pomodoros + shutting every tab except the markdown file.

Takeaways for you

Ship something small. My first post had 47 views—and that was enough.
Stack learning pathways. Badge → blog → community invitation → bigger badge.
Find a feedback loop. AWS Experts gave me real eyes on early drafts.
Tell your unique story. Backgrounds that feel “non-traditional” in tech are actually superpowers.

Ready to start your own journey?

Earn a foundational badge on AWS Educate.
Publish a working-notes style article—perfection later, URL today.
Join a local AWS User Group (or start one!).
Apply for the next round of AWS Community Builders 2026.

Questions, feedback, or just want to say hi? Connect with me on LinkedIn

Thanks for reading, and see you in the cloud! ☁️👋

Seamless File Storage: Integrating AWS S3 with Spring Boot

Sachith Fernando — Sat, 08 Feb 2025 04:08:40 +0000

Hello Developers! 🚀

Today, I’m going to talk about how to integrate Amazon S3 with Spring Boot for efficient and secure file storage. Whether you're building a cloud-based application, handling user-generated content, or just looking for a scalable way to store files, AWS S3 is a reliable and cost-effective solution. In this article, I’ll guide you through setting up an S3 bucket, configuring access policies, integrating with Spring Boot, and handling file uploads/downloads using the AWS SDK. By the end, you’ll have a fully functional backend that interacts seamlessly with S3. Let’s get started!

AWS S3 Bucket Creation

General Configuration

1️⃣ AWS Region
Region: US East 1(N. Virginia) (us-east-1)
This means the bucket will be created in the US East (N. Virginia) data center.
Choose a region closest to your users to reduce latency and improve performance. Additionally, regions with multiple Availability Zones provide better redundancy and reliability. For most general-purpose applications, us-east-1 (N. Virginia) is a popular choice due to its low cost, high availability, and broad service support.

2️⃣ Bucket Type
General Purpose (Selected)
Recommended for most workloads.
Stores data across multiple Availability Zones for redundancy.

Directory (Not Selected)
Used for low-latency storage.
Supports S3 Express One Zone for faster access but no redundancy across multiple zones.

✅ Best Choice: General Purpose (default option, more reliable).

3️⃣ Bucket Name
Entered Name: spring-aws-s3
The bucket name must be globally unique across all AWS accounts.
AWS naming rules apply (lowercase, no spaces, no special characters except - and .).

4️⃣ Copy Settings from Existing Bucket (Optional)
Allows users to duplicate settings from an existing bucket.
"Choose Bucket" button enables selecting an existing bucket.
Not used in this case (default settings will be applied).

Configure Block Public Access Settings

Configure the Block Public Access settings to secure your bucket. You can allow public access for the Spring Boot application's REST API, customize these settings as shown below.

5️⃣ Allowing Public Access for REST API

Uncheck Block all public access and the related sub-options.

This setting will enable public access to your bucket, which is required for accessing files via your Spring Boot REST API.

Acknowledgement: Ensure you check the acknowledgment box to confirm the settings.

Warning: Allowing public access might expose your bucket contents. Use this option cautiously and consider adding restrictive bucket policies to limit access to specific API calls.

6️⃣ After configuring the settings, click on Create Bucket to finalize the process. Your bucket will now be ready to use!

Spring Boot Development

POM File Dependencies

To enable AWS S3 integration in your Spring Boot application, you need to add the required dependencies to your pom.xml file.

Note: Ensure that you use the correct versions of dependencies to avoid compatibility issues.

Configuration for AWS Credentials

Add the AWS credentials and region configuration in the application.properties file

AWS S3 Client Configuration

Create a configuration class to set up the S3Client for interacting with the S3 bucket. Here’s the code:

For more code details, you can refer to the public repository on GitHub: https://github.com/SachithMayantha/aws-s3-spring

Testing REST API with Postman

Once your Spring Boot application is running, you can test the file upload functionality using Postman. Configure your request as follows:

Method: POST

URL: http://localhost:8080/api/files/upload

Body: Select form-data and add a key file with the value set to the file you want to upload (e.g., Profile.pdf).

Same way, you can test other APIs as well.

Deploying a React.js App on AWS Amplify in 3 Minutes

Sachith Fernando — Wed, 08 Jan 2025 14:16:20 +0000

Deploying web applications quickly and efficiently is essential in today's fast-paced development environment. AWS Amplify, a cloud-based platform by Amazon, makes deploying and managing full-stack applications, including straightforward.

In this guide, I’ll show you how to deploy your React.js github repository on AWS Amplify in just 3 minutes. Let’s dive in and explore AWS Amplify with ReactJS!

Step 1: Create a React App Locally and Push it to GitHub

Before deploying your React.js application on AWS Amplify, the first step is to set up your app locally and upload it to a GitHub repository. This ensures that your application’s code is version-controlled and accessible for deployment.

Step 2: Log In to AWS Console and Navigate to AWS Amplify

After setting up your React app on GitHub, the next step is to deploy it using AWS Amplify. First, login AWS Management Console using your credentials and go to AWS Amplify, then click on create new app

Step 3: Connect Your GitHub Repository to AWS Amplify

Now it's time to connect your GitHub repository and configure the deployment.

1. Choose Your Source Code Provider

On the AWS Amplify dashboard, you'll see the "Start building with Amplify" page, as shown in the screenshot.
Select GitHub as your source code provider and select Next (because I already uploaded my source code into GitHub).

2. Authenticate Your GitHub Account

AWS Amplify will prompt you to authenticate your GitHub account.
You will see the Install & Authorize page, where you can manage which repositories AWS Amplify can access.
You can choose between two options:

All Repositories: Grants AWS Amplify access to all current and future repositories.

Only One Repository: Provides access to specific repositories only.

If you select Only One Repository, choose your React app repository (e.g., recipe-app) as shown.

After reviewing the permissions, click Install & Authorize to grant access.

Step 4: Add Repository and Branch

Once GitHub is authorized, the next step in AWS Amplify is to select the repository and branch that you want to deploy.

1. Select Your Repository

In the Add repository and branch section, choose your GitHub repository from the dropdown menu. In this work, the repository SachithMayantha/recipe-app is selected.
If your repository doesn't appear:
- Ensure the AWS Amplify GitHub App has permissions to access your repository.
- Push a new commit to your repository and click the Refresh button.

2. Select Your Branch

After selecting your repository, choose the branch you want to deploy (e.g., aws-amplify ).
Ensure that the branch contains the latest version of your app's code.

3. Monorepo Configuration (Optional)

If your repository is a monorepo (a single repository containing multiple projects), check the My app is a monorepo option.

Once you’ve selected the repository and branch, click Next to configure your app’s build settings.

With the repository and branch set, you’re now ready to configure build settings for your React app!

Step 5: Configure App Settings and Build Settings

After selecting the repository and branch, the next step is to configure your app settings and verify the build settings.

1. App Name

The App name field will be pre-filled based on your repository name (e.g., recipe-app).
You can leave it as it is or change it to a custom name for better identification.

2. Auto-Detected Framework

AWS Amplify will automatically detect the framework used in your project. In this case, it recognizes that the app is built using React.
This ensures the correct build settings are applied for your framework.

3. Build Settings

Verify the Frontend build command and Build output directory:
- Frontend build command: This is the command used to build your app. For React apps, it’s npm run build.
- Build output directory: This is the folder where the build output is generated. For React apps, it’s usually build.

4. Advanced Build Settings (Optional)

If your project requires environment variables or custom build scripts, you can add them under the Advanced settings section.

5. Save and Continue

Once everything is configured and verified, click Next to proceed to the review and deployment step.

With the app settings and build configuration complete, you’re ready to review your deployment settings and launch your React app! Let’s move on to the final step.

Step 6: Review and Deploy Your React App

Now that you’ve configured your app settings and build steps, it’s time to review your deployment details and launch your app.

1. Review Deployment Details

On the Review page, check the following:
- Repository Details: Verify the GitHub repository name, branch (e.g., aws-amplify), and monorepo root path (if applicable).
- App Settings: Confirm the app name, framework (React), and build configuration (e.g., npm run build with the build directory).
If you need to make changes, click the Edit button next to the respective section.

2. Start Deployment

Once you’ve reviewed the settings, click the Deploy button to start the deployment process.
AWS Amplify will begin building and deploying your app, as shown in the "Deploying app".

3. Monitor Deployment Progress

Amplify provides real-time updates during the build and deployment phases. You can see:
- Build Duration: The time it takes to build your app.
- Deploy Duration: The time it takes to deploy your app to the hosting environment.

4. Access Your Deployed App

After the deployment is complete, you will see a Deployed status.
A unique domain URL will be provided. Click on this link to view your live React app.

Congratulations! Your React app is now live on AWS Amplify, and you’ve successfully deployed it in just a few simple steps. 🎉

[Boost]

Sachith Fernando — Wed, 08 Jan 2025 05:56:51 +0000

Connecting AWS RDS to Spring Boot

Sachith Fernando ・ Dec 8 '24

#aws #mysql #springboot #project

Connecting AWS RDS to Spring Boot

Sachith Fernando — Sun, 08 Dec 2024 13:21:53 +0000

Introduction

In this article, I will walk through the process of setting up an AWS RDS MySQL instance after configuring the security group and connecting it to your Spring Boot application, and testing the connection.

Step 1: Create a New Security Group

Before setting up the RDS instance, you need to ensure that the instance is accessible. You can do this by configuring an AWS Security Group. The security group acts as a virtual firewall to control inbound and outbound traffic.

Access AWS Console: Go to the EC2 Dashboard > Security Groups > Create Security Group.
Inbound Rules:
- Choose the type as MYSQL/Aurora (Becuase I'm planning to use MySQL), which opens port 3306 (MySQL default port).
- Set the Source to My IP then it will automatically get your IP Address to connect with the RDS instance.
Outbound Rules:
- Set to allow all traffic to ensure that the instance can communicate freely with other resources.

Once the security group is set up, move on to configuring the RDS instance.

Step 2: Configure RDS Instance

Choose the Database Engine: In this case, select MySQL.

Choose a Template: For simplicity, you can use the Free tier because I'm going to setup a demo application.

Set Up DB Instance:
- Select Single DB instance (if you don’t require high availability).
- Define DB Instance Identifier, Master Username (I used default name "admin"), and Password.

Choose a DB Instance class:
- I selected db.t3.micro (minimum resources option) because no need more CPU or RAM.

Choose a storage type:
- General Purpose SSD and 20 GB storage value enough for my demo application.

Note : I do not need a specific EC2 instance for this DB because there is no need to allocate compute resources.

After configuring these settings, click on Create Database to start provisioning the RDS instance. It will take a couple of minutes for creation.

Step 3: Configure Spring Boot Application

Now that your RDS MySQL instance is up and running, you can proceed to configure your Spring Boot application to connect to it.

I'm not going to deep dive into Spring boot, I just show a few Java files and configurations to get an idea. If youre new to Spring boot, please get a basic idea about Spring boot applications before that implementation.

3.1. Update application.properties

In your Spring Boot project, you will need to add the necessary database connection details in the application.properties file. The connection will use the endpoint (under the connectivity and security of RDS instance) along with the credentials set during the RDS setup.

spring.application.name=DevOps
spring.datasource.url=jdbc:mysql://<End Point>/devops
spring.datasource.username=admin
spring.datasource.password=<Password>
spring.jpa.hibernate.ddl-auto=update

spring.datasource.url: This is the URL of your RDS instance (replace the host with the actual RDS endpoint you received).
spring.datasource.username: The admin user or the master username you configured during the setup.
spring.datasource.password: The password that you configured for your RDS instance.
spring.jpa.hibernate.ddl-auto: Set to update to automatically update your schema (ideal for development).

3.2. Add MySQL Dependency

Ensure that you have the MySQL driver dependency in your pom.xml for Maven or build.gradle for Gradle.

For Maven:

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>

For Gradle:

implementation 'mysql:mysql-connector-java'

Note : Ensure that you add spring-boot-starter-data-jpa dependency as well.

3.3. Define JPA Entity and Repository

You can now define your JPA entity and the corresponding repository. For example, to create a User entity:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;

    <getters, setters and constructions>
}

And a repository interface:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

Step 4: Create a Simple REST Controller

Create a controller to handle requests related to the User entity. The following code shows how to create a simple POST method for saving user data:

@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @PostMapping
    public String saveUser(@RequestBody User user){
        try {
            userService.saveUser(user);
            return "Success!";
        } catch (Exception e) {
            return e.getMessage();
        }
    }
}

The UserService class handles saving the data to the database.

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;
    public void saveUser(User user) {
        userRepository.save(user);
    }
}

Step 5: Verifying the Connection in MySQL Workbench

You can verify the connection by using MySQL Workbench to connect to the AWS RDS instance. Enter the connection details as follows:

Host: The endpoint of your RDS instance.
Username: The admin username.
Password: The password you set for your database.
Port: 3306.

Once connected, you can browse the databases and tables to confirm that your Spring Boot application is interacting with the MySQL database.

Step 6: Testing with Postman

You can test the POST endpoint using Postman. Send a POST request to http://localhost:8080/user with a JSON body:

{
   "name": "test",
   "email": "test@gmail.com"
}

You should see a response "Success!" if everything is set up correctly.

Conclusion

You have now successfully connected your Spring Boot application to an AWS RDS MySQL instance. By following the above steps, you were able to:

Set up an AWS RDS instance for MySQL.
Configure the necessary security groups for access control.
Connect your Spring Boot application to the RDS instance via JDBC.
Test the setup by sending POST requests through Postman and verifying the database entries.

This setup ensures a seamless and scalable database backend for your Spring Boot application hosted on AWS.

Let me know if you need any further assistance or if you have any ideas to improve the setup!

Thank you!

AWS Elastic Load Balancer: Guide to High Availability and Scalability

Sachith Fernando — Sat, 30 Nov 2024 05:53:26 +0000

In today’s cloud-driven world, where businesses demand resilience, speed, and adaptability, building robust applications is no longer optional, it’s essential. Imagine a bustling airport terminal with passengers arriving from all directions. To keep things running smoothly, traffic needs to be directed, whether to check-in counters, security lines, or gates. AWS Elastic Load Balancer is a powerful service that provides load balancing incoming traffic between multiple targets, which could be instances of EC2, containers, IP addresses, and Lambda. Herein, in this article, I'll give an overview of ELB and its important options to make your choice of load balancer right for your use case.

AWS Elastic Load Balancer automatically distributes incoming application or network traffic across multiple targets in one or more availability zones (AZs). By acting as a traffic distribution layer, ELB enhances fault tolerance, scalability, and availability, ensuring your applications can handle varying levels of demand seamlessly.

So, what are the use cases?? 🧐

It really depends on what type of load balancer you're using. Let's take one-by-one types, and I will give a brief explanation with specific use cases.

1. Application Load Balancer (ALB)

Think of the Application Load Balancer as the ultimate traffic controller for web apps. It specializes in handling HTTP and HTTPS traffic, operating at the application layer to guide incoming requests based on specific details such as finely tuned GPS for your traffic. This makes ALB the go-to choice for modern architectures such as microservices, web applications, and RESTful APIs.

Imagine this: You’re running an e-commerce platform. With ALB, you can easily direct customers to the right microservices. For example, requests to /cart are routed to the shopping cart service, while /checkout requests go straight to the payment system.

Smooth, right?

2. Network Load Balancer (NLB)

Let's talk about the powerhouse of traffic management. Network Load Balancer is purpose-built to handle huge volumes of traffic with incredible speed. Operating at the transport layer, it’s designed for TCP and UDP traffic, and it absolutely shines under pressure, managing low-latency, high-throughput workloads like a pro. In fact, the NLB is so efficient it can scale to handle millions of requests per second without breaking a sweat.

Imagine this: You’re running a real-time gaming platform or managing a financial app where even the tiniest delay is unacceptable. The NLB steps in to ensure every request is processed quickly and reliably, even when traffic surges, such as a tidal wave. It’s the definition of “always-on” performance.

3. Gateway Load Balancer (GLB)

Think of the Gateway Load Balancer as the Swiss Army knife for your traffic. It combines the capabilities of a load balancer and a gateway into one neat solution, making it ideal for scenarios where your traffic needs to pass through virtual appliances like firewalls, intrusion detection systems, or network monitoring tools. It’s all about streamlining complex tasks and doing the heavy lifting for you.

Here’s a scenario: Let’s imagine you’re developing a high-security application where every bit of traffic needs to pass through a virtual firewall for inspection. GLB takes care of routing all that traffic seamlessly, which means no manual intervention is required. It’s built to handle these tasks effortlessly, letting you focus on the bigger picture while ensuring your app stays secure.

So, that’s it about AWS Elastic Load Balancer.

I hope you got something new!

Have a great day!

Securing Your Infrastructure on Amazon EC2

Sachith Fernando — Thu, 31 Oct 2024 12:53:53 +0000

In today's digital age, the security of your infrastructure is more critical than ever. As businesses increasingly rely on cloud services such as Amazon EC2 (Elastic Compute Cloud). Furthermore, understanding how to protect your data and workloads in the cloud is essential. AWS (Amazon Web Services) provides robust security features and best practices to ensure your infrastructure is safe, reliable, and scalable.
This article will walk you through key infrastructure security practices for Amazon EC2. Whether you are a small business owner or a seasoned IT professional, these concepts will help you design a secure and efficient cloud environment.
The security measures for Amazon EC2 infrastructure encompass various aspects to ensure secure and controlled access to your instances, protect data, and maintain isolation. Here’s a breakdown of the key security concepts based on the detailed content provided:

Access Control TLS and Cipher Suites: Access to Amazon EC2 requires clients to support TLS 1.2 or 1.3 and use cipher suites with Perfect Forward Secrecy (PFS), such as DHE or ECDHE. This ensures encrypted and secure communication. API Access: API requests must be signed using an AWS access key ID and secret access key or via temporary credentials from AWS Security Token Service (STS).
Network Isolation Virtual Private Cloud (VPC): Each VPC is a logically isolated network within AWS. You can create separate VPCs to isolate workloads or different parts of an organization. Subnets: Use subnets within a VPC to separate application tiers (web, application, database). Instances can be placed in private subnets if they don’t require direct internet access. PrivateLink: To call Amazon EC2 API via private IPs within a VPC, AWS PrivateLink can be used to keep traffic secure within the AWS network.
Isolation on Physical Hosts Hypervisor Isolation: EC2 instances on the same physical host are isolated through hypervisor technology, which ensures that each instance’s CPU and memory are separate. Data Security: When instances are terminated, their memory is scrubbed, and storage blocks are reset, preventing data leakage. Network Isolation: Instances can only send traffic from their assigned MAC and IP addresses, with non-compliant traffic being dropped.
Controlling Network Traffic Security Groups: Primary mechanism to control access. Define rules to allow minimal and specific traffic, such as from a corporate network or for specific protocols (e.g., HTTPS). Network ACLs: Provide stateless, coarse-grain network control. Can be used as an additional layer of defense to restrict traffic on a subnet level. Private Subnets & Bastion Hosts: For instances in private subnets, use bastion hosts or NAT gateways to manage external connectivity without exposing the instance directly to the internet. VPC Subnet Route Tables: Configure minimal necessary routes to control network access, such as limiting internet access to specific subnets.
Windows-Specific Security Recommendations Windows Firewall & Group Policies: Use Group Policy Objects (GPO) to centrally manage Windows Firewall settings, providing additional control over network traffic. Secure Administration: Secure RDP via SSL/TLS and manage user permissions through Active Directory or AWS Directory Service. Avoid using Domain Admin accounts for daily activities. Configuration Management: Utilize tools like EC2 Run Command, Amazon EC2 Systems Manager (SSM), and PowerShell DSC for managing configurations without direct instance access. Application Layer Restrictions: Use built-in functionalities in Microsoft applications to set network restrictions (e.g., IP range filters in IIS, SQL Server).
Monitoring & Automation VPC Flow Logs: Monitor the network traffic reaching your instances for potential security insights. AWS GuardDuty: Detects suspicious behaviors and malware, helping to identify compromised instances or malicious activity. AWS Security Hub & Analyzers: Services like Reachability Analyzer and Network Access Analyzer can detect unintended network exposure, aiding in continuous security assessment. Secure Remote Access: Utilize AWS Systems Manager Session Manager and EC2 Instance Connect for secure, keyless access to instances. This reduces the need to open SSH or RDP ports.
Additional Security Measures Multiple Network Interfaces: Deploy additional interfaces to separate and audit management traffic from application traffic, enhancing security management. AWS VPN & Direct Connect: Establish private, dedicated connections between your on-premises network and VPC for secure, low-latency communication. These security practices are designed to provide comprehensive protection across various layers, from access and network control to monitoring and configuration management. Following these guidelines ensures that your Amazon EC2 infrastructure remains secure, scalable, and resilient.

Container Image Management Workflow with Amazon ECR

Sachith Fernando — Tue, 17 Sep 2024 04:19:22 +0000

Registry Creation

Each AWS account is automatically provided with a private Amazon ECR registry, where you can store container images such as Docker images. This registry serves as a central hub for managing repositories and images.

Repository Management

Within the registry, users can create multiple repositories. These repositories are designed to store versions of container images and can be configured with repository policies to manage access control. Policies are resource-based and use AWS IAM to control who can push, pull, or manage the images in the repository.

Authentication via Authorization Tokens

To interact with an Amazon ECR repository, a user or application (eg : Amazon EC2 instances) must first authenticate. This authentication is achieved using an authorization token provided by ECR, which is linked to AWS Identity and Access Management (IAM). The authorization token is then passed to the Docker CLI (or another compatible client) to authenticate API requests for pushing or pulling images.

Image Pushing and Pulling

Once authenticated:
Push: Users can upload container images to the repository using Docker commands or other container management tools. These images are stored in the repository with tags indicating their version.
Pull: When an application or service (such as Amazon ECS or Amazon EKS) needs a container image, it can request and retrieve the image from the repository using the image name and tag.

Lifecycle Policies

Repositories often accumulate outdated or unused images, so Amazon ECR provides lifecycle policies to help manage storage. Users can define rules to automate the removal of old or unused images, thus saving storage costs and keeping the repository organized. These policies can be tested before applying, ensuring no valuable images are deleted by accident.

Image Scanning

Security is a major concern with container images. Amazon ECR offers image scanning to identify vulnerabilities in images that are pushed to the repository. This scanning can be automatic (triggered upon image push) or manual (triggered by the user). The scan results provide details about any vulnerabilities found, allowing users to update and patch their images accordingly.

Cross-Region and Cross-Account Replication

ECR enables cross-region replication to allow the same image to be available in multiple AWS regions. This is useful for applications deployed across different geographies. Similarly, cross-account replication allows sharing of images between different AWS accounts while maintaining control over access through repository policies.

Pull-Through Cache

Amazon ECR provides a pull-through cache that allows caching of images from an upstream public registry (e.g., Docker Hub). This cache ensures faster retrieval of images and reduced dependency on the availability or performance of the upstream registry. ECR periodically synchronizes cached images with the upstream registry, ensuring that the images are up to date.

Integration with Other AWS Services

Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service) can both pull images from ECR repositories as part of their deployment process.
AWS Lambda can also use container images stored in ECR to run containerized workloads.
Amazon EC2 and AWS Fargate instances often use ECR to pull images for deployment.

Summary of the Workflow:

User or Service Authentication: A user or service authenticates to the ECR using an authorization token.
Push/Pull Images: Authorized users push container images to the repository or pull images for their services.
Security Measures: Image scanning checks for vulnerabilities.
Maintenance: Lifecycle policies clean up old images to optimize storage.
Scaling: Cross-region and cross-account replication provide scalability, and pull-through caching helps ensure performance.

AWS Security Group Rules

Sachith Fernando — Sun, 25 Aug 2024 12:32:52 +0000

AWS Security Group rules are critical for controlling and securing network traffic to and from your AWS resources. These rules define who can access your instances by specifying allowed IP addresses, protocols, and ports, ensuring that only authorized users and services can connect. This access control is crucial for preventing unauthorized access and potential security breaches, protecting your data and applications.

In addition to access control, Security Groups act as virtual firewalls that manage inbound and outbound traffic, shielding your AWS environment from threats and blocking unwanted or harmful traffic. This layer of security is essential for reducing the risk of breaches and ensuring your resources remain secure.

Security Group rules also play a key role in meeting compliance and security best practices. By enforcing strict access restrictions, they help ensure your infrastructure adheres to industry standards, reducing the risk of compliance issues. Furthermore, Security Groups are easy to configure and manage, allowing you to apply rules to multiple instances simultaneously, which simplifies security management and minimizes the chances of configuration errors.

Components

Here’s a breakdown of each component and its importance:

Type: The type defines the specific protocol to open to network traffic, such as SSH, RDP, HTTP, or HTTPS. This is crucial for controlling what kind of traffic can access your instance, ensuring that only the necessary protocols are exposed, thereby minimizing security risks.
Protocol: The protocol defines the method by which data is transmitted over the network, such as TCP, UDP, or ICMP. Understanding the protocol is important because different types of traffic require different protocols. Configuring the right protocol ensures that your application can communicate correctly while preventing unwanted traffic.
Port Range: The port range specifies which ports are open for the defined protocol. Ports act as gateways for different types of network services, and correctly setting the port range allows the necessary traffic while blocking potentially harmful connections.
Source: The source determines where the traffic originates (for inbound rules) or where it’s sent (for outbound rules). This component is vital for defining who or what can access your resources, allowing you to restrict access to trusted IP addresses or networks, enhancing overall security.

By carefully configuring each of these components, you can create precise rules that ensure only authorized traffic can reach your AWS instances, providing a robust defense against potential security threats.

Exploring Amazon EC2 Instance Purchasing Options

Sachith Fernando — Mon, 15 Jul 2024 14:37:50 +0000

Amazon Elastic Compute Cloud (EC2) offers a variety of instance purchasing options for different needs and budgets. Whether you're looking for flexibility, cost savings, or scalability, there's a suitable option for you. This article will explore the four main EC2 instance purchasing options: On-demand Instances, Reserved Instances (RI), Savings Plans, and Spot Instances.

1. On-demand Instances

On-demand Instances allow you to pay for compute capacity by the second, with no long-term commitments. This option is ideal for users who need compute capacity on a short-term basis, for spiky or unpredictable workloads. Key benefits include:

No Upfront Costs: Pay only for the time your instances are running.
Flexibility: Easily scale up or down based on your application's needs.
No Long-term Commitment: Suitable for short-term, unpredictable workloads.

On-demand Instances are perfect for development and testing environments, or for applications with unpredictable traffic patterns.

2. Reserved Instances (RI)

Reserved Instances offer significant cost savings compared to On-demand Instances, with options to prepay for capacity for one or three years. There are three types of RIs:

Standard RIs: Provide the highest discount, up to 75%, but are less flexible in terms of changing instance attributes.
Convertible RIs: Offer flexibility to change instance types, operating systems, and tenancies, with a slightly lower discount compared to Standard RIs.
Scheduled RIs: Allow you to reserve capacity for specific time periods.

Reserved Instances are ideal for predictable workloads that do not require changes in compute power. They are suitable for applications with steady-state usage, such as databases or business applications.

3. Savings Plans

Savings Plans provide a flexible pricing model, offering significant cost savings. There are two types of Savings Plans:

Compute Savings Plans: These offer the most flexibility, allowing you to change instance families, operating systems, and tenancies, and even shift workloads between regions. They can reduce costs by up to 66%.
EC2 Instance Savings Plans: These apply to specific instance families within a region, offering savings of up to 72%, similar to Standard RIs.

Savings Plans are excellent for long-term workloads and users who need flexibility in their computing needs.

4. Spot Instances

Spot Instances allow you to get spare EC2 capacity, often at significantly reduced prices. Key features include:

Cost Savings: Pay the Spot price, which is often much lower than the On-demand price.
Flexible Start and End Times: Suitable for applications that can handle interruptions.
Termination Notice: Receive a two-minute notice before termination.

Spot Instances are ideal for applications with flexible start and end times, such as batch processing, data analysis, and high-performance computing tasks.

In conclusion, understanding these EC2 instance purchasing options allows you to optimize your AWS costs and tailor your compute capacity to your specific requirements. By selecting the right mix of On-demand, Reserved Instances, Savings Plans, and Spot Instances, you can achieve both cost efficiency and operational flexibility.

Manage Amazon S3 Storage Cost with Lifecycle Rules

Sachith Fernando — Sun, 07 Jul 2024 14:12:54 +0000

Hello World! ✌️

In the last article, we introduced Amazon S3 Storage Classes with use cases. As an extension of that, today we are going to discuss Amazon S3 storage costs with lifecycle rules.

As we talked earlier, Amazon S3 is a durable, scalable, and flexible storage service. It provides options for various kinds of storage classes optimized for cases of frequent access all the way through to archival storage.

Amazon S3 also allows you to set lifecycle rules on how it automatically transitions your objects between the various classes of storage. You can even set expiration dates for object deletion. In this way, it helps you optimize storage costs by automating the movement of objects to the most cost-effective storage class if its access pattern changes over time. A lifecycle rule, in general, comprises two actions: Transition Actions and Expiration Actions.

Let’s dive into these actions and understand how they work using the below image.

Transition Actions

Transition actions are rules that automatically move objects to more cost-efficient storage classes.

In the example image lifecycle policy:

S3 Standard: The object mydoc.pdf is initially stored in the S3 Standard class for the first 30 days. This class is optimized for frequent access with low latency.

S3 Standard-IA: After 30 days, the object automatically transitions to the S3 Standard-IA (Infrequent Access) storage class. This move is more cost-effective for data that is accessed less frequently, as it reduces storage costs while imposing a fee for data retrieval.

S3 Glacier Flexible Retrieval: After another 60 days in S3 Standard-IA, the object transitions to the S3 Glacier Flexible Retrieval storage class. This class is designed for long-term archival where the data is rarely accessed but still needs to be available. The storage cost here is even lower, though retrieval is slower and can take from minutes to hours, with associated costs.

These transitions are automated based on predefined rules, allowing you to optimize storage costs without manual intervention.

Expiration Actions

Expiration actions automatically delete objects after a specified period. This is useful for managing data lifecycle and compliance requirements, ensuring that objects does not incur unnecessary storage costs.

In the example image lifecycle policy:

Deletion: Finally, after 365 days in S3 Glacier Flexible Retrieval, the object is deleted. This expiration action ensures that the object is not kept in the S3 bucket, thus avoiding unnecessary storage costs.

S3 Lifecycle Rules Benefits

Cost Efficiency: You can save a lot of storage costs by migrating data through classes of storage, especially for data that, over time, becomes less frequently accessed.

Automated Management: The lifecycle rules perform automation in data management, hence reducing the need for manual interventions.

Compliance and Governance: The use of Expiration Actions allows for data retention policies and compliance requirements by deleting data automatically when it is no longer needed.

Scalability: One can manage the make of data at scale through S3 lifecycle regulations.

In other words, Amazon S3 Lifecycle Rules provide powerful tools to keep your storage costs optimized among various classes. Understanding and adhering to such rules would ensure that throughout the data's life cycle, it is cost-effectively stored.

Have a great day, and see you soon with another incredible topic!

Amazon S3 Storage Classes

Sachith Fernando — Wed, 26 Jun 2024 01:46:55 +0000

Today, let’s talk about Amazon S3 Storage Classes. It is a super flexible solution from Amazon that caters to different storage needs, data access patterns, and cost considerations. Whether you’re storing frequently accessed data, archival data, or something in between, S3 has got you covered!

What are Amazon S3 Storage Classes? 🧐

Simply put, Amazon S3 offers multiple storage classes that are designed to optimize for different requirements, such as how often you access your data, how fast you need it, and how much you want to spend. Let’s break it down:

1.S3 Standard

This is your go-to storage class for frequently accessed data. It offers:

99.9% availability and 99.9% durability
High throughput and low latency
Perfect for dynamic websites, mobile apps, gaming apps, and big data analytics
However, it comes with a slightly higher storage cost compared to other classes, but the bonus is no retrieval fees.

2. S3 Standard-Infrequent Access (S3 Standard-IA)

If your data is accessed less often but still needs to be quickly retrieved, S3 Standard-IA is a smart pick. Key features include:

Lower storage costs compared to S3 Standard
Retriever fees apply, so plan wisely!
99% availability and 99.9% durability
Use cases? Think backups, long-term storage, or data you don’t need every day but still want handy when you do.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

This class stores your data in a single Availability Zone, making it super cost-effective. But heads up:

It has lower availability (99.5%) and no cross-AZ redundancy.
Perfect for non-critical data or region-specific applications where cost-saving matters more than durability.
If you can afford to lose it or easily reproduce it, S3 One Zone-IA is the way to go!

4. S3 Glacier Flexible Retrieval

Need to stash your data long-term but still want flexible access? Meet S3 Glacier Flexible Retrieval:

Super low storage costs for archival data
Retrieval speeds range from minutes (Expedited) to hours (Standard and Bulk)
Ideal for archive data, regulatory compliance, and disaster recovery
It’s great for those "just-in-case" moments when you need old data but not immediately.

5. S3 Glacier Deep Archive

Now, this is Amazon S3’s lowest-cost storage class. It's perfect for data that rarely gets touched.

Retrieval times can go up to 12 hours, so patience is key! 🤓
Excellent for compliance records or past data you’ll likely never need but can’t delete.
If your data is expected to sit dormant for years, this is your best bet.

6. S3 Intelligent-Tiering

Feeling indecisive? Let S3 Intelligent-Tiering handle it! This class:

Automatically moves your data between frequent and infrequent access tiers based on usage patterns.
Provides 99.9% availability and 99.9% durability.
Saves you money by adjusting storage fees as your access patterns change, and no manual work is required!
It’s the ideal solution for unpredictable data access patterns.

Why Choose Amazon S3 Storage Classes?

Flexibility: A class for every use case and a good solution to high-performance applications and deep archives.
Cost-effectiveness: Pay for what you use, tailored to your data’s access patterns.
Scalability: Whether it’s a few files or millions, S3 handles it like a champ.
So that’s the scoop on Amazon S3 Storage Classes! I hope this helps you pick the perfect one for your needs.

Have a great day, and see you soon with another incredible topic!