This guide provides detailed information about the security features, configurations, and best practices for the S3 Cross-Region Compressor system.
The S3 Cross-Region Compressor is designed with security as a fundamental principle. The architecture implements multiple layers of security controls across network, data, identity, and operational domains to ensure that your data remains secure throughout the compression and replication processes.
All components of the system run in private subnets within isolated VPCs:
- Private Subnet Configuration: All ECS tasks run in
PRIVATE_ISOLATEDsubnets with no internet gateway or NAT gateway access - Region-Specific VPCs: Each region has its own isolated VPC with non-overlapping CIDR blocks
- Multi-AZ Deployment: Resources are distributed across multiple availability zones for resilience
The system uses VPC Endpoints to access AWS services without traversing the public internet:
-
Gateway Endpoints:
- S3 for object storage access
- DynamoDB for compression settings storage
-
Interface Endpoints:
- Amazon ECR for container image access
- CloudWatch Logs for logging
- SQS for message queuing
- DynamoDB for configuration storage
- Security Groups: ECS tasks use security groups that only allow outbound traffic
- No Inbound Access: No inbound rules are configured, blocking all incoming connections
- No Internet Access: Components have no route to the internet, preventing data exfiltration
- AWS Backbone Network: Cross-region replication uses AWS's private network backbone
- TLS Encryption: All API calls and data transfers use TLS encryption in transit
The system implements comprehensive encryption at rest using AWS KMS:
-
S3 Bucket Encryption:
- All solution-managed buckets enforce KMS encryption
- Bucket key feature enabled for reduced API calls and costs
- User-provided buckets can optionally use KMS encryption
-
KMS Key Configuration:
- Region-specific KMS keys with annual rotation enabled
- Separate keys for each function (source processing, target processing)
- IAM-based access control to encryption keys
- Key Separation: Each region uses its own KMS keys
- Key Permissions: S3 replication roles have permissions to decrypt in source region and encrypt in target regions
- Manifest Encryption: The manifest file containing metadata is encrypted along with the objects
- Metadata Preservation: Original object metadata and tags are preserved through the compression/decompression process
- Manifest Validation: Target processing validates manifests before restoring objects
- Additional Tags for Consistency: The solution replicates all the source tags adds 2 additional tags to the target objects:
- OriginalCreationTime: datetime value for original object put in source
- OriginalETag: uniquely identifiable ID for original object put in source
- Public Access Blocking: All S3 buckets have Block Public Access enabled at the bucket level
- SSL Enforcement: HTTPS connections are required for all S3 operations
- Lifecycle Management: Automated cleanup of temporary objects after successful replication
The system implements the principle of least privilege through specialized IAM roles:
-
ECS Task Roles:
- Task-specific permissions for source and target processing
- Separate roles for each deployment configuration
- Permissions scoped to specific resources and actions
-
ECS Execution Roles:
- Permissions limited to pulling container images and writing logs
- No access to customer data
-
S3 Replication Roles:
- Limited to source bucket read access and destination bucket write access
- KMS decrypt/encrypt permissions for cross-region replication
- IAM Role-Based: All components use IAM roles without long-term credentials
- Short-Lived Credentials: Temporary credentials via IAM roles for ECS tasks
- No Embedded Secrets: No credentials or secrets are stored in containers or configuration files
- CloudWatch Logs: All container logs are captured in CloudWatch
- Structured Logging: JSON-formatted logs for easier analysis and filtering
- Log Retention: Configurable log retention periods based on compliance needs (one month default)
- Resource Tagging: All resources tagged for governance and cost allocation
- IAM Access Analyzer: Compatible with AWS IAM Access Analyzer for permission verification
- AWS Config: Compatible with AWS Config for compliance monitoring
- Minimal Base Images: Container images based on minimal Linux distributions (python:3.13.5-slim)
- Non-Root User Implementation: Containers run as
appuserwith UID/GID 1000- Dedicated user and group created for application execution
- Proper directory ownership and permissions (755 for directories, 644 for files)
- Enhanced security through principle of least privilege
- Compatible with Kubernetes Pod Security Standards
- Enhanced Directory Structure:
/app(755, appuser:appuser) - Application code directory/tmp/app-temp(1777, appuser:appuser) - Primary temporary directory/tmp/app-work(1777, appuser:appuser) - Alternative temporary directory- Environment variables configured for proper temp directory usage
- Image Scanning: Container images can be scanned for vulnerabilities through ECR
- No Persistent Storage: Containers are stateless with no persistent storage
- AWS S3 Security Best Practices
- AWS KMS Best Practices
- ECS Security Best Practices
- VPC Security Best Practices
- Container images should be regularly rebuilt to incorporate security patches
- AWS service updates are automatically applied by AWS
- CDK dependencies should be kept updated to resolve security vulnerabilities