DEV Community: Kelvin Onuchukwu

Getting Started with AWS CDK in Python: A Comprehensive and Easy-to-Follow Guide

Kelvin Onuchukwu — Wed, 31 Jul 2024 12:37:39 +0000

A Practical Guide to AWS CDK with Python

The AWS Cloud Development Kit (CDK) is a powerful tool that allows developers to define cloud infrastructure using familiar programming languages. In this guide, we'll focus on using AWS CDK with Python to provision and manage AWS resources. This comprehensive guide will cover everything from setting up your environment to advanced use cases and best practices for CI/CD with CDK.

What is AWS CDK?

AWS CDK is an open-source software development framework that allows you to define your cloud infrastructure using code. Instead of writing lengthy JSON or YAML CloudFormation templates, you can use familiar programming languages like Python, JavaScript, TypeScript, Java, and C#. This approach enables you to leverage the full power of programming languages, such as loops, conditions, and functions, to create reusable and maintainable infrastructure.

Why Use AWS CDK?

Advantages over Terraform

Familiarity: Use your preferred programming language to define infrastructure.
Reusability: Create reusable constructs that can be shared across projects.
Integration: Seamlessly integrate with other AWS services and SDKs.
Modularity: Break down your infrastructure into logical components for better organization and management.
Rich Library: Leverage a rich library of AWS constructs (L1, L2, L3) to simplify complex infrastructure definitions.

Setting Up Your Environment

Prerequisites

Node.js and NPM: CDK CLI is built on Node.js, so you need to have Node.js and npm installed.

   npm install -g aws-cdk

Python: Install Python and set up a virtual environment.

   python3 -m venv .env
   source .env/bin/activate

AWS CLI: Configure AWS CLI with your credentials.

   pip install awscli
   aws configure

Initialize a New CDK Project

Create and Initialize CDK App:

   mkdir my-cdk-app
   cd my-cdk-app
   cdk init app --language python

Install Dependencies:

   pip install -r requirements.txt

Defining Your Infrastructure

Basic Stack Example

Create a new file my_stack.py under the my_cdk_app directory and define your stack.

# my_cdk_app/my_stack.py
from aws_cdk import core
from aws_cdk.aws_s3 import Bucket

class MyStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        bucket = Bucket(self, "MyBucket", versioned=True)

Update app.py to include your stack.

# app.py
from aws_cdk import core
from my_cdk_app.my_stack import MyStack

app = core.App()
MyStack(app, "MyStack")
app.synth()

Synthesizing and Deploying

Synthesize CloudFormation Template:

   cdk synth

Deploy Stack:

   cdk deploy

Cross-Stack References

Share resources between stacks using exports and imports.

Stack A: Define and export the S3 bucket.

# my_cdk_app/stack_a.py
from aws_cdk import core
from aws_cdk.aws_s3 import Bucket

class StackA(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        bucket = Bucket(self, "MyBucket")
        core.CfnOutput(self, "BucketArnOutput", value=bucket.bucket_arn)

Stack B: Import the S3 bucket from Stack A.

# my_cdk_app/stack_b.py
from aws_cdk import core
from aws_cdk.aws_s3 import Bucket

class StackB(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        bucket_arn = core.Fn.import_value("BucketArnOutput")
        imported_bucket = Bucket.from_bucket_arn(self, "ImportedBucket", bucket_arn)

Update app.py to include both stacks.

# app.py
from aws_cdk import core
from my_cdk_app.stack_a import StackA
from my_cdk_app.stack_b import StackB

app = core.App()
stack_a = StackA(app, "StackA")
StackB(app, "StackB")
app.synth()

Advanced Use Cases

Multi-Account and Multi-Region Deployment

Deploy infrastructure across multiple AWS accounts and regions.

# app.py
from aws_cdk import core
from my_cdk_app.my_stack import MyStack

app = core.App()

prod_env = core.Environment(account="123456789012", region="us-west-2")
dev_env = core.Environment(account="987654321098", region="us-east-1")

MyStack(app, "ProdStack", env=prod_env)
MyStack(app, "DevStack", env=dev_env)

app.synth()

CI/CD with CDK

Step 1: Create the CDK Project

Initialize your CDK project if you haven't already.

mkdir my-cdk-app
cd my-cdk-app
cdk init app --language python
pip install -r requirements.txt

Step 2: Define Your Infrastructure

Define the resources you need in your CDK stack.

Example: S3 Bucket Stack

# my_cdk_app/my_stack.py
from aws_cdk import core
from aws_cdk.aws_s3 import Bucket

class MyStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        bucket = Bucket(self, "MyBucket", versioned=True)

Step 3: Add CDK Pipeline Construct

AWS CDK provides a higher-level construct for setting up CI/CD pipelines called CodePipeline. This construct simplifies creating a pipeline with stages for source, build, and deploy.

Example: Pipeline Stack

# my_cdk_app/pipeline_stack.py
from aws_cdk import core
from aws_cdk.pipelines import CodePipeline, CodePipelineSource, ShellStep
from my_cdk_app.my_stack import MyStack

class PipelineStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        pipeline = CodePipeline(self, "Pipeline",
                                synth=ShellStep("Synth",
                                                input=CodePipelineSource.git_hub("my-org/my-repo", "main"),
                                                commands=[
                                                    "npm install -g aws-cdk",
                                                    "python -m venv .env",
                                                    "source .env/bin/activate",
                                                    "pip install -r requirements.txt",
                                                    "cdk synth"
                                                ]))

        pipeline.add_stage(MyApplicationStage(self, "Deploy"))

class MyApplicationStage(core.Stage):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)
        MyStack(self, "MyStack")

app = core.App()
PipelineStack(app, "PipelineStack")
app.synth()

Best Practices

Modularize Your Code:
- Break down your infrastructure into reusable constructs. This promotes code reuse and maintainability.
Use Environment Variables and Context:
- Use context values (cdk.json) and environment variables to manage configuration across different environments.
Leverage CDK Patterns:
- Use higher-level constructs (L3) and patterns to standardize your infrastructure setup.
Testing:
- Implement unit tests for your constructs to ensure correctness.
Documentation and Comments:
- Document your code and provide comments to explain complex logic or configurations.
Use CDK Metadata:
- Add metadata to your constructs to provide additional context and information.
Version Control:
- Use version control for your CDK projects, and version your constructs to manage changes over time.
Follow AWS Best Practices:
- Ensure your infrastructure follows AWS best practices for security, performance, and cost management.

CDK Commands

cdk init: Initializes a new CDK project.

   cdk init app --language python

cdk synth: Synthesizes and generates the CloudFormation template.

   cdk synth

cdk deploy: Deploys the CloudFormation template to AWS.

   cdk deploy

cdk destroy: Destroys the deployed stack.

   cdk destroy

cdk diff: Compares the deployed stack with the local stack.

   cdk diff

cdk bootstrap: Bootstraps the environment to create necessary resources for CDK.

   cdk bootstrap

cdk context: Manages cached context values.

   cdk context

Struct

uring Your CDK Directory

Example Directory Structure

my-cdk-app/
├── app.py
├── cdk.json
├── requirements.txt
├── setup.py
├── README.md
└── my_cdk_app/
    ├── __init__.py
    ├── stack_a.py
    ├── stack_b.py
    ├── constructs/
    │   ├── __init__.py
    │   └── my_construct.py
    └── tests/
        ├── __init__.py
        └── test_stack.py

Explanation

app.py: Entry point of the CDK app where stacks are instantiated.
cdk.json: CDK configuration file.
requirements.txt: Lists Python dependencies.
setup.py: Setup script for the Python package.
README.md: Project description and instructions.
my_cdk_app/: Directory for the CDK application code.
- stack_a.py: Defines Stack A.
- stack_b.py: Defines Stack B.
- constructs/: Directory for reusable constructs.
  - my_construct.py: Example construct.
- tests/: Directory for tests.
  - test_stack.py: Example test file.

Conclusion

AWS CDK with Python provides a powerful and flexible way to define and manage your AWS infrastructure using code. By following best practices, leveraging modular design, and integrating with CI/CD pipelines, you can create scalable, maintainable, and automated infrastructure. This guide has covered the basics and advanced use cases, offering a comprehensive overview of how to get started and succeed with AWS CDK and Python.

By incorporating these elements into your AWS CDK projects, you'll be well-equipped to harness the full power of AWS infrastructure as code, ensuring efficient and reliable deployments in your cloud environments. Happy coding!

Comparing AWS RDS to NoSQL Databases like DynamoDB: When to Use Which

Kelvin Onuchukwu — Wed, 19 Jun 2024 11:33:49 +0000

This post was originally published on Practical Cloud.
Read the unabridged version here.

Amazon Web Services (AWS) provides a range of database solutions to cater to various application needs. Two popular options are Amazon Relational Database Service (RDS) and Amazon DynamoDB, a managed NoSQL database. This comparison highlights the key differences between RDS and DynamoDB, offering guidance on when to use each based on specific use cases and requirements.

Overview of AWS RDS

Amazon RDS is a managed relational database service that supports several database engines, including:

Amazon Aurora
PostgreSQL
MySQL
MariaDB
Oracle Database
Microsoft SQL Server

RDS automates administrative tasks such as hardware provisioning, database setup, patching, and backups, allowing developers to focus on their applications.

Overview of Amazon DynamoDB

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB is designed for applications that require consistent, single-digit millisecond latency at any scale. It is highly available, with built-in support for multi-region and multi-master replication.

Key Differences Between RDS and DynamoDB

Data Model

RDS: Relational database with a structured schema. Data is organized into tables with predefined columns, and relationships between tables are defined using foreign keys.
DynamoDB: NoSQL database with a flexible schema. Data is stored in tables, but each item (row) can have a different set of attributes (columns). This allows for more flexible and dynamic data structures.

Query Language

RDS: Uses SQL (Structured Query Language) for querying and managing data. SQL is a powerful and expressive language that supports complex queries, joins, and transactions.
DynamoDB: Uses a proprietary query language called PartiQL, which is a SQL-compatible query language for querying DynamoDB tables. While PartiQL supports basic SQL-like queries, it does not support complex joins or transactions as SQL does.

Consistency Model

RDS: Supports strong consistency by default. Transactions and ACID (Atomicity, Consistency, Isolation, Durability) properties are fully supported, making RDS suitable for applications that require reliable and consistent data integrity.
DynamoDB: Offers two consistency models:
- Eventual Consistency: Read operations might not immediately reflect the results of a recently completed write operation.
- Strong Consistency: Ensures that read operations always reflect the latest write operations.

Scalability

RDS: Vertical and horizontal scaling:
- Vertical Scaling: Increase the instance size (CPU, memory) or storage capacity.
- Horizontal Scaling: Use read replicas for read-heavy workloads.
DynamoDB: Horizontal scaling by design. DynamoDB automatically partitions data and spreads the load across multiple servers. It can handle virtually unlimited throughput and storage capacity.

Performance

RDS: Performance depends on the instance type, storage configuration, and database engine tuning. It can handle complex queries and transactions efficiently but might require careful management and optimization.
DynamoDB: Designed for high performance with low latency at any scale. It is optimized for key-value and document data models, providing consistent performance even under high load.

Use Cases

When to Use RDS

Transactional Applications: Applications that require ACID transactions, such as financial systems, order management, and inventory systems.
Complex Queries and Joins: Use cases where complex SQL queries, joins, and data relationships are essential, such as business intelligence and reporting.
Relational Data Models: Applications that benefit from a structured schema with well-defined relationships between entities, such as CRM systems and content management systems.

When to Use DynamoDB

High-Throughput and Low-Latency Applications: Applications that require consistent, single-digit millisecond latency and can scale horizontally, such as gaming leaderboards, real-time bidding, and IoT applications.
Flexible Schema Requirements: Use cases where the data model evolves frequently, and a fixed schema is restrictive, such as user profile stores and content recommendation systems.
High Availability and Multi-Region Replication: Applications that need to be highly available with seamless multi-region replication, such as global e-commerce platforms and distributed applications.

Cost Considerations

RDS: Costs are based on instance type, storage, and I/O operations. It can become expensive as the instance size and storage requirements increase, especially for high-availability setups with Multi-AZ deployments and read replicas.
DynamoDB: Pricing is based on the provisioned throughput (read and write capacity units) and storage used. DynamoDB offers on-demand pricing, which can be cost-effective for workloads with variable traffic patterns.

Management and Maintenance

RDS: AWS manages the underlying infrastructure, including hardware provisioning, patching, backups, and automated failover. However, database tuning and optimization are the user's responsibility.
DynamoDB: Fully managed service with minimal maintenance requirements. AWS handles all aspects of infrastructure management, including scaling, replication, and backups.

Detailed Use Cases

RDS Use Cases

E-commerce Platforms:
- RDS is ideal for handling transactional operations, product catalogs, and user orders. The relational model supports complex queries for inventory management and customer relationship management.
Enterprise Resource Planning (ERP):
- ERPs require robust data integrity and complex relationships between entities like suppliers, customers, and inventory. RDS supports the transactional requirements and complex queries needed in ERP systems.
Financial Applications:
- Banking and financial applications need strong consistency and ACID transactions to ensure data accuracy and integrity. RDS's support for transactions and relational models makes it suitable for these applications.

DynamoDB Use Cases

Real-Time Data Processing:
- Applications like real-time bidding, gaming leaderboards, and live event tracking benefit from DynamoDB's low latency and high throughput. The flexible schema allows for rapid iteration and updates to data models.
Internet of Things (IoT):
- IoT applications generate massive amounts of data that need to be ingested and queried quickly. DynamoDB's ability to scale horizontally and handle high write and read rates makes it ideal for IoT data storage and processing.
Content and User Personalization:
- DynamoDB is well-suited for storing user profiles, session data, and personalized content recommendations. Its flexible schema allows for storing diverse attributes and evolving data models without downtime.

Conclusion

Choosing between AWS RDS and Amazon DynamoDB depends on your application's specific requirements:

Use RDS when you need strong consistency, ACID transactions, complex queries, and a relational data model.
Use DynamoDB for applications requiring high throughput, low latency, flexible schemas, and horizontal scalability.

Understanding the strengths and limitations of each service will help you make an informed decision and design a robust and efficient database architecture for your application.

Comprehensive Guide to AWS API Gateway: Everything You Need to Know - Part I

Kelvin Onuchukwu — Wed, 12 Jun 2024 10:25:47 +0000

AWS API Gateway is a powerful service that allows you to create, publish, manage, and secure APIs with ease. Whether you're building RESTful APIs, WebSocket APIs, or HTTP APIs, API Gateway provides a range of features and functionalities to streamline API development, authentication, authorization, documentation, and monitoring. In this comprehensive guide, we'll dive deep into different aspects of AWS API Gateway, covering key concepts, best practices, use cases, and implementation strategies.

This is the first part of a two-part series. Read the second part here.

1. Introduction to AWS API Gateway

Comprehensive Guide To AWS API Gateway
AWS API Gateway is a fully managed service that allows you to create, deploy, and manage APIs at scale. It acts as a front-door for your backend services, enabling clients to access your APIs securely and efficiently. With API Gateway, you can build RESTful APIs, WebSocket APIs, and HTTP APIs, leverage serverless computing with AWS Lambda integrations, implement authentication and authorization mechanisms, monitor API usage and performance, and generate interactive API documentation.

2. API Gateway Features and Components

Integration Types
AWS API Gateway supports multiple integration types to connect your API methods with backend services, AWS resources, Lambda functions, HTTP endpoints, and external APIs. The key integration types in API Gateway include:

HTTP Integration:
Integrates API Gateway with HTTP/HTTPS endpoints such as web services, microservices, and external APIs.
Supports standard HTTP methods (GET, POST, PUT, DELETE) and custom headers, query strings, and payloads.
Allows seamless communication between API Gateway and backend HTTP services for data exchange and processing.
AWS Lambda Integration:
Integrates API Gateway with AWS Lambda functions for serverless computing, event-driven processing, and backend logic.
Executes Lambda functions in response to API requests, passing event data, headers, and payloads to Lambda.
Enables serverless API endpoints, dynamic content generation, and scalable compute resources.
AWS Service Integration:
Integrates API Gateway with AWS services such as AWS DynamoDB, AWS S3, AWS Step Functions, AWS SQS, and AWS SNS.
Enables direct API access to AWS resources, data storage, messaging services, workflow orchestration, and event-driven workflows.
Utilizes AWS IAM roles and policies for secure access control and resource permissions.
Mock Integration:
Provides mock responses and simulations for API methods without actual backend integrations.
Useful for API testing, development, prototyping, and simulating various API responses.
Allows developers to define mock responses, status codes, headers, and payloads for API endpoints.
HTTP Proxy Integration:
Acts as a reverse proxy for HTTP/HTTPS requests, forwarding requests to backend services and routing responses back to clients.
Supports path-based routing, URI rewriting, header forwarding, and response transformation.
Enables API Gateway to proxy requests to backend HTTP services, legacy systems, or external APIs.
Lambda Proxy Integration:
Integrates API Gateway with Lambda functions using Lambda proxy integration for direct Lambda invocation and response handling.
Passes entire API requests (including path parameters, query strings, headers, and payloads) to Lambda as event data.
Simplifies API Gateway configuration, reduces overhead, and improves performance for Lambda-based APIs.
Integration Requests and Responses
AWS API gateway Integration requests and responses
Integration requests and responses in API Gateway define the format, structure, transformation, and mapping of data between API Gateway and backend integrations. Key aspects of integration requests and responses include:

Request Mapping Templates:
Define request mapping templates to transform incoming API requests into backend integration requests.
Use Velocity Template Language (VTL) to manipulate headers, parameters, payloads, and data formats.
Implement data mappings, transformations, conditional logic, and error handling in request templates.
Response Mapping Templates:
Define response mapping templates to transform backend integration responses into API Gateway responses.
Use VTL to format, filter, map, and transform backend response data for client consumption.
Handle status codes, headers, error messages, and response structures in response templates.
Data Mapping and Transformation:
Map request parameters, path variables, query strings, headers, and payloads to backend integration data.
Transform data formats (e.g., JSON, XML, form data) between API Gateway and backend services.
Implement data validation, serialization, deserialization, and content negotiation in integration mappings.
Payload Encoding and Decoding:
Encode and decode request/response payloads using standard encoding schemes (e.g., base64, URL encoding).
Handle binary data, multipart/form-data, and content encoding for API Gateway integrations.
Configure payload transformations, size limits, and content-type conversions for data exchange.
Response Handling and Error Management:
Handle backend integration responses, status codes, headers, and error messages in API Gateway.
Map backend errors to API Gateway error responses, error codes, and error handling behavior.
Implement response transformations, caching directives, and content negotiation for API clients.
Method Requests and Responses
AWS API gateway Method reponses and requests
Method requests and responses in API Gateway define the input parameters, request models, response models, validation rules, and error handling for API methods. Key aspects of method requests and responses include:

Request Parameters and Models:
Define method request parameters (e.g., path parameters, query strings, headers, body parameters) for API methods.
Specify request models, schemas, and validation rules using JSON Schema or OpenAPI Specification (Swagger).
Validate input data, enforce data types, and handle missing or invalid parameters in method requests.
Response Models and Content Negotiation:
Define method response models, schemas, and content types for API method responses.
Specify response data formats (e.g., JSON, XML), data structures, and validation rules.
Implement content negotiation, response encoding, and media type selection based on client preferences.
Request Validation and Error Handling:
Validate method requests against defined request models, schemas, and validation rules.
Handle request validation errors, missing parameters, invalid input data, and parameter constraints.
Define custom error responses, error codes, error messages, and error handling behavior for API methods.
Response Formatting and Mapping:
Format method responses based on defined response models, content types, and media types.
Map backend integration responses to API method responses using response mapping templates.
Implement response transformations, data mappings, and content negotiation for API clients.
Practical Scenario: Transforming Responses from a Step Functions orchestration to an API Gateway
To transform responses from the step functions service, you configure the integration response in API Gateway to transform a response from an AWS Step Function connected to API Gateway.

Here's a breakdown of the functionalities:

Integration Response: This setting controls how API Gateway handles the response it receives from the backend service (in this case, the Step Function). You can use a mapping template to modify the response body, headers, and status code before passing it on to the client.
Method Response: This setting defines the format of the response that the API Gateway method itself will return to the client. It specifies the HTTP status code, response parameters, and response models. While method responses are useful for defining the expected API output, they are not the primary way to transform a response from a backend integration.
In essence, the integration response acts as an intermediary, allowing you to manipulate the Step Function's output before it reaches the client via the method response.

Here's how integration and method responses work together in API Gateway:

Client Request: A client sends a request to your API Gateway endpoint.
Integration: API Gateway forwards the request (possibly with transformations) to your backend service (the Step Function in this case).
Backend Response: The Step Function processes the request and returns a response.
Integration Response: This is where the transformation happens. You can use a mapping template in the integration response to modify the Step Function's response data (body, headers, status code) before passing it on.
Method Response (Optional): API Gateway uses the configured method responses to define the final format of the response sent back to the client. This includes:
HTTP Status Code: Defines the success or error code (e.g., 200 for success, 404 for not found).
Response Parameters: Specifies additional headers you want to include in the response.
Response Models: Defines the expected structure of the response body using pre-defined models in API Gateway. This is helpful for generating client-side SDKs for your API.
Since you're transforming the response in the integration response for the Step Function scenario, you don't necessarily need a method response. However, method responses are useful in several situations:

Default Responses: Define common response formats for success (200) and error conditions (400, 500, etc.) across your API. This provides consistency for developers using your API.
Customizing Headers: You might want to add specific headers not present in the backend response (e.g., API Gateway throttling information).
Response Model Validation: Define a model for the expected response body structure. This helps validate the backend's response data and ensures consistency. This is particularly beneficial when generating client-side SDKs for your API.
To summarize, integration responses offer flexibility to manipulate data directly from the backend service. Method responses define the public interface of your API, specifying what developers can expect in the final response. You can leverage both for a more controlled and well-defined API experience.

3. Best Practices for API Gateway

Security Best Practices
Implement HTTPS for secure API communication and data encryption.
Use API keys, IAM roles, and custom authorizers(Lambda Authorizer or Cognito Authorizer) for authentication and access control.
Secure sensitive data, headers, and payloads using encryption and access policies.
Implement rate limiting, throttling, and usage plans to prevent abuse and control API usage.

Performance Optimization
Use caching, content delivery networks (CDNs), and response compression for performance optimization.
Minimize round-trip times, reduce latency, and optimize integration execution for faster responses.
Implement asynchronous processing, batch operations, and parallel execution for scalable API performance.

Scalability Strategies
Design scalable APIs with distributed architectures, stateless services, and horizontal scaling capabilities.
Use AWS Auto Scaling, Lambda concurrency controls, and caching to handle varying loads and traffic spikes.
Implement load balancing, fault tolerance, and distributed caching for high availability and resilience.

API Versioning and Lifecycle Management
Implement API versioning strategies, backward compatibility policies, and version control for API evolution.
Use API Gateway stages, deployment slots, and version aliases for seamless API deployment and testing.
Manage API lifecycle stages, deprecations, retirements, and sunset policies for legacy APIs.

CI/CD Integration and Deployment
Integrate API Gateway with CI/CD pipelines, version control systems, and deployment automation tools.
Use AWS CodePipeline, AWS CodeBuild, and AWS SAM (Serverless Application Model) for automated API deployment.
Implement continuous integration, continuous deployment, and infrastructure as code (IaC) for API lifecycle management.

Cost Optimization and Resource Management
Monitor API usage metrics, performance metrics, and cost metrics for cost optimization.
Optimize resource utilization, capacity planning, and resource scaling based on usage patterns.
Use AWS Budgets, AWS Cost Explorer, and resource tagging for cost allocation and budget management.

4. Final Thoughts and Future Trends

In conclusion, AWS API Gateway is a comprehensive platform for building, deploying, and managing APIs with agility, scalability, security, and performance. By leveraging integration types, integration requests and responses, method requests, and method responses, you can design robust APIs, connect with backend services, and deliver seamless experiences for API consumers. As organizations continue to adopt cloud-native architectures, serverless computing, and digital transformation initiatives, AWS API Gateway will play a crucial role in enabling API-driven innovation, real-time communication, and scalable solutions. Looking ahead, future trends in API Gateway may include enhanced integration capabilities, AI-driven API management, event-driven architectures, API monetization, and ecosystem collaboration, shaping the future of API-driven development and digital ecosystems.

Happy Clouding !!!

Optimising Your Cloud Spend: Top Strategies for AWS Cost Management

Kelvin Onuchukwu — Thu, 06 Jun 2024 00:22:55 +0000

Visit my blog PracticalCloud for more indepth cloud computing articles.

In today's cloud-driven world, businesses are increasingly migrating to AWS to leverage its scalability, agility, and wide range of services. However, managing cloud costs effectively is essential to ensure you're getting the most out of your AWS investment. In this article, we will explore several key strategies for optimizing your AWS costs and maximizing your return on investment (ROI).

Understanding AWS Pricing

Before diving into cost optimization strategies, it’s crucial to understand how AWS pricing works. AWS uses a pay-as-you-go model, which means you only pay for the services you use. However, the complexity of AWS pricing can make cost management challenging. Here are the main components to consider:

Compute Costs: Charges for virtual servers (EC2 instances), Lambda executions, etc.
Storage Costs: Charges for data storage (S3, EBS, etc.) and data transfer.
Data Transfer Costs: Charges for data moving in and out of AWS.
Miscellaneous Costs: Charges for additional services like RDS, CloudFront, etc.

Top Strategies for AWS Cost Management

Right-Sizing Your Instances Right-sizing involves matching instance types and sizes to your workload’s needs. Over-provisioning resources leads to unnecessary costs, while under-provisioning can impact performance.

How to Right-Size:

Analyze Usage Patterns: Use AWS CloudWatch and Cost Explorer to analyze your instance usage and performance.
Choose the Right Instance Types: AWS offers various instance types optimized for different workloads (compute-optimized, memory-optimized, etc.).
Utilize Auto Scaling: Set up Auto Scaling to automatically adjust capacity to maintain steady, predictable performance at the lowest possible cost.

Leverage AWS Savings Plans and Reserved Instances AWS offers Savings Plans and Reserved Instances (RIs) for long-term commitments, which can significantly reduce costs.

Savings Plans vs. Reserved Instances:

Savings Plans: Flexible pricing plans offering savings over on-demand pricing, applicable across any region and instance family.
Reserved Instances: Offer significant discounts (up to 75%) compared to On-Demand pricing in exchange for a commitment to use AWS for a 1- or 3-year term.
How to Use Them:

Analyze Historical Usage: Use Cost Explorer to identify stable workloads that can benefit from long-term commitments.
Choose the Right Plan: Based on your usage pattern, select either a Compute Savings Plan or an EC2 Instance Savings Plan.
Regular Review: Periodically review and adjust your reservations to match your evolving workload.

Utilize Spot Instances Spot Instances offer unused EC2 capacity at up to 90% discount compared to On-Demand prices. They are ideal for flexible, stateless, and fault-tolerant workloads.

Best Practices for Spot Instances:

Spot Fleet: Use Spot Fleet to automate the allocation and management of Spot Instances.
Instance Interruption Handling: Implement fault-tolerant design patterns to handle potential Spot Instance interruptions.
Combine with On-Demand and RIs: Use a mix of Spot, On-Demand, and Reserved Instances for optimal cost savings and reliability.

Monitor and Optimize Storage Costs Storage costs can quickly escalate if not properly managed. AWS provides tools and best practices to optimize storage expenses.

Strategies for Storage Optimization:

S3 Lifecycle Policies: Automate transitioning of objects to lower-cost storage classes (e.g., from S3 Standard to S3 Glacier) based on their lifecycle.
Delete Unused Data: Regularly audit and delete unused or old data.
Optimize EBS Volumes: Identify and delete unused EBS volumes, take advantage of EBS volume types that best match your performance and cost needs.

Implement Cost Allocation and Tagging Cost allocation and tagging allow you to track and manage AWS costs by associating them with different departments, projects, or teams.

How to Implement Tagging:

Define a Tagging Strategy: Establish a consistent tagging strategy across your organization.
Use AWS Cost Allocation Tags: Tag resources with cost allocation tags to categorize and track costs.
Leverage Cost Explorer and AWS Budgets: Use these tools to analyze tagged resources and monitor spending.

Use AWS Cost Management Tools AWS provides several tools to help you manage and optimize your cloud spend:

AWS Cost Explorer: Visualize, understand, and manage your AWS costs and usage over time.
AWS Budgets: Set custom cost and usage budgets and receive alerts when you exceed them.
AWS Trusted Advisor: Provides real-time guidance to help you optimize your AWS infrastructure, improve security, and reduce costs.
Scenario-Based Cost Optimization Examples

Scenario 1: Seasonal Traffic Spikes

Problem: An e-commerce website experiences high traffic during holiday seasons.
Solution: Use Auto Scaling to automatically adjust the number of instances based on traffic. Leverage Spot Instances during peak hours to save costs and Reserved Instances for baseline capacity.

Scenario 2: Development and Testing Environments

Problem: Development and testing environments are running 24/7, leading to high costs.
Solution: Implement start/stop schedules for non-production instances using AWS Instance Scheduler. Use Spot Instances for testing workloads that can tolerate interruptions.

Scenario 3: Data Analytics and Big Data Processing

Problem: High costs associated with big data processing.
Solution: Use S3 Lifecycle policies to move old data to cheaper storage classes. Leverage Spot Instances for data processing jobs. Use Amazon Athena for cost-effective querying of data stored in S3.

Optimizing AWS costs is crucial for maximizing the value of your cloud investment. By understanding AWS pricing and employing strategies such as right-sizing, leveraging Savings Plans and Spot Instances, monitoring storage costs, implementing cost allocation and tagging, and using AWS cost management tools, you can significantly reduce your cloud spend. Regularly review and adjust your strategies to align with your evolving workloads and business needs. With these best practices, you'll be well on your way to mastering AWS cost management.

Advanced End-to-End DevOps Project: Deploying A Microservices APP To AWS EKS

Kelvin Onuchukwu — Sat, 10 Feb 2024 13:11:00 +0000

This post was originally publised at Practical Cloud

DevOps is a rapidly evolving space in the IT industry. As a DevOps engineer, it is paramount to keep up with the space of developments to avoid beign left behind.

One popular paradigm that has evolved to maturity in this field is GitOPs.

GitOps is a DevOps framework or practice whereby we make our Git repository a single source of truth whilst applying CI/CD and version control to infrastructure automation.
Red Hat defines it as "using Git repositories as a single source of truth to deliver infrastructure as code."

DevSecOps on the other hand is a new and improved version of DevOps that inculcates security tools and controls within the SDLC(software development life-cycle). The main goal of devsecops methodology is “shifting security left” i.e. security should be a part of the development lifecycle from the very beginning rather than being an afterthought.

In this project guide, we will be applying GitOps practices while implementing an advanced end-to-end DevSecOps pipleine that incorporates many tools.

Project Overview

This is a two-part project. In the first part we will be setting up our EC2 instances on which the CI pipeline will run.

To learn how to build a standard continuous integration pipleine with jenkins, click here.

In the second part, we will set up the EKS Cluster, ArgoCD for Continuous Delivery and configure Prometheus and Grafana for application monitoring.

In this project, we will be covering the following:
- Infrastructure-as-Code: We will use terraform to provision our EC2 instances as well as the EKS Cluster.

- Jenkins Server Configuration: Install and configure essential tools on the Jenkins server, including Jenkins itself, Docker, OWASP Dependency Check, Sonarqube, and Trivy.

- EKS Cluster Deployment: Utilize Terraform to create an Amazon EKS cluster, a managed Kubernetes service on AWS.

- Load Balancer Configuration: Configure AWS Application Load Balancer (ALB) for the EKS cluster.

- ArgoCD Installation: Install and set up ArgoCD for continuous delivery and GitOps.

- Sonarqube Integration: Integrate Sonarqube for code quality analysis in the DevSecOps pipeline.

- Monitoring Setup: Implement monitoring for the EKS cluster using Helm, Prometheus, and Grafana.

- ArgoCD Application Deployment: Use ArgoCD to deploy the microservices application, including database and ingress components.

PART I: Setting Up The CI Pipeline

- Step 1: Provision The EC2 Instance
Clone the Git repository.

cd into the terraform directory.

Run terraform init, after that run terraform plan to see proposed infrastructural changes.

Run terraform apply to effect these changes and provision the instance.

The instance is bootstraped with user-data that will automatically install jenkins, sonarqube, trivy and docker once it is provisioned.

- Step 2: Modify The Application Code

This is a simple yet crucial step. In the Jenkinsfile contained in the repository you just cloned, you must change all occurances of "kelvinskell" to your DockerHub username. This is very necessary if you want to implement this project on your end.

- Step 3: Configure The Jenkins Server

On the browser, login to the jenkins server.

Install suggested plugins and complete the registration.
Go to Manage Jenkins, Plugins,and install the following plugins: Docker, Docker Commons, Docker pipeline, SonarQube Scanner, Sonar quality gates, SSH2 Easy, OWASP dependency check, OWASP Markup Formatter Plugin, GitHub API pluin and GitHub pipeline plugin.

Configure tools: Go to Dashborad > Manage jenkins > Tools Git Installation

Sonar Scanner Installation

Dependency Check

Docker Installation

- Step 4: Configure SonarQube

On the browser, connect to your Jenkins server IP address on port 9000 and the log in to the server. The default username and password is "admin".

Once you log in, click on "Manually".

Follow the directions in the image above, then click on "set up".
NB: Your project key has to exactly be newsread-microservices-application. That way, you won't have to edit the Jenkinsfile.

Select "With Jenkins" and choose GitHub as the DevOps platform.

Click on Configure analysis, on step 3, copy the "sonar.projectKey", you will be needing it later.

Click on "Account" > "My Account" > "Generate token". Give it a name and click on "generate".

Go to "Manage Jenkins" > "Credentials"
Select secret tex and paste in the token you just copied.

Now go to Jenkins Dashboard > Configure Jenkins > System > Sonarqube Server > Add Sonarqube
Give it the name "SonarQube Server", enter the server url and credential ID for the secret token. Notice here that our server url is localhost, since SonarQube is hosted on the same server as jenkins.

click on "Save".

- Step 5: Integrate your DockerHub Credentials

This stage is essential for Jenkins to have access to your DockerHub account.

Go to "Manage Jenkins" > "Credentials" > "Add Credentials"

- Step 6: Configure The Jenkins Pipeline

From Jenkins' dashboard, click New Item and create a Pipeline Job.

Under Build Triggers, choose Trigger builds remotely.

Set a secret token under the "Authentication Token" box. We will use it when creating a GitHub Webhook.

Under Pipeline, make sure the parameters are set as follows:
- Definition: Pipeline script from SCM
- SCM: Configure your SCM. Make sure to only build your main branch. For example, if your main branch is called "main", put "*/main" under Branches to build.
- Script Path: Jenkinsfile

NB You have to fork my repository into your own GitHub account. This is necessary for you to have acess to repository and able to configure it.
Once this has been done, create a GitHub Personal Access Token.

We will use the GitHub PAT to authenticate to our repository from Jenkins.

Connect to the EC2 instance, switch to the jenkins user, create an SSH key-pair. The public key will be uploaded to GitHub as your PAT, while the private key will be added in our Jenkins configuration.

Back on the Jenkins server, click on "Add credential"

The error message has now disappeared.

Click on "Save".

- Step 7: Create A GitHub WebHook

This is necessary for trigerring our jenkins builds remotely.

Go to the GitHub Webhook creation page for your repository and enter the following information: URL: Enter the following URL, replacing the values between *** as needed:



***JENKINS_SERVER_URL***/job/***JENKINS_JOB_NAME***/build?token=***JENKINS_BUILD_TRIGGER_TOKEN***

- Step 8: Execute The Pipeline
Now, we are done configuring this pipeline. It is time to test our work.
You can either trigger the pipeline by making a change and pushing to your GitHub repository. If the web hook trigger is properly configured, this will automatically start the pipeline.

Alternatively, you can simply click on "Build now" to execute the pipeline.

If everything is configured as they should, you will get this output:

Conclusion

We have now come to the end of the first part of this project. In this first part, we configured and set up the continuous integration pipeline. The second part will involve implementing GitOps using ArgoCD.

We will provision an EKS cluster using terraform, then use ArgoCD for contuinuous deployment to the EKS Cluster.

The idea here is that you can have seperate teams managing the two parts of the process - continuous integration and continuous deployment. Thus further decoupling and streamlining the whole process while using Git as our single source of truth.

PS: I am open to remote DevOps, Cloud and technical writing offers.
Connect with me on LinkedIn.

Advanced Terraform: Getting Started With Terragrunt

Kelvin Onuchukwu — Fri, 19 Jan 2024 23:59:16 +0000

This post was originally published at Practical Cloud

View the longer, original version here

What Is Terragrunt?

Terragrunt is an open source tool developed by GruntWork that helps to reduce code duplication accross your Terraform projects - effectively keeping your terraform code DRY.

DRY is a popular acronym which means Do not Repeat Yourself.

Terragrunt can be used to manage Terraform code across multiple enviornments, multiple AWS accounts, handling dependency management, custom actions and versioning.

Terragrunt simplifies the management of multiple environments by providing a clear separation between them.
Terragrunt hooks can be used to perform actions before or after Terraform commands.

Terragrunt can be integrated with your CI/CD pipelines for automated infrastructure deployment.

Terragrunt is able to integrate with external secret management tools like Hasicorp Vault or AWS Secrets Manager for managing sensitive data.

In fact, you can use Terragrunt commands in place of basic terrafrom comands.

terragrunt init
terragrunt plan
terragrunt apply
terragrunt output
terragrunt destroy

Terragrunt lets you specify the IAM role to use. You can do this by using the _--terragrunt-iam-role_ CLI argument or the TERRAGRUNT_IAM_ROLE environmental variable. Terragrunt will call the sts-assume-role API and then expose the credentials it receives as environmental variables when invoking terraform. This makes it possible to seamlessly deploy infrastructure across different environments without having to store AWS credentials in plaintext.

Installing Terragrunt

To install terragrunt, make sure you have alredy installed terraform beforehand.

Follow this link to install terraform.
Download the Terragrunt binary from the releases page.
Select the correct binary for your OS.
Copy the link and download on your terminal using the wget command. Example: wget https://github.com/gruntwork-io/terragrunt/releases/download/v0.54.19/terragrunt_linux_amd64
Rename the binary to terragrunt: mv terragrunt_linux_amd64 terragrunt
Make the file executable: chmod u+x terragrunt
Move the file to the /usr/local/bin directory: `sudo mv terragrunt /usr/local/bin/terragrunt'
To verify your installation, run: terragrunt --version.

A Case Study

Let us now present a scenario for managing infrastructure with Terragrunt.

The following is a sample terraform code for creating an EC2 instance using Terraform.

`
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}

required_version = ">= 1.2.0"
}

provider "aws" {
region = "us-west-2"
}

resource "aws_instance" "app_server" {
ami = "ami-830c94e3"
instance_type = "t2.micro"

tags = {
Name = "ExampleAppServerInstance"
}
}
`

The probelm is, how do you create this instance across several environments?

Ordinarily, you would want to duplicate the same code for each environment and then modify the parameters.
You might wish to specify different instance types for each environment. For example, you might want to use a t2.micro instance for development environment, a t3.medium for test environment and a t2.large for production.

The probelm is that this would be a very manual process -inefficient and leaves plenty room for error. Using Terragrunt, we can improve thiscode without having to copy and paste the code across several environments.

Also these environments might be spread out across diffrent AWS accounts and you'd also have to worry about managing the different AWS credentials and IAM roles required.
The terraform backend does not support variables or any type of expression whatsoever. So you would have to manually copy and edit the backend configuration code for each of the environments.

Working With Terragrunt

First we need to create seperate directories for each of the enviornments. In each of the directories, a terragrunt.hcl file will be created. This is the configuration file for each of the environments.

Your directory structure should look like this:

First, we have to define a terraform block and declare the source of our EC2 module.

`
terraform {
source = "tfr:///terraform-aws-modules/ec2-instance/aws?version=5.6.0"
}

` Now let's define a provider. `
generate "provider" {
path = "provider.tf"
if_exists = "overwrite_terragrunt"
contents = <<EOF
provider "aws" {
profile = "default"
region = "us-east-1"
}
EOF
}
`
Now we need to declare an inputs block. This is where most of the magic of terragrunt happens.

we can simply define one terraform code for all our environments and then use the inputs block to change values as reuired across all the environments.

inputs = { ami = "ami-0005e0cfe09cc9050" instance_type = "t2.micro" tags = { Name = "grunt-ec2" } }
What is happening here is that the instance type, ami and tags are values that are intended to differ based on the environment.

My terragrunt.hcl file now looks like this:

I have replicated this in my test directory with a few changes. The instance type is t2.medium, the tags have also been modified to reflect the environment.

The terragrunt.hcl file in my test environment looks like this:

The next stage is to execute terragrunt commands to read our configuration and invoke terraform with it.

Switch to the dev directory.
First, run terragrunt init.
Now run terragrunt plan to see proposed infrastructure changes. This is how mine looks:

Run terragrunt apply to actually create the instance.

Repeat the steps above for the test environment.

Final Thoughts

If you followed this tutorial until now, I'm sure you must have begun to see the importance of terragrunt and how it helps manage terraform code acoss different environemnts while keeping your terraform code DRY.

What Is AWS AppConfig?

Kelvin Onuchukwu — Tue, 18 Jul 2023 11:23:24 +0000

This post was originally published at Practical Cloud
This is an abridged version.

View the longer, original version here.

AppConfig is a service offering from AWS that helps you to efficiently create, manage and deploy your application configurations without altering your application code.

In a nut shell, AppConfig helps you to dynamically change values without redeploying your application. Thereby eliminating downtime or service disruptions.
AppConfig seamlessly integrates with applications running on EC2 instances, Lambda, Containers, Mobile apps and IOT devices.

Use Cases For AppConfig

Feature Flags: Feature flags are a concept in software development that allows you to enable or disable features in your application without modifying source code or redeploying your application. A feature of an application can be delivered to production in an inactive form by hiding it behind a feature flag. With AWS AppConfig, we can turn these features on at any specified time, making them available to either a selected group of users or to all users.
Application tuning: With AWS AppConfig, you can change the behavior of your application on the fly. You can for instance, save timeout settings in your configuration data and alter them when needed, without needing to change your source code or restarting the application. Similarly, a DevOps engineer can increase or reduce the verbosity of the application logs without needing to redeploy the application.
Whitelisting or Blacklisting: AppConfig enables you to expose certain features of your application to a select group of users, using a dynamic allow-list. You can conversely block a group of users from viewing your application by creating a deny-list. This is useful if you want some features of your application to only be available to paying customers.

Why Use AppConfig?

AppConfig enables controlled deployment of configurations to applications, allowing you to swiftly and safely manage configurations. You can simply turn features on or off without having to redeploy or restart your application.
AppConig can protect you against costly configuration mistakes that can cause application downtime.With built-in validation checks, you can ensure your configurations are always syntactically valid and devoid of any errosr.
AppConfig gives you the ability to safely deploy changes using progressive rollouts and rollback alarmas. By integrating with CloudWatch alarms, AppConfig will monitor the application to see that deployment is successful. If errors are encountered and alarms go off, it will automatically rollback any configuration changes.
AppConfig enables auditablity by providing a change log where you can view your update history.

How To Use AppConfig

To effectively use AppConfig, there are three steps you need to go through.

Setup AppConfig: This step involves properly configuring the service to suit your needs. This can either be done via the AWS console, CLI or CDKs.
Integrate Application: This is where you integate your application with AppConfig. This can either be done through APIs or AWS Lambda AppConfig extension.
Deployment: This is where you deploy your configuration changes. It involves updating your values, choosing a deployment strategy and applying your deployment.

AppConfig Terminology

In order to be comfortable working with AppConfig, there are some basic terminologies that you must understand.

Environment: These are logical deployment groups that you can use to deploy your configuration. It is basically a collection of AWS resources - EC2 instances, ECS tasks, Lambda functions, etc. For example, you can have a dev environment and a prod environment. You can change the configurations for dev and prod separately.
Application: This is a logical unit of deployment.
Configuration Profile: This is where your configuration resides. A configuration profile is a collection of configurations for an application, associated with a specific environment. Configuration profiles can either be Freeform or Feature flags.
Deployment Strategies: These are a variety of methods or sets of rules specifying how to roll out configuration updates to an environment.

In summary, AWS AppConfig is a great service for building feature flags, performing operations tuning on your application and changing your application behavior without ever needing to alter source code, redeploy or restart the application.

DevOps On AWS: CodePipeline In Action

Kelvin Onuchukwu — Fri, 02 Jun 2023 17:26:43 +0000

This post was originally published at Practical Cloud.
View the original post here.

This is the second part of a three series project on designing and deploying a three-tier architecture on AWS. Here is the link to the first part of this project.

DevOps on AWS is the implementation of the DevOps philosophy on the AWS Cloud platform. This includes implementing an effective CI/CD solution that provides components such as Load Balancing, Content Delivery, Storage, Security, Database, Caching and Scaling.
AWS provides a set of tools for implementing DevOps which includes,but may not be limited to:

AWS CodeCommit: This is a cloud version control service that is quite secure and highly scalable.
AWS CodeBuild: This is a fully managed build and continuous integration service in the cloud. It provides similar capability to Jenkins. It is also highly scalable, offering continuous scaling and high availability.
AWS CodeDeploy: This is a deployment service that automatically deploys applications to EC2 instances, On-premises servers, Lambda functions and ECS.
AWS CodePipeline: This is a managed continuous delivery service that can be used to automate a release pipeline. AWS also offers other supplementary services such as CodeStar, Device Farm, etc which can help improve the quality of your DevOps experience on AWS.

In this project, we'll be making use of CodePipeline as the continuous delivery service for automating the deployment of our three-tier application to AWS.

We'll be using GitHub, instead of CodeCommit for source control.
We'll use CodeBuild for building and testing our application code. CodeBuild will also be used to execute our terraform scripts in order to provision environments for the application. At this stage we'll also add a manual step, which involves sending SNS notifications to the user after a "terraform plan". If we are happy with the plan, then we go ahead to approve, which takes it to the next step.
CodeDeploy will then be used to deploy the Flask application to our EC2 instances.

Lets Go!

Step 1: Fork The Application repository

This is a very important first step. CodePipeline will listen for changes to our application. To follow through with the rest of the project, you'll need to have the repository in your GitHub account. Here is the link to the project on GitHub. Fork the repository.

Step 2: Provision The Environment

Clone the repository to your local computer.
Navigate into the terraform directory. Edit the backend.tf file and add your own backend.
Run terraform plan. if you like the plan, then run terraform apply. After the apply is successfully executed, you should see your bastion host's IP address and your application's DNS address on your screen.

Step 3: Create A Build Project

This is where we integrate our source control.
CodeBuild enables us to perform testing and other necessary builds and integrations. It is our build server of choice for this project.
On the CodeBuild Console, create a project. Choose a suitable name and description. Enable build badge.
Build badges are images provided through a public URL which displays the status of our latest build.

Your source provider should be GitHub. Connect to your GitHub account. Source version is master (The master branch).

Choose Ubuntu as your operating system. Choose the standard runtime and select "create a new service role".

Because I want CodeBuild to have private access to my servers, I will click on "Additional configuartion".
Under VPC, Ill select the project-x-vpc that I provisioned using terraform.
Leave every other setting as is. Click on create build project.
N.B: The secret sauce for CodeBuild is the buildspec file at the root of the application's repository. This is where I define what happens during the build phase. CodeBuild cannot run without a buildspec file. By default, this file must be named buildspec.yml though you can change this behaviour.

Step 4: Create An IAM Role For CodeDeploy

CodeDeploy will require IAM permissions in order to access the application servers.
Go to the IAM Console, click on "Roles", click on "Create role".
We will create a service roles which CodeDeploy will assume to gain access to our EC2 servers.

Click on Next.

Since our AutoScaling group will be originally launched from a launch template, we will need to add extra permissions.
Click on Add permissions, Attach policy, Create policy
Our json policy willl look like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags",
                "ec2:RunInstances",
                "iam:PassRole"
            ],
            "Resource": "*"
        }
    ]
}

Click on Next. Review and create your policy. It should look like this:

Now go back and attach this permission, it should look like this:

Click Next, Review and create your role.

Step 5: Configure CodeDeploy

AWS CodeDeploy is a deployment service that automates the continuous deployment of application updates/versions to your servers.
Click on CodeDeploy drop down on the Left hand side of your screen. Click on "Applications". Click on "Create Application".
Application in CodeDeploy is a mechanism by which it manages revisions, deployment configurations and deployment groups.
Choose a name for your application and select a platform. Click on "Create application".

Click on "Create deployment group".
Choose a name for your group. Select the CodeDeploy service role we created in step 4.

Now because I want MINIMUM downtime, I'll be using a blue/green deployment type. You can visit here to get more information about blue/green deployments.

Select the project-x-asg auto scaling group and also choose terminate after 5 minutes. Under Application Load Balancer, select your provisoned project-x-lb-tg target group as the target group of choice.

Click on "advanced options". Enable deployment rollbacks on failures. Create your deployment group.

We don't need any triggers for this deployment group. you typically use triggers if you are simply automating your deployment. But since this is a CI/CD pipeline, we'll leave everything to CodePipeline to orchestrate.

N.B: The secret sauce for CodeDeploy is the appspec file at the root of the application's repository. This is where I define what happens during the deploy phase. CodeDeploy cannot run without an appspec file. By default, this file must be named appspec.yml though you can change this behaviour.
Also note that the only reason this would work is because I already included instructions for installing the CodeDeploy as part of the user data on the logic tier servers. Therefore they will be automatically provisoned by terraform. If you were to use a different environment, remeber to install the CodeDeploy agent on your servers. You can find instructions on how to do that here.

Step 6: Create A Pipeline

AWS Codepipeline acts as our continuous delivery service. It is the glue that holds our entire together and also orchestrates it. CodePipeline will seamlessly handle the integration of source control, CodeBuild and Codedeploy.

Go to the Pipeline Console, click on "Create Pipeline".

Choose a name for your pipeline. Click on Next.

Under source stage, select GitHub from the drop down. Authorize access to GitHub.

CodePipeline allows us to choose either Jenkins or CodeBuild as our build provider. We are going to choose CodeBuild.
Under project name, select the build project we created in step 3.

On the Add Deploy stage, we will use CodeDeploy as our deploy provider. Then we will select the application name and deployment group we created earlier on in step 5.

Review and create your pipeline.

Aaaaaaaaaaaaaaaaaaannnnnnndd............Done!!!
We have successfully created a CI/CD pipeline on AWS using AWS CodePipeline.

Before You Go..
Let's take this a notch further by adding a manual approval feature through which manual approval must be given before the application is deployed.

Step 7: Create An SNS Topic

For manual the manual approval stage, we want to be able to send an email notification to the team lead that the buid is successful and about to deploy. The team lead must then review the artifacts and/or log outputs from the build and make a decision whether to continue to deploy or not.

Go to the AWS SNS console, create a topic.
Choose a standard topic. Give a name and display name to your topic. create the topic.

Step 8: Modify The Pipeline

Now we have to include an action group after the build stage to enable a manual approval feature.

Go to the pipeline, click on Edit.

On the Build Stage, click on Edit.
Here, we will add an action group just after the build.
An Action Group is a set of one or more actions through which you can further refine your pipeline workflow. There are six types of actions - source, build, test, deploy, approval and invoke. Read more about them here.
Your pipelie should now look like this:

Without the red lines of course!

That's it. I hope you enjoyed it. Happy Clouding!!!

A Practical Guide To Deploying A Three-tier Application On AWS

Kelvin Onuchukwu — Thu, 01 Jun 2023 09:26:55 +0000

This post was originally published at Practical Cloud.

View the longer, original version here.

Multi-tiered architectures have become the most popular ways of designing and building applications in the cloud. This is primarily because they offer high availability, replication, flexibility, security and many other numerous benefits. This is as opposed to single-tier architectures which typically involves packaging all the requisite components of a software application into a single server.

The most popular multi-tier design pattern is a three-tier architecture. The three-tier architecture consists of the following layers:

Presentation Layer: This is the outermost layer of the application and provides an interface for interacting with the user. It also provides a secure communication channel with the other tiers.
Logic Layer: This is where information is processed and application logic is executed. It processes input from the presentation layers, processes it and also communicates with the data layer when necessary. it is also known as the application layer or middleware.
Data Layer: This is where the database management system sits, thus providing it with a secure, isolated environment for storing and managing application information.

In this guide, we are going to design a very fault-tolerant, highly scalable Flask application on AWS using the three-tier architecture design pattern.

Architectural Design

The Presentation layer will comprise of; Cloudfront, Elastic Load Balancer, Internet Gateway, NAT Gateway and two Bastion Hosts.
The Application (Logic) Layer will consist of EC2 instances based on EBS volumes, provisioned through an Auto Scaling group.
The Data Layer will be made up of a PostgresQL Database with a Read Replica. The EC2 instances provisioned in the application layer will be connected to an Elastic Filesystem for data storage. So technically, the EFS is also residing in this layer.

Bonus:

AWS Route 53 will be used to provide a domain name for the application.
We will integrate ClodFront with the Application Load Balancer to provide worldwide accelerated content delivery and reduce latency.
Terraform will be used as the Infrastructure-as-code (IAC) tool to automate this whole process from end to end.

To automatically create this architecture from end to end, click on this Link to get the Terraform code.

This is a first-part of a three series project.
In the second project, we will implement DevOps on AWS via CodePipeline, CodeBuild and CodeDeploy.
The third project introduces a Reporting Layer into the architecture.
This part focuses soley on designing and deploying three-tier architecture for a Flask application on AWS.

Let's begin. Shall we?

Step 1: Create The Environment.

Firstly we will create a VPC. A virtual private cloud is a secure, isolated, networking environment hosted in a public Cloud. A VPC is more or less a virtual data center in the cloud. This is where most of our application resources will be hosted.

My VPC has a name tag of project-x. This means that all other resources created within this VPC will have the prefix of "project-x".
You can also notice that I am assigning a CIDR block of 10.0.0.0/16 to my VPC. This is a block of private IP addresses from which my VPC resources will get their local addresses.

Notice that I am in the us-east-1 region (North Virginia).
Our VPC will be provisioned in three availability zones. 6 subnets will be created in total. Three public and three private ones. The public subnets are public soley because an internet gateway will be attached to them.
Also notice that I am creating a NAT gateway. This NAT gateway will be used by the EC2 instances hosting our application to connect to the internet (E.g: For Updates).

Step 2: Create A Security Group

A security group acts like a firewall and determines how traffic will enter or exit instances.
Since our web servers will be hosted in the logic-tier, it is important that we restrict the type of traffic entering them.

The name of our security group will be "project-x-logic-tier-sg"
The security group must allow inbound traffic on port 5000 since that is the port on which Flask listens on.

Step 3: Create A Launch Template

A Launch Template is a way of specifying important configuration details such that we can then launch instances using the details in the template. This template will be used by an auto scaling group to create instances in our Application tier.

I assigned a name and description to my template. Notice also that i duly tagged the environment as "prod".

I am using a "t3.xlarge" instance type.
Be sure to select the "project-x-logic-tier-sg" security group.
Leave every other detting as is.
Under "Advanced details", I am going to paste in the following under user data:



#!/bin/bash

# Mount EFS
fsname=fs-093de1afae7166759.efs.us-east-1.amazonaws.com # You must change this value to represent your EFS DNS name.
mkdir /efs
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport $fsname:/ /efs

# install and set up Flask
apt update
apt upgrade -y
apt install python3-flask mysql-client mysql-server python3-pip python3-venv -y
apt install sox ffmpeg libcairo2 libcairo2-dev -y
apt install python3-dev default-libmysqlclient-dev build-essential -y

Step 4: Create an Autoscaling Group, Elastic Load balancer And Target Group

The Load balancer is the entry point to the application.
The Application Load Balancer, residing in the presentation layer, will route traffic through the AutoScaling Group to logic-tier instances residing in the logic layer.

I am naming this Autoscaling group "project-x-asg"
Click on next. Select the "project-x-vpc" we created earlier. Also make sure that you select only the private subnets from the three availability zones. This is very crucial since our VPC will be launched in the logic tier. The subnets must not be public.

Click on next.
Under "Configure advanced options", select "Attach to a new load balancer". Also select "Create a target group".
On the next page, we'll configure our ASG to have a minium capacity of 2, a desired capacity of 4 and a maximum capacity of 6. We'll also set up scaling based on target tracking metrics to scale based on average CPU Utilization.

You can decide to add tags. I'll add a tag name of "Environment" with a value of "Prod". this will be needed during the CodeDeploy stage.

Create your ASG.

Step 5: Attach An Elastic Filesystem

AWS EFS is a fully managed, highly scalable shared storage solution in the cloud. It is NFS compatible.
This Elastic filesystem will provide shared storage for all our application tier servers. Since it provides storage, EFS sits in the data layer of the three tier architecture.

First Create a new security group. This security group should allow only inbound NFS traffic from the security group of our logic-tier instances. You can get a detailed guide on how to create that Here
**
Go to the EFS console. Click on "Create filesystem*" and then click on **customize*.

Assign a name to your EFS. Leave every other setting as default. Click on Next.

On the Network access page, select your propject-x VPC. Select the EFS security group you have created. Click on next.

Under Filesystem Policy, leave everything as default.

Skip to Review and then Create your filesystem.
Now we must update our user data to look like this:



#!/bin/bash

# Use Google's DNS
echo "nameserver 8.8.8.8" >> /etc/resolv.conf

# Force apt to use IPV4
apt-get -o Acquire::ForceIPv4=true update

# Change hostname
echo "project-x-app-server" > /etc/hostname

# Install efs-utils
apt-get install awscli -y
mkdir /efs
sudo apt-get -y install git binutils
git clone https://github.com/aws/efs-utils
cd /efs-utils
./build-deb.sh
apt-get -y install ./build/amazon-efs-utils*deb

# Mount EFS
fsname=$(aws efs describe-file-systems --region us-east-1 --creation-token project-x --output table |grep FileSystemId |awk '{print $(NF-1)}')
mount -t efs $fsname /efs

# Get DB credentials
DB=$(aws rds describe-db-instances --db-instance-identifier --region us-east-1 database-1 --output table |grep DBName |awk '{print $(NF-1)}')
HOST=$( aws rds describe-db-instances --db-instance-identifier --region us-east-1 database-1 --output table |grep Address |awk '{print $(NF-1)}')
ARN=$(aws secretsmanager list-secrets --region us-east-1 --filters "Key=tag-value, Values=project-x-rds-mysqldb-instance" --output table |grep ARN |awk '{print $(NF-1)}')
USER=$(aws secretsmanager get-secret-value --region us-east-1 --secret-id $ARN --output table |grep -w SecretString |awk '{print $3}' |cut -d: -f2 |sed 's/password//' |tr -d '",')
PRE_PASSWORD=$(aws secretsmanager get-secret-value --region us-east-1 --secret-id $ARN --output table |grep -w SecretString |awk '{print $3}' |cut -d: -f3 |tr -d '"')
PASSWORD=${PRE_PASSWORD%?}

# install and set up Flask
apt-get update -y && apt-get upgrade -y 
apt-get install python3-flask mysql-client mysql-server python3-pip python3-venv -y 
apt-get install sox ffmpeg libcairo2 libcairo2-dev -y 
apt-get install python3-dev default-libmysqlclient-dev build-essential -y 

# Clone the app
cd /
git clone https://github.com/Kelvinskell/terra-tier.git
cd /terra-tier

# Populate App with environmental variables
echo "MYSQL_ROOT_PASSWORD=$PASSWORD" > .env
cd /terra-tier/application
echo "MYSQL_DB=$DB" > .env
echo "MYSQL_HOST=$HOST" >> .env
echo "MYSQL_USER=$USER" >> .env
echo "DATABASE_PASSWORD=$PASSWORD" >> .env
echo "MYSQL_ROOT_PASSWORD=$PASSWORD" >> .env
echo "SECRET_KEY=08dae760c2488d8a0dca1bfb" >> .env # FLASK EXTENSION KEY. NOT NECESSARILY A "SECRET".
echo "API_KEY=f39307bb61fb31ea2c458479762b9acc" >> .env 
# YOU TYPICALLY DON'T ADD SECRETS SUCH AS API KEYS AS PART OF SOURCE CONTROL IN PLAIN TEXT.
# THIS IS BEIGN ADDED HERE SO THAT YOU CAN EASILY REPLICATE THIS INFRASTRUCTURE WITHOUT ANY HASSLES.
# YOU CAN REPLACE IT WITH YOUR OWN MEDIASTACK API KEY.

# Setup virtual environment
cd /terra-tier
python3 -m venv venv
source venv/bin/activate

# Run Flask Application
pip install -r requirements.txt
export FLASK_APP=run.py
export FLASK_ENV=production
flask run -h 0.0.0.0

Here is where you find your filesystem's DNS name.

Make sure to change the value of the "fsname" variable to represent your own filesystem's DNS name.

Step 6: Create A Bastion Host

A Bastion Host is a special server used to manage access to servers sitting in an internal network or other private AWS resources from an external network. The bastion host sits in the public network and provides limited access to administrators to log in to servers sitting in an isolated network. It is also commonly referred to as a Jump Box or Jump Server.

From the bastion host, we'll be able to gain SSH access into our application layer servers, for administrative purposes.

Here is a good resource on how to create your bastion host and connect to your logic layer servers through it.
Security Caution: Connecting to bastion hosts using ssh key-pairs is no longer the recommended practice. Instead use AWS Systems Manager for a more secure connection and tunneling through the bastion host to your private instances.

Step 7: Create A Database

The database solidly sits in the data layer, together with the Elastic filesystem.
Our Flask application will need to connect to a relational database. We will be using MYSQL for this architecure.
MYSQL is a widely relational database management system (DBMS) which is free and open source. MYSQL is renowned for its ability to support large production workloads, hence its suitability for our project.

We will however be utilizing Amazon RDS for MYSQL. It is a fully managed database solution in the cloud.

On the RDS Console, click on Databases and then clcik on "Create database".

I am selecting a Production template and choosing Multi-AZ DB-instance.

Select your master username and DB Instance Class. We'll be using AWS SEcrets manager for managing our DB credentials.

Under "Connectivity", select the project-x-vpc. Click on "Create a new security group".

Create a security group that only allows incoming traffic on port 3306 from security group of the application layer servers. Select the security group.

Under "Database Authentication", choose "password".

Go down to "Advanced Options", Under "database name", choose "newsreadb". (You must choose this exact name for the Flask App to be able to connect to the database).

Click on Create database.

Now our architecture is almost ready !!!

To connect to the database, our application will execute API calls to AWS Secrets Manager in order to get the DB credentials. Therefore, we must create an IAM role that allows it to perform that. We will also modify the launch template to attach the role as instance profile for our application layer servers.

Step 8: Create An IAM Role And Modify Launch Template

Go to the IAM Dashboard and click on Roles.
Click on Create Role. Under UseCase, select EC2 and click Next.
Search for secrets and select the permission that pops up.

Click on next and click on Create Role.

Next, we'll need to modify our launch template to include this role so that our logic tier servers can assume it to communicate with AWS Secrets Manager.

Go to the EC2 Console, select launch templates, Actions and click on "Modify launch template"

Go to "Advanced details", Click on the box under IAM instance profile and then select your newly created role. Click on Create.

Finally, be sure to set the new version as the default version.

AND YOU're DONE !!!!!!!
Our three-tier application should now be up and running.

Step 9: Accessing Your Application

If you have followed through with all these steps, Congrats.
Now to access your application, you have to visit the EC2 console to get the domain name of your load balancer.

Go to the EC2 Console and click on Load Balancers.

Copy the DNS Name

Now paste this into a web browser.

That's it. If you made it this far, Congratulations.

Kubernetes Security: Exploring Role Based Access Control (RBAC)

Kelvin Onuchukwu — Thu, 15 Sep 2022 14:03:08 +0000

Security in kubernetes can be quite complex, as there are a lot of disparate parts which must be pieced together in order to get a full picture of the overall architecture. One of the best ways to understand security in kubernetes is to study the individual concepts one at a time. Today we are going to explore the concept of Role Based Access Controls (RBAC) and how they fit in with the general architecture of kubernetes.

Imagine that you are a kubernetes administrator, working on a large cluster or clusters comprising of many nodes and complex applications. How do you define a systematic approach to authorization for your team? Surely, not every team member needs to have access to all parts of the cluster. How do you define what rights and privileges are granted to each member of your team to create, view, modify or delete resources? Luckily, kubernetes provides Role Based Access Control (RBAC). RBAC helps us to achieve fine-grained control over who can do what within our cluster(s).

To understand RBAC, it is necessary to understand how kubernetes processes requests. The API server is responsible for processing requests in kubernetes. When a request comes into the API server, it has to go through a series of events before it is processed by the API server. These series of steps are broadly categorized into Authentication, Authorization and Admission Control.

Authentication validates the identity of the requester that sent the API request. This could be users communicating via kubectl, service accounts within pods or the control-plane and worker nodes. Authentication is enabled through authentication plugins. With plugins, we can define several authentication methods to the API server. There are several authentication plugins that enable authentication, some of which include: client certificates, authentication tokens or Basic HTTP.

Authorization is the process that determines if the requester is allowed to perform actions on resources as stated in the submitted API request. Authorization is also enabled through authorization plugins. This could be Role Based Access Control (RBAC), Node or Attribute Based Access Control (ABAC). Role Based Access Control in kubernetes is implemented at the authorization stage of the API request.

Admission control basically enables administrative control over API requests. This is achieved by admission controllers, which intercept requests to the API server before the object is persisted in etcd.

What Are Role Based Access Controls?

Role based access control is an authorization plugin implemented on the API Server. RBAC is a method of regulating access to cluster resources based on defined roles assigned to subjects. RBAC allows us to write rules which determine what actions can be performed on resources in our cluster. Since RBAC denies by default, only allow rules can be written which permits actions to be performed on the resource. These rules will then have to be bound to subjects. Subjects in RBAC refer to users, groups or service accounts. RBAC implements several API objects such as role, cluster role, role binding and cluster role binding.

Roles define what actions that can be performed on resources within a namespace. Roles can be made up of one or several rules which define the Verbs for resources. Roles are defined using RESTful HTTP semantics. Verbs are similar to HTTP styled verbs such as GET, DELETE, etc. Since RBAC denies access by default, only allow rules can be defined for roles. Since Roles only exist within a namespace, the rules that are defined are bound within that namespace. It is not possible to define a role to perform an action outside the namespace in which it exists.

ClusterRoles are quite similar to roles. They both define permission for actions to be performed on resources. The fundamental difference is that ClusterRole is not a namespaced API object. What this means is that ClusterRole is cluster-scoped. They provide access across all namespaces and to cluster-scoped resources such as Nodes and Persistent volumes. Using a ClusterRole enables us to define a single set of rules and apply them across all resources within our cluster. This greatly reduces administrative overhead since we do not need to define the same rule set over and over across all namespaces.

RoleBinding grants a subject access to a Role or ClusterRole. Essentially, a RoleBinding defines who can do what has been defined in a Role or ClusterRole. When a Role is attached to a RoleBinding, the intention is to grant permissions within a namespace. When a ClusterRole is attached to a RoleBinding, the intention is to grant permissions across several or all namespaces.

ClusterRoleBinding is used to grant cluster-wide permissions across all namespaces. when a ClusterRole is attached to a ClusterRoleBinding, permissions are granted across all namespaces and cluster-scoped (non-namespaced) resources.

Kubernetes provides default roles that can immediately be put to use if we do not wish to define custom Roles/ClusterRoles.

Cluster-admin: This ClusterRole is the super user in kubernetes. It can potentially perform all actions on all resources across all namespaces. When it is attached to a RoleBinding, it has unrestricted access and rights across the defined namespace. When used with a ClusterRoleBinding, it assumes unrestricted rights and privileges across all namespaces and cluster-scoped resources.
Admin: This role permits unlimited read/write access to resources within a namespace. However, it does not grant access to the namespace itself.
Edit: This role grants read/write access within a given Kubernetes namespace. Access to view and modify Roles and RoleBindings is however denied.
View: This role allows read-only access within a given namespace. A subject in a RoleBinding attached to this role will only be able to view resources but unable to modify, create or delete them.

Properly implementing Role Based Access Control within a cluster is a very important aspect of security in kubernetes. RBAC gives an administrator the ability to implement least-privileged access in Kubernetes.

Linux For Cloud Engineers: Understanding SELinux

Kelvin Onuchukwu — Thu, 15 Sep 2022 13:54:49 +0000

Visit my website: Practical Cloud for more posts and projects on Devops and Cloud engineering.

I find that most Cloud Administrators, DevOps engineers and even some sysadmins shy away from the subject of SELinux.
This is not encouraging, giving the fact that a properly implemented SELinux policy can greatly reduce the attack surface across our Linux-based EC2 instances and on-premise systems.

The best way to think of SeLinux is to think of it as an access control mechanism, which implements Mandatory Access Control. This MAC is implemented on top of Discretionary Access Control (DAC) which is built into all Linux systems. What this effectively means is that SELinux will not grant a permission that has been denied by DAC. It can only deny permissions that might have been granted by your Discretionary Access Control.
In addition to implementing MAC, you can argue that SELinux implements Role-Based Access Control (more on that in the later paragraphs).

Discretionary Access Control can simply be thought of as the read, write and execute (rwx) permissions for users, groups and 'others' that you define for your files across your filesystem.

The purpose of SELinux is to regulate the permissions granted to a process and how it accesses files within a Linux environment. Such that a process will always run under the permissions granted to it, no matter if it is started by a privileged or non-privileged user. In essence, a process will only run with the rights necessary for it to perform its function.

Suppose an application running in our EC2 instance - with root privileges - is compromised by a hacker, the hacker can not be able to cause major damage to our environment. This is because even though the application is running under the context of the root user, our SELinux policy has restricted the permissions granted to this application and the running process is not able to access resources beyond which has been granted to it by an appropriately configured SELinux Policy.

There are quite a few terminologies associated with SELinux.
A few of them are; users, roles, subjects, objects, domains, types and type enforcement.

An SELinux user executes a process. That process, is known as a subject.
This could be a user creating a directory, or modifying a file.
So basically, a subject is a running process (a daemon).

But in order for a user to execute a process, it must have access to a role and that role itself must have access to the subject.
This is where Role Based Access Control (RBAC) comes in. A role acts like a bridge between a user and a subject. The role defines which users can have access to itself. Also, the role has a defined list of subjects that it can access.

An object in SELinux is anything that a subject acts upon. This could a file, a directory, or even a server.
Domains are contexts for subjects while Types are contexts for objects.

Bye for now and thank you for reading.

Kubernetes Architecture: Demystifying etcd Data Store.

Kelvin Onuchukwu — Thu, 15 Sep 2022 13:53:18 +0000

The kubernetes API server is the gateway to the kubernetes cluster. This is the primary medium through which we interact with our cluster. The front end of the kubernetes control plane. It is also the medium of communication between resources on the control node and those on the worker node. Nothing escapes the Kube API server. All communication passes through it.

However, anybody who has worked with Kubernetes long enough knows that the API server is stateless. This is where etcd comes in. The etcd data store is where cluster configuration is stored. All configurations and secrets are persisted in the etcd data store in order to maintain state. While this is obvious, what is not so obvious is that extra steps must be taken, especially in a production environment, to protect this data and ensure its continuous availability. This etcd is deployed as a pod on the control node and has a its default data directory location in /var/lib/etcd.

This is why knowing how to backup and restore the etcd data store becomes important. For instance, you need to recover from an administrative error such as a delete operation in which you accidentally deleted the data store. Or perhaps, you lost the server in which etcd was being hosted. Knowing how to backup and restore your etcd server is a very important skill which you must add to your skillset.

For starters, etcdctl is the command line client for interacting with etcd. It also provides backup and restore capabilities for etcd data stores. When you backup etcd, it creates a backup file which will contain the complete state of the data stored in etcd. Etcdctl is not installed by default, so you may need to download it first. You can either download the binary from GitHub or you can run the image as a container.

Before making a backup of your etcd, you need to have a backup plan. When making a backup plan, there are a few factors you must consider. The first is encrypting your backup file. Since they are plain-text by default, you need to ensure that they are encrypted after backup. The second factor to consider is an offsite location for storing your backup file(s). You do not want to lose your backup file alongside your etcd data store if the server goes down or you lose access to your cluster.