cyberangles guide

Deploying Ruby Applications on AWS: Best Practices

Ruby has long been a favorite among developers for building dynamic, scalable web applications, thanks to its elegant syntax, robust frameworks (like Ruby on Rails and Sinatra), and vibrant ecosystem. When it comes to deploying these applications, Amazon Web Services (AWS) stands out as a leading cloud provider, offering a suite of tools to ensure scalability, reliability, and security. However, deploying Ruby apps on AWS requires careful planning to avoid common pitfalls like poor performance, security vulnerabilities, or unexpected costs. In this blog, we’ll explore **best practices** for deploying Ruby applications on AWS, covering everything from choosing the right services and deployment strategies to security, monitoring, and cost optimization. Whether you’re deploying a small Sinatra microservice or a large Rails application, these guidelines will help you build a robust, production-ready infrastructure.

Table of Contents

  1. Prerequisites
  2. Choosing the Right AWS Services for Ruby Apps
  3. Deployment Strategies for Ruby Applications
  4. Containerization with Docker and AWS ECS/EKS
  5. Serverless Ruby: AWS Lambda & API Gateway
  6. Database Best Practices
  7. Security First: Protecting Your Ruby App
  8. Monitoring, Logging, and Tracing
  9. CI/CD Pipelines with AWS
  10. Cost Optimization Techniques
  11. Common Pitfalls and Solutions
  12. Conclusion
  13. References

Prerequisites

Before diving into deployment, ensure you have the following:

  • Ruby Environment: A working Ruby installation (2.7+ recommended) with bundler for dependency management.
  • AWS Account: An active AWS account with administrative access (or permissions to create resources like EC2, S3, and IAM roles).
  • AWS CLI: Installed and configured with credentials (via aws configure).
  • Basic AWS Knowledge: Familiarity with core AWS services (e.g., EC2, S3, IAM) and concepts like VPCs and security groups.

Choosing the Right AWS Services for Ruby Apps

AWS offers multiple services to host Ruby applications, each with tradeoffs in control, scalability, and operational overhead. Here’s how to choose:

1. AWS Elastic Beanstalk

Best for: Developers who want to focus on code, not infrastructure.

  • Pros: Fully managed platform; auto-handles deployment, scaling, and patching. Supports Ruby, Rails, and Sinatra out of the box.
  • Cons: Less control over infrastructure compared to EC2/ECS.
  • Use Case: Rapid prototyping, small-to-medium Rails apps, or teams with limited DevOps resources.

2. Amazon EC2

Best for: Full control over the environment.

  • Pros: Customize OS, libraries, and server configurations. Ideal for legacy apps or specialized setups.
  • Cons: Requires manual management of scaling, patching, and high availability.
  • Use Case: Large monolithic Rails apps needing fine-grained control over server resources.

3. Amazon ECS/EKS (Containers)

Best for: Microservices or containerized Ruby apps.

  • ECS: Managed container orchestration with Fargate (serverless) or EC2 launch types.
  • EKS: Managed Kubernetes for more complex container workflows.
  • Pros: Scalable, portable, and consistent across environments.
  • Cons: Steeper learning curve for Kubernetes (EKS).
  • Use Case: Modern Ruby microservices, multi-container apps, or hybrid cloud deployments.

4. AWS Lambda (Serverless)

Best for: Event-driven, lightweight Ruby functions (e.g., APIs, background jobs).

  • Pros: Pay-per-use pricing, auto-scales, no server management.
  • Cons: Cold starts, execution time limits (15 mins), and limited runtime support (Ruby 2.7+).
  • Use Case: API backends, webhooks, or batch processing tasks (e.g., image resizing).

Deployment Strategies for Ruby Applications

To minimize downtime and risk, use these deployment strategies:

1. Blue-Green Deployment

  • How it works: Maintain two identical environments (“blue” = live, “green” = staging). Deploy updates to green, test, then switch traffic.
  • AWS Tools: Elastic Beanstalk (built-in), ECS (with target groups), or ALB (Application Load Balancer) for EC2.
  • Benefits: Zero downtime, easy rollbacks if issues arise.

2. Canary Deployment

  • How it works: Roll out updates to a small subset of users first, then gradually expand.
  • AWS Tools: ECS with ALB weighted routing, Lambda traffic shifting, or Elastic Beanstalk environment URLs.
  • Benefits: Reduces risk by limiting exposure to bugs.

3. Rolling Updates

  • How it works: Update instances in batches, ensuring some remain live to handle traffic.
  • AWS Tools: Auto Scaling Groups (EC2), ECS service deployments.
  • Benefits: Balances downtime and resource usage (no need for duplicate environments).

Containerization with Docker and AWS ECS/EKS

Containerizing Ruby apps ensures consistency across development, testing, and production. Here’s a step-by-step guide:

Step 1: Dockerize Your Ruby App

Create a Dockerfile in your app root:

# Use an official Ruby runtime as the base image
FROM ruby:3.2-slim

# Set working directory
WORKDIR /app

# Install system dependencies (e.g., for PostgreSQL, Node.js)
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    libpq-dev \
    nodejs \
    && rm -rf /var/lib/apt/lists/*

# Install Ruby dependencies
COPY Gemfile Gemfile.lock ./
RUN bundle install --without development test

# Copy app code
COPY . .

# Precompile assets (for Rails)
RUN bundle exec rake assets:precompile

# Expose the port the app runs on
EXPOSE 3000

# Start the app
CMD ["bundle", "exec", "rails", "server", "-b", "0.0.0.0"]

Step 2: Push to Amazon ECR

Amazon Elastic Container Registry (ECR) is a managed Docker registry. Push your image:

# Authenticate Docker to ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.us-east-1.amazonaws.com

# Create a repository (if not exists)
aws ecr create-repository --repository-name my-ruby-app --region us-east-1

# Tag and push the image
docker tag my-ruby-app:latest <your-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-ruby-app:latest
docker push <your-account-id>.dkr.ecr.us-east-1.amazonaws.com/my-ruby-app:latest

Step 3: Deploy to ECS with Fargate (Serverless)

  • Define a task definition (JSON/YAML) specifying the ECR image, CPU/memory, and network settings.
  • Create an ECS service with Fargate launch type, attaching it to an ALB for traffic routing.
  • Enable auto-scaling based on CPU/memory usage or request count.

Serverless Ruby: AWS Lambda & API Gateway

For lightweight Ruby apps, AWS Lambda is a cost-effective option. Here’s how to deploy a Ruby function:

Step 1: Write a Ruby Lambda Function

Create lambda_function.rb:

def lambda_handler(event:, context:)
  {
    statusCode: 200,
    body: JSON.generate({ message: "Hello from Ruby Lambda!" })
  }
end

Step 2: Package and Deploy with AWS CLI

Zip the function and deploy:

zip function.zip lambda_function.rb

aws lambda create-function \
  --function-name RubyHelloWorld \
  --runtime ruby3.2 \
  --role arn:aws:iam::<your-account-id>:role/lambda-execution-role \
  --handler lambda_function.lambda_handler \
  --zip-file fileb://function.zip

Step 3: Expose via API Gateway

  • Create a REST API in API Gateway.
  • Link it to your Lambda function as an integration.
  • Deploy the API to a stage (e.g., prod) to get a public endpoint.

Note: For Rails apps, use aws-lambda-rails gem to adapt Rails to Lambda, but be mindful of cold starts and memory limits.

Database Considerations

Ruby apps often rely on databases; use AWS-managed databases for reliability:

1. Amazon RDS (Relational Databases)

  • Options: PostgreSQL, MySQL, MariaDB (popular with Rails).
  • Best Practices:
    • Use Multi-AZ deployment for high availability (automated failover).
    • Enable backups (daily snapshots, point-in-time recovery).
    • Encrypt data at rest with AWS KMS.
    • Use connection pooling (e.g., pgbouncer for PostgreSQL) to avoid hitting RDS connection limits.

2. Amazon Aurora

  • A MySQL/PostgreSQL-compatible database with better performance and scalability than RDS.
  • Use Aurora Serverless for auto-scaling, pay-per-use databases (ideal for variable workloads).

3. Amazon DynamoDB (NoSQL)

  • For Ruby apps needing fast, scalable NoSQL storage (e.g., user sessions, product catalogs).
  • Use the aws-sdk-dynamodb gem for Ruby integration.
  • Enable DynamoDB Streams for event-driven workflows (e.g., syncing with Elasticsearch).

Security Best Practices

Secure your Ruby app on AWS with these steps:

1. IAM Roles & Least Privilege

  • Assign IAM roles to EC2 instances/ECS tasks instead of hardcoding access keys.
  • Follow the principle of least privilege: restrict permissions to only what the app needs (e.g., S3 read-only for static assets).

2. Network Security

  • Deploy apps in a VPC with private subnets (no direct internet access).
  • Use security groups to allow traffic only on necessary ports (e.g., 80/443 for HTTP/HTTPS).
  • Block unwanted traffic with network ACLs (stateless firewalls).

3. Encryption

  • Data in transit: Use TLS 1.2+ for all traffic (ALB, API Gateway, RDS).
  • Data at rest: Encrypt EBS volumes, RDS databases, and S3 buckets with AWS KMS.

4. Secrets Management

  • Store database credentials, API keys, and tokens in AWS Secrets Manager or Parameter Store (not in code or environment variables).
  • Example: Fetch secrets in Ruby using aws-sdk-secretsmanager: 
    require 'aws-sdk-secretsmanager'

client = Aws::SecretsManager::Client.new(region: 'us-east-1')
secret = client.get_secret_value(secret_id: 'prod/ruby-app/db-creds')
db_creds = JSON.parse(secret.secret_string)

5. Regular Patching

  • Use AWS Systems Manager Patch Manager to automate OS and Ruby gem updates.
  • Scan for vulnerabilities with Amazon Inspector.

Monitoring and Logging

Proactively monitor your Ruby app with AWS tools:

1. Amazon CloudWatch

  • Metrics: Track CPU, memory, request latency, and error rates (e.g., 5xx errors in ALB).
  • Logs: Stream Ruby app logs (Rails logs, Puma logs) to CloudWatch Logs using the CloudWatch Logs agent.
  • Alarms: Set alerts for critical issues (e.g., high error rates, low disk space).

2. AWS X-Ray

  • Distributed tracing for Ruby apps: trace requests across Lambda, EC2, RDS, and external APIs.
  • Use the aws-xray-sdk-ruby gem to instrument Rails/Sinatra apps: 
    require 'aws-xray-sdk'

Aws::XRay.recorder.configure do |config|
  config.service_name = 'my-ruby-app'
end

CI/CD Pipelines with AWS

Automate deployment with AWS CodePipeline:

Example Workflow

  1. Source: Connect to GitHub/GitLab repository.
  2. Build: Use CodeBuild to run tests (e.g., bundle exec rspec) and build Docker images.
    • Sample buildspec.yml: 
      version: 0.2
phases:
  install:
    runtime-versions:
      ruby: 3.2
  pre_build:
    commands:
      - bundle install
      - bundle exec rspec
  build:
    commands:
      - docker build -t my-ruby-app .
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
      - docker push $ECR_URI:latest
  3. Deploy: Use CodeDeploy to deploy to EC2/ECS or Elastic Beanstalk.

Cost Optimization

Avoid overspending with these tips:

1. Right-Size Resources

  • Use EC2 Instance Types or Fargate CPU/memory that match your app’s needs (e.g., t3.medium for small Rails apps).
  • Use AWS Compute Optimizer to get recommendations for right-sizing.

2. Auto Scaling

  • Scale down during low traffic (e.g., nights/weekends) with Auto Scaling Groups (EC2) or ECS service auto-scaling.

3. Use Spot Instances

  • For non-critical workloads (e.g., staging, batch jobs), use EC2 Spot Instances (up to 90% cheaper than On-Demand).

4. Reserved Instances/Savings Plans

  • For steady-state workloads, buy Reserved Instances (1-3 year terms) or Savings Plans for up to 72% savings.

Common Pitfalls and Solutions

PitfallSolution
Lambda cold startsUse Provisioned Concurrency to keep functions warm.
RDS connection limitsUse connection pooling (e.g., pgbouncer).
Memory leaks in RubyProfile with rack-mini-profiler, fix leaks, or use auto-scaling to replace instances.
Misconfigured security groupsRestrict inbound traffic to only necessary IPs/ports.

Conclusion

Deploying Ruby applications on AWS requires careful planning around service selection, security, scalability, and cost. By following these best practices—whether using Elastic Beanstalk for simplicity, ECS for containers, or Lambda for serverless—you can build robust, secure, and cost-effective Ruby apps on AWS. Always prioritize security, monitoring, and automation to reduce operational overhead and focus on delivering value to users.

References