Dr. Werner Vogels delved into the intricate dance between simplicity and complexity, emphasizing the importance of strategic design, organizational alignment, and a relentless pursuit of evolvability. As we embark on a new year, it's time to revisit these principles and apply them to our own architectural endeavors.

A Masterclass in System Design

Dr. Werner Vogels, CTO of Amazon, delivered a masterclass in system design. He emphasized the importance of evolvability and manageability in building scalable systems. He highlighted the significance of decomposition, organizational alignment, and cell-based architectures in achieving these goals.

By breaking down complex systems into smaller, loosely coupled components, organizations can improve their ability to adapt to changing requirements and mitigate the impact of failures. Additionally, aligning organizational structure with system architecture can enhance team autonomy and accelerate innovation. He also advocated for the use of cell-based architectures, which can isolate failures and improve system resilience.

Finally, he stressed the role of predictability and automation in reducing operational complexity. By automating routine tasks and leveraging machine learning to identify anomalies, organizations can free up engineers to focus on higher-value activities.

The Echoes of re:Invent 2024: A Blueprint for the Future

Dr. Werner Vogels’ keynote wasn’t just theoretical - it resonated deeply with real-world challenges and solutions I’ve seen while working with customers. Many of the principles he outlined, such as managing complexity, designing for evolvability, and leveraging cell-based architectures, align with the strategies I’ve applied in customer projects. Let’s dive into some specific examples where these ideas have been put into practice, showcasing how they can address real business needs and drive innovation.

A Proactive Approach to System Design

The quote "Plan for failure and nothing will fail," emphasizes the importance of proactive system design. Even the best-designed systems can encounter problems. By carefully considering the system's requirements, operational model, and potential failure points, organizations can build more resilient and reliable systems. They often rush to launch products without proper testing or backup plans. This can lead to costly downtime, damaged reputations, and lost revenue.

Key considerations for proactive system design include:

• Thorough Requirements Analysis: A deep understanding of the system's purpose, users, and constraints is essential.

• Realistic Operational Model: Developing a realistic operational model that accounts for potential challenges and limitations.

• Organization's Capabilities: Assessing the organization's technical expertise, resources, and risk tolerance.

• Long-Term Vision: Considering the system's future evolution and potential scalability needs.

• Failure Mitigation Strategies: Implementing robust error handling, monitoring, and recovery mechanisms.

By taking a proactive approach to system design, organizations can reduce the risk of costly failures and ensure the long-term success of their digital initiatives. While iterative development is crucial for continuous improvement, it's equally important to get certain foundational aspects right from the start. Investing time in upfront planning and design can prevent costly and time-consuming refactors and redesigns later on. By striking a balance between agility and foresight, organizations can build systems that are both adaptable and resilient.

Simplexity: The Art of Balancing Simplicity and Complexity

Dr. Werner Vogels' concept of "simplexity" highlighted the delicate balance between simplicity and complexity in system design. While simplicity is often desirable, it's not always achievable, especially in large-scale systems.

Achieving simplexity involves several key strategies. One approach is adopting a modular architecture, which involves breaking down complex systems into smaller, more manageable components. Another is defining clear and concise interfaces between these components, helping to reduce complexity and improve communication. Automation also plays a critical role, as it minimizes manual effort and reduces the risk of errors in routine tasks. Finally, continuous optimization is essential—regularly reviewing and refining the system helps eliminate unnecessary complexity and ensures it remains efficient and effective.

By embracing simplexity, organizations can build systems that are both efficient and maintainable. However, it's important to strike a balance between simplicity and functionality.

Evolvability: Building Systems for the Future

Dr. Werner Vogels emphasized the importance of evolvability, or a system's ability to adapt to future needs. In today's rapidly changing technological landscape, it's crucial to design systems that can evolve without significant disruption. By investing in a solid foundation, embracing a culture of continuous improvement, and leveraging modern technologies, organizations can build systems that are not only resilient but also adaptable to the future.

For example, using microservices architecture allows for independent development and deployment of individual services, making it easier to add new features or modify existing ones. Additionally, adopting a DevOps culture can accelerate the development and deployment process, enabling organizations to respond quickly to changing market conditions.

Again, I want to emphasize how a strong foundational baseline can greatly enhance a system’s ability to evolve. Taking the time for thoughtful planning and design upfront can help avoid expensive and time-consuming major refactors down the line. By balancing agility with foresight, organizations can create systems that adapt easily to changing business needs.

The Long Haul of System Ownership

Dr. Werner Vogels highlighted the often-overlooked reality that the lifespan of a system far exceeds its initial development time. Once deployed, systems require ongoing maintenance, updates, and support.

To ensure the long-term success of a system, organizations should:

• Prioritize Maintainability: Design systems with maintainability in mind, using clear code, consistent naming conventions, and comprehensive documentation.

• Invest in Ongoing Support: Allocate sufficient resources for ongoing maintenance, monitoring, and troubleshooting.

• Embrace Continuous Improvement: Continuously monitor system performance and identify opportunities for optimization.

• Plan for End-of-Life: Develop a plan for decommissioning or migrating the system when it reaches the end of its useful life.

Many organizations make short-sighted decisions when choosing technology, opting for quick and easy solutions that often lead to long-term problems. When choosing one technology over another with cost in mind, the operational effort is often not included in the decision made. Custom or hacky solutions, while initially cheaper, can require significant operational overhead and maintenance effort. In contrast, managed services offered by cloud providers can significantly reduce operational burden and improve system reliability.

By leveraging managed services, organizations can focus on their core business objectives, rather than spending time and resources on infrastructure management. Additionally, managed services often offer advanced features and security capabilities that would be difficult or expensive to implement in-house. Cost optimization is not about using custom workarounds and cheap unreliable solutions. AWS has a great deal of tools and offerings to help you optimize costs.

The Dilemma of Service Size: A Balancing Act

For the last point in this list, I am looking at Dr. Werner Vogels’ question about optimal service size which highlights a common challenge in system design. While extending existing services can be tempting, it can lead to monolithic architectures that are difficult to maintain and scale. On the other hand, creating too many small services can increase complexity and overhead.

By carefully considering the trade-offs between simplicity and flexibility, organizations can strike a balance that best suits their specific needs. While it may require more effort upfront to create well-defined services, the long-term benefits in terms of maintainability and scalability will outweigh the initial investment.

This principle can also be applied to Infrastructure as Code (IaC). While it may be tempting to create a single, monolithic repository for all infrastructure configurations, a component-based approach can offer several advantages. By breaking down infrastructure into smaller, independent components, organizations can improve maintainability, testability, and reusability. Additionally, a component-based approach can make it easier to manage changes and reduce the risk of unintended consequences.

Remember, regardless of the specific IaC framework used (e.g., Terraform, Pulumi, AWS CloudFormation), it's important to remember that IaC is essentially code. By applying fundamental programming principles, such as modularity, encapsulation, abstraction, testing, and version control, and using principles like DRY (Don't Repeat Yourself) organizations can write more efficient, maintainable, and reliable IaC. This can lead to significant time and cost savings, as well as improved system reliability and security.

Unfortunately, many organizations internally as well as widely used public solutions, often disregard fundamental programming principles like DRY (Don't Repeat Yourself). This leads to code duplication, inconsistency, and increased maintenance costs. For example, many modules contain redundant code snippets and configuration options, making them difficult to consistently modify. When code is duplicated across multiple environments or workloads, it becomes challenging to maintain consistency and implement changes. This can lead to configuration drift, security vulnerabilities, and operational issues. Additionally, promoting solutions through a DTAP (Development, Test, Acceptance, Production) pipeline becomes more complex, as changes must be applied to multiple locations.

Conclusion: Building for the Future, Now

In conclusion, Dr. Werner Vogels' keynote at re:Invent 2024 serves as a timeless guide for navigating the complexities of system design and architecture. By embracing principles such as evolvability, proactive planning, and the delicate balance of simplexity, organizations can build resilient, scalable, and adaptable systems. As we move forward, it is crucial to apply these insights to our own projects, ensuring that we not only meet current demands but also anticipate future challenges. When help is needed, don't hesitate to reach out to the solid network of AWS Professionals who can guide you on the right path. The lessons from re:Invent 2024 remind us that thoughtful design, strategic foresight, and leveraging expert support are key to long-term success in the ever-evolving landscape of technology.

As done previously, I will split the information shared in this post in the high level categories that AWS recognizes. With no further ado, let’s dive into it!

Application Integration

AWS has announced new features that allow customers to share resources like Amazon EC2 instances, Amazon ECS and EKS container services, and HTTPS services across Amazon VPC and AWS account boundaries. This enables the building of event-driven applications via Amazon EventBridge and orchestration of workflows with AWS Step Functions. These features leverage Amazon VPC Lattice and AWS PrivateLink, providing more options for network design and integration across technology stacks.

The key benefits for AWS customers include:

• Simplified Modernization: Accelerate modernization efforts by integrating cloud-native apps with on-premises legacy systems.

• Enhanced Integration: Seamlessly connect public and private HTTPS-based applications into event-driven architectures and workflows.

• Efficiency: Replace complex data transfer methods with simpler, more efficient solutions.

These updates aim to help customers drive growth, adapt to the cloud, and reduce costs while meeting security and compliance requirements. Read more about this announcement here.

Containers

Businesses should focus on promoting the business value and not on operational tasks that can be offloaded to a managed services partner or by trying to achieve a no-ops model using key cloud services like the one described below.

AWS announced the general availability of Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode. This new capability streamlines Kubernetes cluster management for compute, storage, and networking, from provisioning to ongoing maintenance with a single click.

Key Benefits for AWS Customers:

• Higher Agility and Performance: By eliminating the operational overhead of managing cluster infrastructure, businesses can achieve greater agility and performance.

• Cost-Efficiency: EKS Auto Mode continuously optimizes costs, helping businesses manage their budgets more effectively.

• Simplified Management: Automates cluster management without requiring deep Kubernetes expertise, selecting optimal compute instances, dynamically scaling resources, managing core add-ons, patching operating systems, and integrating with AWS security services.

• Enhanced Operational Responsibility: AWS takes on more operational responsibility, configuring, managing, and securing the AWS infrastructure in EKS clusters, allowing customers to focus on building applications that drive innovation.

• Support for AI Workloads: Reduces the work required to acquire and run cost-efficient GPU-accelerated instances, ensuring generative AI workloads have the necessary capacity.

Amazon EKS Auto Mode is now available in all commercial AWS Regions except China Regions where Amazon EKS is available. It supports Kubernetes 1.29 and above, with no upfront fees or commitments. Customers pay for the management of the compute resources provisioned, in addition to regular EC2 costs. You can read more about this announcement here.

Databases

Matt Garman discussed in his keynote on Tuesday the challenges of distributed systems, particularly the difficulty of keeping distributed databases in sync, especially over long distances. Providing highly available applications while maintaining low latency reads and writes across AWS Regions is a common challenge faced by many customers.

Accessing data from different Regions can cause delays of hundreds of milliseconds compared to microseconds within the same Region. The necessity for developers to create complex custom solutions for data replication and conflict resolution can lead to increased operational workload and potential errors. Beyond multi-Region replication, these customers have to implement manual database failover procedures and ensure data consistency and recovery to deliver highly available applications and data durability.

Amazon Web Services (AWS) announced the general availability of Amazon MemoryDB Multi-Region, a fully managed, active-active, multi-Region database that you can use to build applications with up to 99.999 percent availability, microsecond read, and single-digit millisecond write latencies across multiple AWS Regions. MemoryDB Multi-Region is available for Valkey, a Redis Open Source Software (OSS) drop-in replacement stewarded by the Linux Foundation. This new feature builds upon the existing benefits of Amazon MemoryDB, such as multi-AZ durability and high throughput across multiple AWS Regions, and addresses these common challenges faced by many customers.

Benefits of MemoryDB Multi-Region:

• High availability and disaster recovery: Build applications with up to 99.999 percent availability. If an application cannot connect to MemoryDB in a local Region, it can connect to MemoryDB from another AWS Regional endpoint with full read and write access. MemoryDB Multi-Region will automatically synchronize data across all AWS Regions when the application reconnects to the original endpoint.

• Low latency: Serve both reads and writes locally from the Regions closest to your customers with microsecond read and single-digit millisecond write latency at any scale. Data is typically propagated asynchronously between AWS Regions in less than one second.

• Compliance and regulatory adherence: Meet compliance and regulatory requirements by choosing the specific AWS Region where your data resides.

You can read more about this announcement here.

AWS also announced the Amazon Aurora DSQL, a new serverless distributed SQL database designed for always-available applications. Aurora DSQL offers virtually unlimited scale, highest availability, and zero infrastructure management. It can handle any workload demand without the need for database sharding or instance upgrades.

Key benefits for AWS customers include:

• High Availability: Aurora DSQL is designed for 99.99% availability in single-Region configurations and 99.999% in multi-Region configurations.

• Scalability: It scales automatically to meet workload demands, eliminating the need for manual scaling.

• Ease of Management: The serverless design removes the operational burden of patching, upgrades, and maintenance.

• PostgreSQL Compatibility: Developers can use familiar PostgreSQL tools and frameworks, making it easy to build and deploy applications.

Aurora DSQL's innovative active-active architecture ensures continuous availability and strong data consistency, making it ideal for building resilient, high-performance applications. You can read more about this announcement here.

Looking forward to hearing more about the distributed database challenges in Dr. Werner Vogels’ keynote on Thursday.

Developer Tools

Wow, more than 30 minutes of Matt Garman’s keynote was reserved on Amazon Q Developer and the latest additions to its capabilities. Let’s see the ones that I think really stand out.

Amazon Q Developer agent capabilities include generating documentation, code reviews, and unit tests

AWS expanded Amazon Q Developer with three new features:

1. Enhanced documentation: Automatically generate comprehensive documentation within your IDE.

2. Code reviews: Detect and resolve code quality and security issues.

3. Unit tests: Automate the creation of unit tests to improve test coverage.

The new features of Amazon Q Developer enhance productivity by automatically generating comprehensive documentation for newly produced code but also existing codebases, saving developers time and ensuring up-to-date information. Automated code reviews improve code quality and security by detecting issues early, while automated unit test generation increases test coverage and reliability. These capabilities streamline the development process, allowing developers to focus more on creating new features and less on repetitive tasks. You can read more about this announcement here.

Investigate and remediate operational issues with Amazon Q Developer

AWS has announced a new capability in Amazon Q Developer, now in preview, designed to help customers investigate and remediate operational issues using generative AI. This new feature automates root cause analysis and guides users through operational diagnostics, leveraging AWS's extensive operational experience. It integrates seamlessly with Amazon CloudWatch and AWS Systems Manager, providing a unified troubleshooting experience. This capability aims to simplify complex processes, enabling faster issue resolution and allowing customers to focus on innovation. Currently, it is available in the US East (N. Virginia) Region.

This and similar products in Generative AI sphere is and will be transforming Managed Services Providers (MSPs) and platform engineering teams by automating routine tasks, enhancing scalability, and improving efficiency while reducing operational costs.

You can read more about this announcement here.

Generative AI / Machine Learning

Next generation of Amazon SageMaker

AWS has announced the next generation of Amazon SageMaker, a comprehensive platform for data, analytics, and AI. This new version integrates various components needed for data exploration, preparation, big data processing, SQL analytics, machine learning (ML) model development, and generative AI application development. The existing Amazon SageMaker has been renamed to Amazon SageMaker AI, which is now part of the new platform but also available as a standalone service.

Key Highlights:

• SageMaker Unified Studio (preview): A single environment for data and AI development, integrating tools from Amazon Athena, Amazon EMR, AWS Glue, Amazon Redshift, and more.

• Amazon Bedrock IDE (preview): Updated tools for building and customizing generative AI applications.

• Amazon Q: AI assistance integrated throughout the SageMaker workflows.

Value for AWS Customers:

• Unified Environment: Simplifies the development process by bringing together data and AI tools in one place.

• Enhanced Capabilities: Offers advanced tools for data processing, model development, and generative AI, improving efficiency and scalability.

• Flexibility: Allows customers to use SageMaker AI as part of the unified platform or as a standalone service, catering to different needs.

This update aims to streamline workflows and enhance the capabilities available to AWS customers, making it easier to build, train, and deploy AI and ML models at scale. Read more about the release here.

Amazon Nova

Andy Jassy, welcome back to re:Invent! He delivered a presentation (more of a mini-keynote) within Matt Garman's keynote. And it came with announcements!

Amazon has announced Amazon Nova, a new generation of foundation models available exclusively in Amazon Bedrock. These models offer state-of-the-art intelligence and industry-leading price performance, designed to lower costs and latency for various generative AI tasks. Amazon Nova can handle tasks such as document and video analysis, chart and diagram understanding, video content generation, and building sophisticated AI agents. There are two main categories of models: understanding models and creative content generation models. The understanding models include Amazon Nova Micro, Lite, Pro, and the upcoming Premier, which process text, image, or video inputs to generate text output. The creative content generation models include Amazon Nova Canvas for image generation and Amazon Nova Reel for video generation.

Amazon Nova models can be fine-tuned with text, image, and video inputs to meet specific industry needs, making them highly adaptable for various enterprise applications. Built-in safety controls and content moderation capabilities ensure responsible AI use, with features like digital watermarking. For AWS customers, Amazon Nova offers cost efficiency, as the models are optimized for speed and cost, making them a cost-effective solution for AI tasks. These models set new standards in multimodal intelligence and agentic workflows, achieving state-of-the-art performance on key benchmarks. Supporting over 200 languages, Amazon Nova enables the development of global applications without language barriers. Integration with Amazon Bedrock simplifies deployment and scaling, with features like real-time streaming, batch processing, and detailed monitoring. Read more about the release here.

Storage

Amazon has introduced Amazon S3 Tables, a new feature designed to optimize storage for tabular data such as daily purchase transactions, streaming sensor data, and ad impressions. These tables use the Apache Iceberg format, enabling easy queries with popular engines like Amazon Athena, Amazon EMR, and Apache Spark. Key highlights include:

• Performance: Up to 3x faster query performance and up to 10x more transactions per second compared to self-managed table storage.

• Efficiency: Fully managed service that handles operational tasks, providing significant operational efficiency.

Amazon S3 Tables are stored in a new type of S3 bucket called table buckets. These buckets act like an analytics warehouse, capable of storing Iceberg tables with various schemas. They offer the same durability, availability, scalability, and performance characteristics as standard S3 buckets, while also automatically optimizing storage to maximize query performance and minimize costs.

Each table bucket is region-specific and has a unique name within the AWS account. These buckets use namespaces to logically group tables, simplifying access management. The tables themselves are fully managed, with automatic maintenance tasks such as compaction, snapshot management, and removal of unreferenced files, ensuring that users can focus more on their data rather than on maintenance.

Integration with AWS services is a key feature of Amazon S3 Tables. Currently in preview, the integration with AWS Glue Data Catalog allows users to query and visualize data using AWS Analytics services like Amazon Athena, Amazon Redshift, Amazon EMR, and Amazon QuickSight. The table buckets support relevant S3 API functions and ensure security by automatically encrypting all stored objects and enforcing Block Public Access. Read more about this announcement here.

AWS is further using the release above for providing further value to it’s customers: Introducing queryable object metadata for Amazon S3 buckets.

It automatically generates rich metadata for objects when they are added or modified. This metadata is stored in fully managed Apache Iceberg tables, allowing customers to use tools like Amazon Athena, Amazon Redshift, Amazon QuickSight, and Apache Spark to efficiently query and find objects at any scale.

This new feature simplifies the process of managing and querying metadata, making it easier for AWS customers to locate the data they need for analytics, data processing, and AI training workloads. Additionally, Amazon Bedrock will annotate AI-generated video inference responses with metadata, helping users identify the content and the model used.

Overall, this enhancement aims to reduce the complexity and improve the scalability of systems that capture, store, and query metadata, providing significant value to AWS customers. Read more about this announcement here.

To be continued...

That has been something so far. As we take a moment to absorb everything that's happened so far at AWS re:Invent 2024, it's clear that this year's event is already shaping up to be even more exciting than 2023. The CEO's keynote has introduced some impressive new technologies and strategies. With so much already revealed, we're looking forward to what the second half of the event will bring. Stay tuned for more updates and insights.

Creating a repository within AWS CodeCommit is not a difficult process. This can be done either in the console or in code. By using code, one can standardize the creation of the CodeCommit repository as well as perform additional tasks around the repository. An example of this could be an initial sync of files towards newly created repositories. This can facilitate multiple use cases. An example is the initial sync towards the repo of License specific files, .gitignore files specific to the requirements of the company, a structure specific setup when that's appropriate. It could be handy as well when multiple files need to initially synced to a newly create AWS CodeCommit repository from a landing zone specific solution on account vending solution.

So how can we achieve this? We will showcase this below using some Terraform sample code.

Solution

First we need to create a new AWS CodeCommit repository.

resource "aws_codecommit_repository" "repository" {
  repository_name = var.repository_name
  description     = "In bulk created repositories"
}

Then we need to create a user that will be used by the pipeline deploying the Terraform code. The files that would typically be available within the pipeline will be synced using Git to the newly create repository. Below you can see a user, policy and attachment of the policy to the user. If the credentials used to create the repository can perform Git pull and push actions, this step can be skipped. Instead we can use the existing credentials in the last step.

resource "aws_iam_user" "pipeline_codecommit_user" {
  name = "codecommit_user"
}

resource "aws_iam_policy" "codecommit_pullpush_policy" {
  name        = "codecommit_pullpush"
  path        = "/"
  description = "CodeCommit policy for the pipeline_codecommit_user used by a CI/CD pipeline"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "codecommit:GitPull",
          "codecommit:GitPush"
        ]
        Effect   = "Allow"
        Resource = aws_codecommit_repository.repository.arn
      },
    ]
  })
}

resource "aws_iam_user_policy_attachment" "codecommit_policy_attachment" {
  user       = aws_iam_user.pipeline_codecommit_user.name
  policy_arn = aws_iam_policy.codecommit_pullpush_policy.arn
}

We then need to create an access key of the aforementioned user. The key will be used in the next steps to sync the files.

resource "aws_iam_access_key" "pipeline_codecommit_user" {
  user = aws_iam_user.pipeline_codecommit_user.name
}

Please note that using the above snippet, the generated access key and secret access key will be available as plain text in the state file, whether that is local or remote. There are ways to encrypt them with using a pgp key, but that goes beyond the scope of this post.

Finally, we can use the local-exec provisioner to sync files to the remote Git repository. Assuming the files are available within a local folder called repo-init, the code that would sync the files can be found below.

resource "null_resource" "git_clone" {
  provisioner "local-exec" {
    command = <<EOT
      export AWS_ACCESS_KEY_ID=${aws_iam_access_key.pipeline_codecommit_user.id}
      export AWS_SECRET_ACCESS_KEY=${aws_iam_access_key.pipeline_codecommit_user.secret}
      git config --global credential.helper '!aws codecommit credential-helper $@'
      git config --global credential.UseHttpPath true
      git clone ${aws_codecommit_repository.repository.clone_url_http} ../temp-location
      cp -r repo-init/**/* ../temp-location
      cd ../temp-location
      git add . && git commit -am "Initial commit" && git push origin main
      rm -rf ../temp-location
    EOT
  }
}

Conclusion

In summary, AWS CodeCommit offers a robust solution for version control. With the aforementioned solution, one can complement it with automation capabilities like syncing files upon creation.

Main image by Freepik

*This article was originally posted here.

In Terraform, the typical organizational structure involves modules, which are reusable units of code that encapsulate infrastructure components. These modules can be composed to create more complex infrastructure. There isn't a standardized or official concept referred to as "Terraform layers" in the Terraform documentation. However, the term has gained popularity in the Terraform community. If you search the tern "Terraform layers" various articles will pop up discussing the concept.

Early stages of Terraform layers

One of the first references of using layers with Terraform was a talk by Armin Coralic (you can find it here).

In his talk, Armin discussed the evolution of using Terraform for IaC and introduced a layered approach to address challenges at different stages. He emphasized three key layers in Terraform code: the bootstrap layer, focusing on setting up the infrastructure; the foundation layer, handling global and foundational aspects; and the service layer, responsible for implementing specific services. This layering strategy aims to provide flexibility, simplify testing, and effectively manage organizational changes in large and complex environments. He finally pointed out the significance of considering both the tools as well as the organizational practices for successful implementation of Terraform in varying contexts.

The layered approach in Terraform can work exceptionally well in scenarios where the infrastructure and organizational needs become more complex and sophisticated. This approach is particularly effective in medium-to-large organizations with multiple teams, diverse responsibilities, and varying lifecycles of infrastructure components. It becomes especially beneficial when addressing challenges such as separating work and responsibilities between teams, managing different lifecycles, and avoiding a monolithic structure. The layering concept is advantageous in facilitating easier testing, promoting flexibility, and adapting to changes that commonly occur in complex organizational settings. Therefore, the layered approach is most suited for environments where the scale and complexity of infrastructure demand a structured and modular approach to Terraform code. One, though, would argue that the same could be achieved with using multiple repositories, abstracting and shifting the responsibility for each module completely to a team.

Evolution of Terraform layers

In the realm of Terraform architecture, two primary approaches emerge: the single monolith (single repo/module) and multiple modules, either split in different repositories or in multiple layers. Each approach comes with its own set of implications, and it becomes imperative to weigh them against the unique needs of your project. Understanding the intricacies of these alternatives empowers you to make informed decisions based on the specific requirements of your target infrastructure's size, the dynamics of your team, and the desired level of immutability.

Monolith

The single monolith approach offers inherent advantages, such as safety, readability, and a straightforward implementation process. It provides a solid foundation, ensuring the stability of your infrastructure code. This approach is well-suited for scenarios where simplicity and ease of management are paramount. With the monolithic approach, all references to other resources can be passed in a native way without the need to hardcode values in environmental variables, or even worse share them through the various parameter and secret stores.

Layers

On the other hand, opting for multiple layers introduces a new dimension to IaC projects. This approach fosters collaboration, enhances agility, and provides flexibility to cater to future needs. By distributing responsibilities across layers, each dedicated team can focus on a specific aspect of the infrastructure, fostering specialization and efficiency. This approach is particularly valuable for larger-scale projects where the complexity demands a more modular and scalable solution. This is what we discussed in the previous paragraph, right? So where is the problem?

In an era that monolithic approaches do not seem to much the distributed cloud paradigm (unrightfully so as this example points out), there is a trend to split everything into subcomponents. To that end, many teams working with terraform have split their monolithic projects using layers, in an attempt to add modularity. In many cases, teams are using different layers for their networking, compute, database and application components. It could be a lot more layers as well. These layers ([sub-]modules?) have different states and they have dependencies between each other passed as references to the state further up.

This creates a lot of complexity during the development process. This as an example the case of making a complex change as a result of a new feature request. Such a request could include touching almost all the layers. Due to the nature of the layer structure and the dependency mapping, upper layers need to be applied before lower layers can be planned/applied. Otherwise references to the state may not be found or the actual components may be missing. It also create an issue with carrying out the first deployment which needs to be treated as an edge case making the deployment in brand new environment cumbersome. As a reminder, the initial idea of the layers was to only split in layers components that have different teams as owners, or components that have completely different lifecycles. And as it becomes evident, strong coupling of components between layers can be a really bad idea.

All the previous also complicate the build and deployment process, the flexibility to automate using CI/CD tools. When you need to apply each layer before you can plan the next, you need to split your changes over multiple pull/merge requests, fragmenting next to the IaC also the development process.

A solid use case for using layers

Despite all the above, there are some edge cases that the layered approach can really shine. Terraform plan and apply can end up taking really long when a lot of resource changes need to be calculated or applied. Imagine a situation in the thousands of resources of a certain type changed at once. Could be thousands of buckets or dns records or anything else managed with Terraform. When (and only when) these resources do not carry references between each other, they can be partitioned in separate layers, with their name being the partition key. When combining this with the power from certain CI/CD tools that can identify the subfolders that carry changes, then only a sub-portion of the infrastructure needs to be planned and applied speeding things up by a lot.

Conclusion

Based on all the above, my advise would be that the layered approach in a single repository is an edge case that should be used with caution and only when it fits the target use case a lot better than the alternative options.

When considering the organization of infrastructure in Terraform, it's crucial to align your approach with the complexity of your project and the dynamics of your team. For simpler projects managed by a single team, opting for a monolithic approach is often the most straightforward choice. It provides a solid foundation for stability, allowing all references to resources to be handled natively without the need for complex configurations or environment variable management. In contrast, for larger and more complex projects involving multiple teams, consider using separate repositories to promote collaboration, specialization, and efficiency across various aspects of the infrastructure. Ultimately, the choice between monolithic and multi-repository approaches should be based on the unique requirements of your project, team structure, and scalability goals.

Keep it simple.

Main image by vectorjuice on Freepik

*This article was originally posted here.

Generative AI / Machine Learning

Amazon Titan, the latest in generative AI, is now available on Amazon Bedrock. This suite includes Image Generator and Multimodal Embeddings, alongside the already accessible Titan Text Lite and Text Express. Leveraging 25 years of AI innovation, these models offer powerful, customizable options for images, multimodal experiences, and text tasks. Whether using the base models or private customization, access is facilitated through the user-friendly Amazon Bedrock console. The original release blog highlights practical demonstrations of Image Generator and Multimodal Embeddings, emphasizing the seamless integration of Titan into Amazon Bedrock for a comprehensive generative AI solution. Read more about it here.

Model Evaluation, a feature introduced by Amazon Bedrock, is now available in preview, providing developers with the capability to assess, compare, and select foundation models (FMs) for their applications. The automatic evaluation option employs predefined metrics such as accuracy, robustness, and toxicity, while the human evaluation option allows customization for subjective metrics like friendliness and alignment to brand voice. In the playground environment, developers can experiment, iterate with automatic evaluations, and ensure quality through human reviews when preparing for an initial launch. Read more about the release here.

Management & Governance

During Werner Vogels' keynote, AWS unveiled myApplications, a suite of capabilities now in general availability that streamlines application operations on the AWS platform. This tool, accessible via the AWS Management Console, empowers users to initiate, manage, and monitor applications efficiently, offering insights into cost, health, security, and performance. With features like the Applications widget and a dedicated applications dashboard, myApplications simplifies resource management and allows users to take specific actions based on key metrics. The launch spans various AWS Regions, supported by AWS Premier Tier Services Partners, including Xebia. Read more about the release here.

Amazon CloudWatch Application Signals, now in preview, addresses the challenges of monitoring performance in distributed systems. It automatically instruments applications based on best practices, eliminating manual effort and custom coding. Users gain access to a pre-built, standardized dashboard showcasing key metrics like request volume, availability, and latency. The service also facilitates the definition of Service Level Objectives (SLOs) to monitor critical operations. Application Signals correlates telemetry across metrics, traces, logs, real user monitoring, and synthetic monitoring, enhancing troubleshooting efficiency. Collaboration is promoted through features like the Service Map, allowing service owners to share triage tasks seamlessly. Read more about the release here.

Closing thoughts

As AWS re:Invent 2023 comes to a close, it leaves in its wake a trail of groundbreaking announcements and innovations. The keynotes, pulsating with energy and anticipation, unleashed a torrent of releases with a resounding emphasis on Generative AI, catering to the evolving needs of developers, businesses, and enterprises.

From the launch of cutting-edge services simplifying application operations to the unveiling of powerful AI models under the Amazon Titan umbrella, AWS re:Invent showcased a commitment to delivering solutions that empower users to build, deploy, and scale with unparalleled efficiency. The myApplications experience introduces a seamless approach to managing and monitoring applications, emphasizing ease of use and operational efficiency.

The unveiling of Amazon CloudWatch Application Signals in preview emerged as a game-changer in the realm of distributed systems monitoring. This service promises to revolutionize how users collect, analyze, and collaborate on application and container telemetry, offering an integrated and standardized dashboard for efficient troubleshooting.

As the curtain falls on re:Invent 2023, the resounding message is clear – Generative AI has taken center stage. The conference has not only showcased the transformative potential of these AI models but has also set the stage for a future where creativity, innovation, and efficiency converge in the cloud computing space. The releases unveiled during re:Invent 2023 collectively underscore AWS's commitment to shaping the future of cloud technology through the lens of Generative AI.

Join me as I reflect on the journey so far, unpacking the game-changing advancements, captivating moments, and the profound impact re:Invent 2023 is already having on the future of cloud computing.

Analytics

Amazon QuickSight is ushering in a new era with the preview of Amazon Q, introducing Generative BI capabilities that empower business users with enhanced insights and storytelling tools. In this preview, users can leverage three key capabilities: Stories, Executive Summaries, and Data Q&A. Stories enable the creation of visually compelling narratives through natural language prompts. Executive Summaries provide quick snapshots of dashboard highlights, saving time and offering at-a-glance insights. The Data Q&A experience facilitates deeper understanding, allowing users to ask vague questions and receive AI-suggested answers with narrative context. This is just one of the Amazon Q capabilities that were introduced and we will look in a few more further below. Read more about the release here.

Containers

A new capability was introduced – the Amazon Managed Service for Prometheus collector – designed to automatically and agentlessly discover and collect Prometheus metrics from Amazon Elastic Kubernetes Service (EKS). This collector, part of the Amazon Managed Service for Prometheus, eliminates the need to run collectors in-cluster and offers fully managed Prometheus-compatible monitoring and alerting. With the option for AWS-managed or customer-managed collection, users can optimize metric collection costs for monitoring applications and infrastructure on EKS. The setup process involves enabling AWS managed collectors during EKS cluster creation, defining scraper configurations, and visualizing metrics using Amazon Managed Grafana. This new capability is now available to all AWS customers in supported regions. Read more about the release here.

Databases

Several exciting announcements have taken place in the space of Databases (so far) at re:Invent 2023. Amazon introduced Amazon ElastiCache Serverless, a groundbreaking serverless option enabling users to create a cache in under a minute and dynamically scale based on application traffic patterns. Compatible with Redis and Memcached, ElastiCache Serverless eliminates the need for capacity planning or caching expertise. It offers fully managed, highly available caches with automatic replication across multiple Availability Zones, providing a 99.99% availability SLA. With a simplified endpoint experience, no upfront costs, and payment for actual resource consumption, ElastiCache Serverless ensures operational excellence. Read more about the release here.

Next, the preview of Amazon Aurora Limitless Database was announced, a groundbreaking capability enabling automated horizontal scaling for processing millions of write transactions per second and managing petabytes of data in a single Aurora database. Unlike traditional read replicas, Limitless Database scales write throughput and storage capacity independently, supporting high-scale applications without the complexity of managing data across multiple instances. The two-layer architecture includes shards for parallel processing and transaction routers for managing distributed transactions. Users can sign up for the preview in select AWS regions, experiencing the power of Aurora Limitless Database for high-performance and scalable applications. Read more about the release here.

Lastly, AWS dives into the world of the IBM Db2 database! IBM and AWS collaborated to introduce Amazon RDS for Db2, providing a fully managed Db2 database engine on AWS infrastructure. IBM Db2, renowned for its enterprise-grade features, scalability, and security, is widely used for managing data-intensive workloads. Amazon RDS for Db2 simplifies database management, offering features such as fully managed infrastructure, automatic backups, high availability, and scalability. Users can create Db2 databases effortlessly through the AWS Management Console, CLI, or SDKs, allowing AWS to handle infrastructure complexities. The service supports existing applications seamlessly, offering a choice of storage types and flexible scaling options. The preview of Amazon RDS for Db2 is available in various AWS regions but users must bring their own Db2 license. Read more about the release here.

Developer Tools

Let's take a look at another capability of Amazon Q. Amazon introduced new generative AI capabilities in Amazon CodeCatalyst, focusing on feature development acceleration through Amazon Q. The feature development capability in Amazon Q aids in expediting software development tasks, such as adding comments, refining issue descriptions, generating classes and unit tests, and updating workflows. Developers can move from idea to fully tested, merge-ready code with natural language inputs. Amazon Q handles the heavy lifting by converting human prompts into actionable plans, generating code, unit tests, workflows, and summarizing changes in pull requests. Developers can provide feedback to Amazon Q on published pull requests and request new revisions. Read more about the release here.

Generative AI / Machine Learning

re:Invent 2023 is Gen AI heavy. Amazon introduced Amazon Q, a generative AI-powered assistant for business users. Amazon Q streamlines tasks, aids decision-making, and fosters creativity by connecting to company information repositories, code, data, and enterprise systems. Tailored user-based plans ensure pricing and features align with individual needs, and Amazon Q adapts interactions based on users' existing identities, roles, and permissions. The AI assistant operates without using customers' content for model training, ensuring data security and privacy. Amazon Q supports over 40 built-in connectors for popular data sources and enterprise systems. Read more about the release here.

Next, let's look at improvement to Amazon Bedrock. Amazon announced Guardrails for Amazon Bedrock (in preview), allowing users to implement safeguards for generative AI applications to promote responsible AI interactions. As part of AWS's commitment to responsible AI development, Guardrails enable users to define denied topics and content filters, adding an extra layer of control to enhance safety and align applications with company policies. The key controls include:

1. Denied Topics: Users can specify undesirable topics for their applications, providing natural language descriptions. For example, a banking application could avoid providing investment advice.

2. Content Filters: Configurable thresholds for harmful content across hate, insults, sexual, and violence categories. Guardrails provide additional controls beyond built-in protections to filter interactions based on user-defined degrees.

3. PII Redaction (Upcoming): Users will soon be able to select personally identifiable information (PII), such as name, email address, and phone number, for redaction in responses or block user input containing PII.

Guardrails for Amazon Bedrock integrate with Amazon CloudWatch for monitoring and analysis of inputs and responses violating defined policies. Users can apply these guardrails to innovate safely while adhering to responsible AI goals. Read more about the release here.

Security, Identity, & Compliance

I am excited to see further updates to AWS Control Tower, the best way to manage your Landing Zone within AWS. AWS has introduced 65 purpose-built controls within AWS Control Tower to help users meet digital sovereignty requirements. AWS Control Tower allows users to set up and govern secure, multi-account AWS environments efficiently. The new controls support data residency, granular access restriction, encryption, and resilience. Examples of added controls include Operator access, controlling access to data, and encryption at rest and in transit. AWS Control Tower provides a consolidated view of enabled controls, compliance status, and evidence across multiple accounts, helping users manage digital sovereignty needs. Read more about the release here.

Amazon GuardDuty has introduced ECS Runtime Monitoring to detect potential runtime security issues in Amazon Elastic Container Service (ECS) clusters running on AWS Fargate and Amazon EC2. GuardDuty uses machine learning, anomaly detection, network monitoring, and malicious file discovery to identify threats. ECS Runtime Monitoring detects runtime events such as file access, process execution, and network connections, providing over 30 different finding types. It uses a managed and lightweight security agent for individual container runtime behaviors, and when used with AWS Fargate, the agent is automatically managed by AWS. Findings are visible in the console, and GuardDuty can send them to AWS Security Hub, Amazon EventBridge, and Amazon Detective. Amazon Detective now receives security findings from GuardDuty ECS Runtime Monitoring to aid in analysis and investigations. Read more about the release here.

Serverless

AWS Lambda has improved its scaling capabilities, allowing each synchronously invoked Lambda function to scale by 1,000 concurrent executions every 10 seconds. This occurs until the aggregate concurrency across all functions reaches the account's concurrency limit. The update ensures that each function within an account scales independently, regardless of how the functions are invoked, enhancing scalability for highly variable traffic and reducing the impact of noisy neighbor scenarios. Read more about the release here.

Storage

Amazon introduced the Amazon S3 Express One Zone storage class, aiming to provide up to 10 times better performance than the S3 Standard storage class. This new storage class is designed for frequently accessed data and demanding applications, delivering consistent single-digit millisecond latency while handling hundreds of thousands of requests per second. Objects are stored and replicated within a single AWS Availability Zone, allowing co-location of storage and compute resources to reduce latency. With very low latency, especially beneficial for smaller objects, and 50% lower request costs compared to S3 Standard, the Express One Zone storage class is suitable for data-intensive applications such as AI/ML training, financial modeling, media processing, and more. I guess it remains to see this in action. Read more about the release here.

To be continued...

Strap in for the second half – the stage is set for more revelations, connections, and the uncharted terrain of possibilities that lies ahead!

In this article we are not going to discuss K8s infrastructure and the applications. You can find all this information in the original article referenced above. In the attempt to rewrite code in Go that would produce very similar output to my original project in Python, I stumbled upon several challenges. I would like to share this journey with you and hopefully help anybody who is interested in getting started with the AWS CDK in combination with the Go language.

Project Structure

There are several examples one can find online on writing Infrastructure as Code (IaC) using the AWS CDK and Go. All of these examples are focused on a single stack solutions that deploys very limited amount of resources. These examples can be very helpful when trying to identify how you can get started with the AWS CDK and the Go language. For me, starting to work on an IaC project that would potentially would end up having a high number of resources, it is very important to structure the solution accordingly. AWS for several years now supports the concept of Nested Stacks. I believe, it is of paramount importance for any production grade project of non trivial complexity on AWS to take advantage of Nested Stacks.

While looking around for best practices of how one would structure an AWS CDK project in Go, to my surprise I could not find any information other than single file - single stack examples. I would like to share with you here my two cents on how I would structure any complex IaC project.

Folder Structure

With the idea in mind that I would use many Nested Stacks and different configurations per deployed environment (I have written a separate article on this which can be found here), this would be a boilerplate of how the folder structure should look like:

├── charts/
 │   ├── cdk8s-chart-1.go
 │   ├── cdk8s-chart-2.go
├── config/
 │   ├── development.yaml
 │   ├── test.yaml
 │   ├── acceptance.yaml
 │   ├── production.yaml
├── helper/
 │   ├── helper-functions-1.go
 │   ├── helper-functions-2.go
├── stacks/
 │   ├── nested-stack-1.go
 │   ├── nested-stack-2.go
 │   ├── nested-stack-3.go
├── cdk.context.json
├── cdk.json
├── parent-stack-main.go
└──

Go Packages

Go is renowned for its simplicity and ease of use, and one of the fundamental ways it achieves this is through its package system. Packages play a pivotal role in structuring and organizing Go code, making it modular, reusable, and maintainable. They provide a mechanism for code encapsulation, collaboration, and code reusability, which are crucial aspects of any programming language.

The primary purpose of Go packages is to create logical and self-contained units of code that can be imported and utilized in other parts of the application. These packages act as containers for related functions, types, variables, and other components that collectively solve a specific problem or provide a certain functionality.

With the aforementioned folder structure in mind, the application could be split into 4 packages:

• main

• charts

• helper

• stacks

More packages could also be used, for example if someone would want to separate the nested stacks further. The above 4 packages would be the minimum recommended.

Passing values between stacks

Most of the languages supported by the CDK family of frameworks are employing Object Oriented Programming (OOP) concepts. Although not all of them are pure OOP languages, the concepts behind object-oriented software deployment apply: You can split (nested) stacks in classes and you can expose resources and values by making them publicly available in your application.

Go is not an OOP language. How could you share then resources between stacks?

You can make them available as return values of the stack functions.

Let's assume you want to create a NetworkingStack that creates and shares the VPC with all the other Nested Stacks. How can you achieve this in Go?

Let's create a networking-stack.go file within the stacks/ folder. The contents of the file should looks like this:

package stacks

import (
    "github.com/aws/aws-cdk-go/awscdk/v2"
    "github.com/aws/aws-cdk-go/awscdk/v2/awsec2"
    "github.com/aws/constructs-go/constructs/v10"
    // https://docs.aws.amazon.com/sdk-for-go/api/aws/
    "github.com/aws/aws-sdk-go-v2/aws"
)

type NetworkingNestedStackProps struct {
    awscdk.NestedStackProps
}

func NetworkingStack(scope constructs.Construct, id string, props *NetworkingNestedStackProps) (awscdk.NestedStack, awsec2.IVpc) {
    var nsprops awscdk.NestedStackProps
    if props != nil {
        nsprops = props.NestedStackProps
    }
    stack := awscdk.NewNestedStack(scope, &id, &nsprops)

    vpc := awsec2.NewVpc(stack, aws.String("sample-vpc"), 
        &awsec2.VpcProps{
            IpAddresses: awsec2.IpAddresses_Cidr(aws.String("10.0.0.0/16"),
            SubnetConfiguration: &[]*awsec2.SubnetConfiguration{
                {
                    CidrMask: aws.Float64(28),
                    SubnetType: awsec2.SubnetType_PUBLIC,
                    Name: aws.String("public"),
                },
                {
                    CidrMask: aws.Float64(28),
                    SubnetType: awsec2.SubnetType_PRIVATE_WITH_EGRESS,
                    Name: aws.String("private"),
                },
            },
        },
    )

    return stack, vpc
}

As you can see, the NetworkingStack defines to return values. One is of type awscdk.NestedStack and the other of type awsec2.IVpc. Finally, in the bottom, both values are returned with the return stack, vpc statement.

In the main() function then, we can instantiate a new stack that we want to pass the value of the Vpc. We can do that as follows:

package main

import (
    "parent-stack-main/stacks"
         ...
)

func main() {
    defer jsii.Close()

    app := awscdk.NewApp(nil)

         stack := NewParentStack(app, "NewParentStack", &NewParentStackProps{...})

    _, nsvpc := stacks.NetworkingStack(stack, "NetworkingStack", nil)
    stacks.MyNewNestedStack(stack, "MyNewNestedStack", &stacks.MyNewNestedStackProps{
        Vpc: nsvpc,
    })

    app.Synth(nil)
}

Conclusion

You can find the whole codebase that replicates the solution described in "Managing K8S Infrastructure and Applications on AWS" rewritten in Go in GitHub. By comparing the Python and the Go implementation, you can further identify differences and solutions on how you can implement the same functionality but in these different high level programming languages. I hope you find this useful to get you going in the world of AWS CDK using Go.

Main image by svstudioart on Freepik

*This article was originally posted here.

From a programming perspective, there are several key technologies and practices involved in effectively managing multiple environments using IaC.

Let's explore them:

• Configuration Management Tools: Configuration management tools such as Ansible, Chef, or Puppet are commonly used in IaC to automate the provisioning and configuration of infrastructure resources across multiple environments. These tools allow you to define infrastructure configurations as code using a declarative or imperative language. By defining and maintaining infrastructure configurations in a centralized manner, you can easily manage and replicate them across different environments.

• Infrastructure Provisioning Tools: Infrastructure provisioning tools like Terraform or AWS CloudFormation and the Cloud Development Kit (CDK) enable you to define and provision infrastructure resources programmatically. These tools use domain-specific languages (DSLs) or configuration files to describe the desired state of your infrastructure. With these tools, you can define resources such as virtual machines, networks, storage, load balancers, and more, and deploy them consistently across multiple environments with a single command.

• Version Control Systems: Version control systems, such as Git, play a crucial role in managing Infrastructure as Code. By keeping infrastructure configurations and provisioning scripts under version control, you can track changes, collaborate with teammates, and easily roll back to previous versions if necessary. Version control systems also enable you to manage different branches or environments, allowing you to develop and test infrastructure changes in isolation before merging them into production.

• Environment Variables and Parameterization: To accommodate different configurations for each environment, it's essential to leverage environment variables and parameterization techniques. These techniques allow you to define reusable infrastructure templates and dynamically inject environment-specific values during the deployment process. For example, you can use variables to specify the number of instances, network configurations, or credentials for each environment, making it easier to manage and scale environments with minimal manual intervention.

• Continuous Integration and Deployment (CI/CD) Pipelines: Implementing CI/CD pipelines is crucial for managing multiple environments using IaC. CI/CD pipelines enable the automation of build, test, and deployment processes, ensuring consistent and reliable deployments across environments. By integrating your infrastructure code into the CI/CD pipeline, you can trigger infrastructure updates or deployments automatically whenever changes are made, reducing manual intervention and minimizing errors.

Diving more into the Environment Variables and Parameterization concept while focusing on the AWS CDK, YAML could be used to manage the configuration of multiple environments within a single codebase. But why YAML?

There are a couple of reasons why to use YAML for managing multiple environments within the AWS CDK:

1. Simplicity and Readability: YAML provides a simple and human-readable syntax, making it easier for developers, DevOps engineers, and stakeholders to understand and work with the configuration of infrastructure code. The indentation-based structure of YAML makes it intuitive to define resource configurations and relationships, reducing complexity and providing a single configuration pane per environment.

2. Integration with AWS CDK: The AWS CDK can integrate with YAML files, by sense of parsing the YAML files and storing the information in native data structures that can hold key-value pairs.

Assuming an AWS CDK project in any language, let's consider the following structure for our environments' configuration:

├── config
│   ├── development.yaml
│   ├── test.yaml
│   ├── acceptance.yaml
│   ├── production.yaml
└──

For AWS, the contents of each file would typically include a minimum of at least the Account ID, Region and in case we are creating VPCs the CIDR block that will be used for each environment.

account_id: '123456789'
region: eu-west-1

cidr: 10.0.0.0/16

Let's see how we can parse the previous information per environment by diving into the details of how to implement this in the AWS CDK using Python and Go.

Defining the environment

When synthesizing and deploying AWS CDK code, we can pass runtime context. Context values are key-value pairs that can be associated with an app, stack, or construct. They may be supplied to your app from a file (usually either cdk.json or cdk.context.json in your project directory) or on the command line. More information about runtime context for the AWS CDK can be found here.

For example you can synthesize our CDK project using the following command:

cdk synth --context environment=development

The above will synthesize CloudFormation code while also passing to the CDK app the key-value pair environment: development.

We will use this approach to define the environment we want to synthesize or deploy to. This can be configured for each environment in a potential CI/CD pipeline that will be used to deploy your Infrastructure.

Parsing YAML configuration in the AWS CDK for Python

Let's start by creating a configuration parser. For this we will create a helper/config.py file and create a Config class. An example implementation of such class can be seen below.

import yaml
from yaml.loader import SafeLoader

class Config:

    _environment = 'development'
    data = []

    def __init__(self, environment) -> None:
        self._environment = environment
        self.load()

    def load(self) -> dict:
        with open(f'config/{self._environment}.yaml') as f:
            self.data = yaml.load(f, Loader=SafeLoader)
        return self.data

    def get(self, key):
        return self.data[key]

By leveraging the context we discussed earlier, we can then instantiate our CDK stack in the app.py as follows.

from helper import config

conf = config.Config(app.node.try_get_context('environment'))
stack = NameCdkStack(app, "NameCdkStack",
    env=cdk.Environment(account=conf.get('account_id'), region=conf.get('region')),
)

Similar to the above we can parse all other values that we want to store in the configuration, including the CIDR block.

Parsing YAML configuration in the AWS CDK for Go

Similarly to the Python example, we will create a Config function, our configuration parser. For this we will create a helper/config.go file and create there our Config function. An example implementation of such class can be seen below.

package helper

import (
    "gopkg.in/yaml.v3"
)

type conf struct {
    AccountID string yaml:"account_id"
    Region    string yaml:"region"
    CIDR      string yaml:"cidr"
}

func Config(yamlFile []byte) conf {
    var c conf
    yaml.Unmarshal(yamlFile, &c)

    return c
}

By leveraging the context we discussed earlier, we can then define our CDK stack in the name-cdk.go as follows.

package main

import (
    "io/ioutil"
    "name-cdk/helper"
    "log"
    "reflect"

    "github.com/aws/aws-cdk-go/awscdk/v2"
    "github.com/aws/constructs-go/constructs/v10"
    "github.com/aws/jsii-runtime-go"
)

...

func main() {
    defer jsii.Close()

    app := awscdk.NewApp(nil)
    // get environment from context
    envName := app.Node().GetContext(jsii.String("environment"))

    NameStack(app, "NameStack", &NameStackProps{
        awscdk.StackProps{
            Env: env(reflect.ValueOf(envName).String()),
        },
    })

    app.Synth(nil)
}

func env(environment string) *awscdk.Environment {
    return &awscdk.Environment{
        Account: jsii.String(config.AccountID),
        Region:  jsii.String(config.Region),
    }
}

Conclusion

Using YAML can simplify a lot common configuration tasks that need to be done in your AWS CDK codebase without the need to touch the code while at the same time maintaining all the configuration within the same repository in a convenient format. You can use the code snippets shown above to get started within your implementation of the AWS CDK.

Image by vectorjuice on Freepik.

*This article was originally posted here.

How can we manage K8s infrastructure and applications using one codebase and high level programming languages?

In the coming paragraphs, we will identify how we can write Infrastructure as Code (IaC) as well as the K8s workload definition for an application that will be deployed on AWS. We will combine the power of AWS CDK and cdk8s in one single codebase to deploy our infrastructure and application.

Declarative vs Imperative approach for IaC

Before we proceed further, let’s first identify the various ways you can write infrastructure as code and the major differences between the imperative and declarative way of working.

Declarative and Imperative approach for programming are two different concepts of developing and delivering code. We will take a closer look at:

• Main differences between the two approaches, only focusing on IaC.

• Are we really doing it right?

• Dive in the specific case of AWS and see the strengths of Terraform over AWS CDK and vice versa.

There are various tools one can use to write IaC. To name a few well known options:

• YAML

• Crossplane

• pulumi

• Terraform

• AWS CDK

So what is the difference between the declarative and the imperative approach and how do the above options fit in?

Declarative approach

The declarative approach focuses on the “what” of the infrastructure. With a declarative approach, you define the desired end-state of the infrastructure without specifying how to get there. This means that you only need to specify what resources you want to create, configure, or delete. Declarative IaC tools include languages like YAML, JSON, and HCL.

Imperative approach

Focuses on the “how” of the infrastructure. With an imperative approach, you write step-by-step instructions for provisioning and configuring resources. This means that you need to define every step required to create and configure the infrastructure. Imperative IaC tools include scripts written in languages like Bash, PowerShell, or Python.

Terraform VS AWS CDK

Let’s focus for a moment on 2 of the options mentioned above that have most of the markete share in terms of deploying infrastructure in AWS. So what are the differences?

Language and Syntax

Terraform uses its own declarative configuration language (HCL) that is designed to be cloud-agnostic, while AWS CDK allows you to define infrastructure using familiar programming languages like Python, TypeScript, Java, C#, and Go. This means that with AWS CDK, you can leverage the full power and expressiveness of a programming language to define your infrastructure, whereas with Terraform, you use a dedicated configuration language.

Abstraction Level

Terraform provides a higher level of abstraction, allowing you to define infrastructure resources, providers, and modules in a more abstract and cloud-agnostic way. This means that you can use Terraform to manage resources across multiple cloud providers, not just AWS. AWS CDK is specifically designed for provisioning AWS resources and provides a more AWS-centric approach, with AWS-specific constructs, libraries, and APIs that allow you to define AWS resources in a more native way.

Deployment Model

Terraform follows a declarative model, where you define the desired state of your infrastructure and Terraform handles the details of how to achieve that state. Changes to infrastructure are managed by updating the Terraform configuration and applying the changes. AWS CDK, on the other hand, follows an imperative model, where you define the infrastructure using programming code and changes are made by updating the code and redeploying the CDK app. This means that with AWS CDK, you have more flexibility in terms of defining complex logic and dynamic behavior, but it may require additional coding and testing compared to Terraform.

Learning Curve and Familiarity

Terraform’s HCL syntax is designed to be simple and easy to learn, with a configuration-based approach that is familiar to many operations and infrastructure teams. AWS CDK, being a programming-based approach, requires developers to have knowledge and experience with programming languages, which may be an advantage or disadvantage depending on your team’s skill set and preferences.

Is Terraform truly declarative?

The lifecycle meta-argument in Terraform is considered imperative, as it allows you to specify certain lifecycle configuration settings for a resource, which affect how Terraform manages the resource during updates or deletes.

The provisioner meta-argument in Terraform is considered imperative, as it allows you to define actions that are performed on a resource after it has been created or updated, typically used for configuration management or bootstrapping tasks.

Is the AWS CDK truly imperative?

You can actually use the AWS CDK in such a way that the complete codebase will be declarative by avoiding imperative declarations.

Ini the following example, the definition of the S3 bucket can be considered declarative.

Terraform VS AWS CDK (again)

All the above are just a matter of definitions. The choice between Terraform and AWS CDK depends on your specific requirements, preferences, and team’s skill set. Both tools are powerful and widely used in the industry, and they offer different approaches to defining and managing cloud infrastructure as code.

Managing K8s infra and applications on AWS with the AWS CDK and cdk8s

You would typically deploy K8s in the following way: – Create infrastructure using IaC or in any other way. – Define your K8s workload (pods, deployments, statefulsets, etc) using Yaml. – Create your images using Docker. – Configure your cluster with kubectl and deploy.

K8s configuration has always been a declarative paradigm, but then again so has been IaC in its early stages.

Let’s consider the following challenge. We want to: – Deploy K8s infrastructure on AWS using AWS CDK. – Define K8s workload using cdk8s. – Use a single codebase – Use a single step deployment for the infrastructure and the K8s workload on AWS EKS for all the above.

The above use case does not describe a better or preferred way of working with IaC and K8s workload definitions, rather just showing an alternative way of approaching this topic.

Target infrastructure

The target infrastructure we will try to deploy can be seen in the following diagram:

Create you AWS CDK project

We will be creating our AWS CDK project using python. The intention is to create a “template” project that can be reused when someone wants to get starts on AWS using K8s. The same approach can be taken to create similar “templates” in the other programming languages that are supported by the family of the CDK projects.

cdk init app --language=python

More information on getting started with the AWS CDK can be found here.

Define your AWS resources

As per the design shown above, we need to create the following components in AWS:

• The network infrastructure

• An EKS cluster

Network

For the network, we will eb creating a VPC along with its surrounding resources. We will be using the ec2.Vpc level 2 construct.

Please find the implementation below.

from aws_cdk import (
    NestedStack,
    aws_ec2 as ec2,
)
from constructs import Construct
from helper import config

class NetworkingStack(NestedStack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        conf = config.Config(self.node.try_get_context('environment'))

        self.vpc = ec2.Vpc(self, "k8s-sample-vpc",
            ip_addresses=ec2.IpAddresses.cidr(conf.get('cidr')),
            subnet_configuration=[
                ec2.SubnetConfiguration(
                    name = 'public',
                    subnet_type = ec2.SubnetType.PUBLIC,
                    cidr_mask = 28
                ),
                ec2.SubnetConfiguration(
                    name = 'eks',
                    subnet_type = ec2.SubnetType.PRIVATE_WITH_EGRESS,
                    cidr_mask = 26
                )
            ],
        )

EKS cluster

For the EKS cluster, we will be using the eks.Cluster level 2 construct.

Please find the implementation below.

from aws_cdk import (
    NestedStack,
    aws_eks as eks,
    aws_ec2 as ec2,
    aws_iam as iam
)
from constructs import Construct
from helper import config
from aws_cdk.lambda_layer_kubectl_v25 import KubectlV25Layer

class EKSStack(NestedStack):

    def __init__(self, scope: Construct, construct_id: str, vpc: ec2.IVpc, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        conf = config.Config(self.node.try_get_context('environment'))

        self.cluster = eks.Cluster(
            self, 'k8s-sample-cluster',
            version=eks.KubernetesVersion.V1_25,
            kubectl_layer=KubectlV25Layer(self, "kubectl"),
            alb_controller=eks.AlbControllerOptions(
                version=eks.AlbControllerVersion.V2_4_1
            ),
            default_capacity=0,
            vpc=vpc,
            vpc_subnets=[
                ec2.SubnetSelection(
                    subnet_group_name='eks'
                )
            ]
        )

        self.cluster.add_nodegroup_capacity(
            'eks-nodegroup',
            instance_types=[ec2.InstanceType('t3.large')]
        )

        # importing an existing user
        admin_user = iam.User.from_user_arn(
            self, 'imported_user',
            user_arn='arn:aws:iam::970059968789:user/iam_user' # change me
        )
        self.cluster.aws_auth.add_user_mapping(admin_user, groups=["system:masters"])

The level 2 construct for creating an EKS cluster creates a few important resources for the integration with cdk8s. Namely, 2 lambda functions are deployed together with the cluster:

• KubectlHandler is a Lambda function for invoking kubectl commands on the cluster.

• ClusterHandler is a Lambda function for interacting with EKS API to manage the cluster lifecycle.

See below for the architectural design of the eks.Cluster level 2 construct.

Integrating cdk8s into the AWS CDK project

In order to start using cdk8s, we need to perform the following changes in the AWS CDK project.

• In the requirements.txt, we need to configure the following 2 libraries:

  • cdk8s

  • cdk8s-plus-25 ¹

• Create a folder (e.g. k8s_full_stack_charts) on the root level of the project that will hold you cdk8s charts. Create your chars within that folder as classes that inherit from the cdk8s.Chart class.

Example chart used in this project:

import cdk8s as cdk8s
import cdk8s_plus_25 as kplus

from constructs import Construct

class SampleChart(cdk8s.Chart):
    def __init__(self, scope: Construct, id: str):
        super().__init__(scope, id)

        nginx_deployment = kplus.Deployment(
            self, 'sampleDeployment',
            replicas=1,
            containers=[
                kplus.ContainerProps(
                    image='nginx:mainline-alpine',
                    port=80,
                    security_context=kplus.ContainerSecurityContextProps(
                        ensure_non_root=False,
                        read_only_root_filesystem=False
                    )
                )
            ],
            security_context=kplus.PodSecurityContextProps(
                ensure_non_root=False
            )
        )

        nginx_deployment.expose_via_service(
            service_type=kplus.ServiceType.LOAD_BALANCER
        )

• Use the add_cdk8s_chart of the eks.Cluster class to deploy the chart on the EKS Cluster. The deployment will use the KubectlHandler lambda function for executing the relevant kubectl commands.

Example:

from aws_cdk import (
    NestedStack,
    aws_eks as eks
)
import cdk8s as cdk8s
from constructs import Construct

class EKSApplicationStack(NestedStack):

    def __init__(self, scope: Construct, construct_id: str, cluster: eks.ICluster, chart: cdk8s.Chart, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        cluster.add_cdk8s_chart(
            'sample-chart',
            chart,
            ingress_alb=True,
            ingress_alb_scheme=eks.AlbScheme.INTERNET_FACING,
            prune=True
        )

Final thoughts

This way of deploying K8s clusters together with the workload can be really useful in ephemeral clusters. It could also be useful for teams that are proficient with high level programming languages to bundle infrastructure and workloads together using the same high level programming language of their choice.

You can find the complete solution for everything discussed above in GitHub. You can use it as a started template for deploying K8s clusters on AWS together with managing the application in one repository. Next steps would include adding extra templates in the aforementioned repository in the other languages supported by the CDK frameworks family.

Main image by svstudioart on Freepik

[1]: The name/version of this library depends on the K8s version used for the EKS Cluster. In this case we are using K8s version 1.25.

*This article was originally posted here.

On the other hand, AWS ElastiCache for Redis offers a fully managed platform that makes it easy to deploy, manage, and scale a high performance distributed in-memory data store cluster. It is fully compatible with the usual Redis data structures, APIs, and clients, allowing your existing applications that already use Redis to start using ElastiCache without any code changes. It supports both Redis cluster and non-cluster modes, providing enhanced high availability and reliability, with automatic failover scenarios across availability zones.

Getting Started

Upon release, MemoryDB became available in US East (N. Virginia), EU (Ireland), Asia Pacific (Mumbai) and South America (Sao Paulo). MemoryDB clusters can be created using the AWS Management Console, AWS Command Line Interface (CLI), or AWS SDKs. CloudFormation support did not come out of the box with MemoryDB unlike other recent service releases from AWS. This means that we will have to wait before we can deploy MemoryDB clusters with CloudFormation and the AWS CDK.

There are several screenshot walkthrough guides out there to get you through setting up a MemoryDB cluster in the console. Below you can find a CLI command for getting you up and running quickly with a Cluster.

aws memorydb create-cluster \
  --cluster-name memorydb-test \
  --node-type db.r6g.large \
  --acl-name open-access \
  --subnet-group-name memorydb-test-subnet-group \
  --security-group-ids <memorydb-test-security-group-id>

A few assumptions:

• memorydb-test-subnet-group refers to a MemoryDB subnet group created with the aws memorydb create-subnet-group command.

• memorydb-test-security-group-id refers to a pre-existing Security Group ID.

Performance

The first questions that popped in my mind when Amazon MemoryDB was released was related to performance. More specifically, how does Amazon MemoryDB for Redis compare with Amazon ElastiCache for Redis. Can you get the same performance out of the more robust implementation of Redis that was encapsulated around MemoryDB?

In order to give an answer to the above question, the following experiment came to life:

The memtier benchmark tool was used within EC2 to test the performance of both ElastiCache and MemoryDB. For reference, version 1.3.0 was used.

In the table below you can find the various configurations that were used for the experiment.

memtier benchmark was configured as follows:

• A 50/50 Set to Get ratio

• Each object has random data in the value

For comparison purposes exactly the same configuration was used for ElastiCache and for MemoryDB.

You can find the raw data from the test here.

Throughput

In the next plot you can see the throughput performance of the combined Sets and Gets, also refered to as Total Throughput. You can see the results across the 3 different instance types that were used for ElastiCache and for MemoryDB.

From the results it is quite obvious that MemoryDB can deliver less total throughput than ElastiCache across the same instance types. We can also see that when replication is enabled across multiple Availability Zones (AZs) the performance drops even within the same service type. Final remark for this graph is that, taking into consideration the configuration used for the memtier benchmark, performance seems to flatline after the r6g.2xlarge for ElastiCache, comethign that cannot be said for MemoryDB that seems to have increasing performance as we move to the r6g.8xlarge.

Looking at the performance of Sets and Gets separetely, we end up with the followin plots for the throughput, one for the 1 node situation and one with a replication set with 3 nodes.

Without surprise, looking deeper into the Sets and Gets, we get the same remarks as for the Total Throughput. MemoryDB, in that regard, delivers less performance compared to ElasticSearch. The gap seems to be even greater when multiple replicas are used for the shards.

Latency

In the following plot you can see the latency performance of the combined Sets and Gets, also refered to as Total Latency.

MemoryDB is exhibiting considerable latency, at least when it comes to the benchmarking execution set. Only when we are increasing the underlying computing capcity considerably we get results equivalent to ElastiCache. On the hand, ElastiCache seems to be consistent as we go through the different instance types when it comes to latency. Increasing the number of replicas from 0 to 2, the performance increase is less when switching to the r6g.2xlarge from the r6g.large. The above statement is true only for the 99 and 99.9 percentiles.

Below you can see the results for the 1 node scenario split over the Sets and Gets.

Conclusion

It is quite evident that the extra durability of the implementation of Amazon MemoryDB comes at cost of performance that is available with Amazon ElastiCache. Although the results are affected by the configuration that was selected for the benchmarking tool, I believe that they are a good indicator for the expectations we can have in terms of performance from the two services. This means that the two services are different in their offerings and will remain available in the long run and they have distinct use cases.

IP reputation and whitelisting for large scale solutions that have been live for a long time could be a challenge to move away from when considering migrating the underlying infrastructure on AWS.

In this blog, we are not going to discuss the technical process of preparing, provisioning and advertizing IP ranges in AWS. Rather, I want to focus on important design considerations that one needs to make.

Limitations

Before we move on, I would like to consider some important limitations that we need to be aware of.

1. The most specific prefix ones can bring via Bring Your Own IP (BYOIP) is /24.

2. You can’t use the IP addresses that you bring to AWS for one AWS service with another service.

3. You cannot share your IP address range with other accounts using AWS Resource Access Manager (AWS RAM).

Looking at the above, and relating the limitations to actual solutions on AWS, the most specific prefix limitations mean that even if you only need a few EIPs for NAT Gateways, you still need to bring a complete /24.

Furthermore, if you need to use BYOIP with Amazon EC2 as well as with the AWS Global Accelerator, you need to bring a minimum of two /24 blocks, one for each service. After you bring an address range to AWS, it appears in the AWS account as an address pool. When you create an accelerator, you can assign one IP address from your range to it. Global Accelerator assigns a second static IP address from an Amazon IP address range. You need to bring two IP address ranges to AWS if you want both IPs to come from your ranges for your accelerator. This requirement is in place because Global Accelerator assigns each address range to a different network zone, for high availability. This means two /24 blocks are needed just for the AWS Global Accelerator for assigning 2 IPs from your range to it.

Last but not least, the limitation of sharing IP ranges with no other AWS accounts leads to some interesting design patterns for your multi-account AWS solution.

Design Considerations

As per the AWS Well-Architected Framework, account-level separation is strongly recommended for isolating production workloads from development or test workloads. The isolation could go one step forward, with requirements to isolate production workloads, for example due to compliance requirements. It is a good practice to set up multiple accounts as your workloads grow in size and complexity. For reference, a few of the benefits are:

• Opportunity for rapid innovation;

• Better insights on billing;

• Flexibility defining your security controls;

• Convenient adaptation to business processes and requirements.

Bellow, we are proposing a pattern that will help you design your solution around the aformentioned limitations.

In the above design you can see how you can deploy isolated VPCs in various accounts, with all internet traffic routed through a Transit Gateway in a centralized network account. The network account would be the account that holds all the provisioned BYOIP address ranges, with all the NAT gateways having EIPs from that pool.

Moreover, you can see how you can provision Application Load Balancers (ALBs) that leverage the AWS Global Accelerator. As you can see, two more BYOIP address ranges are needed for the Global Accelerator, reaching a total of three ranges required in this simplified example.

By sharing the private subnets using AWS RAM with the network account, it is then possible to create target groups for the ALBs that can have static routes to instances that live within the other accounts. Unfortunately this will not work for Auto Scaling Groups (ASGs) as instance registration to target groups across accounts is not possible. A custom solution using AWS Lambda could solve this limitation.

Conclusion

BYOIP would fit under more advanced network topics and is only part of a handful (relatively) of implementations on AWS. Scarcity of information on this topic requires that best practices are leveraged by implementations that require similar design choices. I hope the above will give you a head start when tackling the BYOIP topic for your projects for the first time.

Those limitations were discussed extensively in the article with title AWS Transit Gateway for connecting to on-premise: A thorough study. In this extension to the original article, we will focus on all the limitations currently in place when trying to deploy a fully backed Infrastructure as Code (IaC) solution leveraging CloudFormation, developed in this particular case with the AWS Cloud Development Kit (CDK).

The main driver of this article is the fact that CloudFormation has limited support in resources specific to the DX and the TGW services, and most importantly the integration between the two. Furthermore, we will not focus on all the potential ways to integrate the solution, rather we will on resources required in order to deploy the solution as it was discussed in the article that was mentioned earlier.

With all this in mind, we will focus on the following three topics:

• Required resources

• Custom CloudFormation resources with the AWS CDK

• Code Reference for the Custom Resources

• Extra pointers

Required resources

In principle, some parts of the solution are not deployed with IaC. A good reason for this is resources that require external verification from 3rd parties, or even resources that appear in the destination account as a result of an external process. One such example are estabilishing Hosted DX Connection with networking partners of AWS.

With the assumption that a DX connection has already been establised and is available in the AWS account, the following resources need to be created for a complete solution.

Custom CloudFormation resources with the AWS CDK

There are several ways to deploy Custom Resouces with the AWS CDK. The CDK itself has a mini-framework for developing custom resources. For more information, you can look in the documentation of the CDK here.

The alternative is to define lambda functions for your custom resources and interact with CloudFormation either complete manually, or by leveraging a library that abstracts the calls to CloudFormation. One example is the crhelper library for Python. You can find more information on this here.

In order to define your custom resources using lambda, you need to perform two actions:

1. You need to define and deploy the lambda function that holds the logic for the custom resource.

2. You need to define the custom resource that will leverage the lambda function that was defined above.

A boilerplate of how you can achieve this with the CDK can be found below.

from aws_cdk import (
    aws_iam as iam,
    aws_lambda as lambda_,
    aws_logs as logs,
    core
)

class DirectConnectTGW():
    def __init__(self, scope)
        custom_resource_lambda = lambda_.Function(
            scope,
            '<custom_resource>',
            code=(
                lambda_.AssetCode(
                    os.path.join(
                        os.path.dirname(__file__),
                        '<path_to_source>'
                    )
                )
            ),
            handler='main.lambda_handler',
            runtime=lambda_.Runtime.PYTHON_3_7,
            timeout=core.Duration.minutes(5),
            initial_policy=[
                iam.PolicyStatement(
                    actions=[
                        'lambda:AddPermission',
                        'lambda:RemovePermission',
                        'events:PutRule',
                        'events:DeleteRule',
                        'events:PutTargets',
                        'events:RemoveTargets'
                    ],
                    resources=[
                        '*'
                    ]
                ),
                iam.PolicyStatement(
                    actions=[
                        '<policies_specific_to_the_lambda_code>'
                    ],
                    resources=[
                        '*'
                    ]
                )
            ],
            log_retention=logs.RetentionDays.ONE_YEAR
        )

        dc_gateway_custom_resource = core.CustomResource(
            scope, '<custom_resource_id>',
            service_token=custom_resource_lambda.function_arn,
            properties={
                '<env_var_name1>': '<env_var_value1>',
                '<env_var_name2>': '<env_var_value2>'
            }
        )

Code Reference for the Custom Resources

For the context of this article, the custom resources have been developed using Lambda and the code is utilizing the crhelper library from AWS. As part of this blog, reference lambda functions written in Python are available here.

Extra pointers

Custom Metric for the BGP session of the TVI

I would like to make a special note in regard to the transit virtual interface and monitoring the BGP session status. Currently, there is no metric available for this. This can be easily achieved by creating a lambda function that will generate a custom metric for you. The following Python snippet showcases a potential way to achieve this.

import boto3
import datetime
import dateutil
import os

def lambda_handler(event, context):
    region_name = os.environ['AWS_REGION']

    dc = boto3.client('directconnect', region_name=region_name)
    cw = boto3.client('cloudwatch', region_name=region_name)

    virtualInterfaces = dc.describe_virtual_interfaces(
        connectionId=event['connectionId']
    )['virtualInterfaces']

    for vi in virtualInterfaces:
        state = None
        if vi['virtualInterfaceState'] == 'available':
            state = 1
        else:
            state = 0

        cw.put_metric_data(
            Namespace='AWS/DX',
            MetricData=[
                {
                    'MetricName': 'BGPStatus',
                    'Dimensions': [{
                        'Name': 'VirtualInterfaceId',
                        'Value': vi['virtualInterfaceId']
                    }],
                    'Timestamp': datetime.datetime.now(dateutil.tz.tzlocal()),
                    'Value': state
                }
            ]
        )

    return True
Integrating the above in your CDK solution could achieved with something like this:

        # Custom Metric for Transit Virtual Interface connection status
        transit_vi_custom_metric_function = lambda_.Function(
            scope,
            'TransitVirtualInterfaceCustomMetric',
            code=(
                lambda_.AssetCode(
                    os.path.join(
                        os.path.dirname(__file__),
                        'transit-virtual-interface-custom-metric'
                    )
                )
            ),
            handler='main.lambda_handler',
            runtime=lambda_.Runtime.PYTHON_3_7,
            timeout=core.Duration.minutes(1),
            initial_policy=[
                iam.PolicyStatement(
                    actions=[
                        'cloudwatch:PutMetricData',
                        'directconnect:DescribeVirtualInterfaces'
                    ],
                    resources=[
                        '*'
                    ]
                )
            ],
            log_retention=logs.RetentionDays.ONE_YEAR
        )

        # the trigger (event) for the Lambda function
        transit_vi_custom_metric_rule = events.Rule(
            scope, 'TransitVirtualInterfaceCustomMetricRule',
            schedule=events.Schedule.rate(core.Duration.minutes(1))
        )
        transit_vi_custom_metric_rule.add_target(
            targets.LambdaFunction(
                handler=transit_vi_custom_metric_function,
                event=events.RuleTargetInput.from_object(
                    {
                        'connectionId': <dx_connection_id>
                    }
                )
            )
        )

        bgp_status_state = cloudwatch.Alarm(
            scope,
            'BGPStatusAlarm',
            metric=cloudwatch.Metric(
                metric_name='BGPStatus',
                namespace='AWS/DX',
                dimensions={
                    'VirtualInterfaceId': <tvi>.get_att_string(
                        'TransitVirtualInterfaceId'
                    )
                },
                period=core.Duration.minutes(1),
                statistic='Maximum'
            ),
            evaluation_periods=5,
            threshold=1,
            alarm_description=(
                f'Alarm for TVI Connection State'
            ),
            comparison_operator=(
                cloudwatch.ComparisonOperator.LESS_THAN_THRESHOLD
            )
        )

Static Routes for the TGW

Deploying static routes within your TGW route table in code can prove benneficial. If you remember from the original article, there is currently a limitation on the number of routes that can be advertised on premise from a DX connection. As an amendment to the original article, I should mention here that it is possible to advertize a superset of the actual CIDR blocks behind the TGW over the DX connection. This can be used to tackle in a way the above limitation by creating supersets instead of advertizing the CIDR bock of each VPC.

The problem that arises when you start using supersets of the CIDR blocks, is that if you are using in conjuction with the DX a VPN connection as a failover, the VPN will advertize via automatic propagation the CIDR blocks of all the VPCs behind the TGW. That will result in a deviation in the CIDR blocks advertized on premise via the DX and the VPN. In order to tackle the above issue, one can inject the TGW route table with superset static routes, exatly as they are advertized via the DX connection.

The following lambda function can help you pick up from tour configuration the manually advertized supersets and inject them in your TGW route table.

import boto3
import logging
import os

def lambda_handler(event, context):
    logger = logging.getLogger()
    logger.setLevel(logging.INFO)

    region = os.environ['AWS_REGION']

    ec2 = boto3.client('ec2', region_name=region)

    cidr_blocks = event['cidr_blocks']
    tgw_route_table_id = event['tgw_route_table_id']

    for cidr_block in cidr_blocks:
        # find all routes that belong in a specific CIDR block or its subnets
        routes = ec2.search_transit_gateway_routes(
            TransitGatewayRouteTableId=tgw_route_table_id,
            Filters=[
                {
                    'Name': 'route-search.subnet-of-match',
                    'Values': [
                        cidr_block,
                    ]
                },
                {
                    'Name': 'attachment.resource-type',
                    'Values': [
                        'vpc',
                    ]
                }
            ]
        )

        # array with the CIDR blocks that were identified
        cidr_blocks_for_routes = (
            [d['DestinationCidrBlock'] for d in routes['Routes']]
        )

        # if a static route does not already exis
        if len(cidr_blocks_for_routes) > 0:
            if cidr_block not in cidr_blocks_for_routes:
                tgw_attachements = (
                    [d['TransitGatewayAttachments'] for d in routes['Routes']]
                )
                tgw_vpc_attachements = (
                    [d for d in tgw_attachements if d[0]['ResourceType'] in ['vpc']]  # noqa: E501
                )
                # identify attachment id for VPC
                tgw_attach_id = tgw_vpc_attachements[0][0]['TransitGatewayAttachmentId']  # noqa: E501

                logger.info('Creating route for: %s' % str(cidr_block))

                ec2.create_transit_gateway_route(
                    DestinationCidrBlock=cidr_block,
                    TransitGatewayRouteTableId=tgw_route_table_id,
                    TransitGatewayAttachmentId=tgw_attach_id
                )

    ####################
    # start - cleanup
    # find all static routes to vpcs
    all_static_routes = ec2.search_transit_gateway_routes(
        TransitGatewayRouteTableId=tgw_route_table_id,
        Filters=[
            {
                'Name': 'type',
                'Values': [
                    'static',
                ]
            },
            {
                'Name': 'attachment.resource-type',
                'Values': [
                    'vpc',
                ]
            }
        ]
    )

    # array with the CIDR blocks that were identified
    all_cidr_blocks_for_static_routes = (
        [d['DestinationCidrBlock'] for d in all_static_routes['Routes']]
    )

    for cidr_block in all_cidr_blocks_for_static_routes:
        if cidr_block not in cidr_blocks:
            logger.info('Deleting route for: %s' % str(cidr_block))
            ec2.delete_transit_gateway_route(
                DestinationCidrBlock=cidr_block,
                TransitGatewayRouteTableId=tgw_route_table_id
            )
    ####################
    # end - cleanup
    ####################

All the above can be found here together with the CloudFormation custom resources.

Conclusion

Using the TGW to connect the on-premise environment to VPCs on AWS could simplify things a lot. Limitations from CloudFormation could complicate the solution as explained above. I do hope the information provided here and the custom resources that have been shared will help you get going. Knowing AWS, these limitations of CloudFormation should one by one be tackled in future announcements, but for now, this is the state of things.

Example Architecture

To simplify things, I provide below a visual representation of an architecture that we will study for its power as well as the limitations that come from it.

In this example architecture, you see the usage of a TGW to connect the on-premise environment with VPCs that live within different AWS accounts. It also enables those VPCs to talk to each other. The connectivity between on-premise and AWS is facilitated by a DX connection, with a Site-to-Site VPN as a failover.

Associated Resources

In order to achieve the infrastructural setup that is visualized above, one needs to follow the following steps:

1. Request a DX connection of at least 1 Gbps to the relevant AWS Region within the TGW account.

2. Create a DX Gateway.

3. Create a TGW.

4. Create a VPN Customer Gateway and VPN Connections directly to the TGW.

5. Associate the TGW with the DX Gateway. At this point, the allowed prefixes also need to be advertised to the on-premise network.

6. Create a Transit Virtual Interface for the DX Connection-Gateway pair.

7. Share the TGW resource with the relevant AWS Accounts using the AWS Resource Access Manager (RAM) service.

DX Connection – VPN Failover

Once you have everything deployed and working, it is easy to test the failover of the DX Connection over to the VPN. At this point, the TGW Route Table should have at least a DX Gateway and a VPN associated with it. In the AWS Console, you can trigger a Failover test under the Transit Virtual Interface by selecting “Bring down BGP”.

By inspecting closely the TGW Route Table, one can then see the preferred route over the DX Gateway switched to the one that targets the VPN connection.

Limitations of the described solution

DX Connections

Transit virtual interfaces are only available over dedicated connections or hosted connections with speeds of 1 Gbps or greater. Transit virtual interfaces are not available for hosted AWS Direct Connect connections with speeds of 500 Mbps and below, also known as a sub-1 Gbps hosted AWS Direct Connect connection.

Propagation of VPC CIDR blocks to on-premise

When a new VPC is associated with the TGW, the route table of the TGW is automatically updated. In order to advertise the CIDR block of each VPC to the on-premise network though, that requires a manual action. This is related to the allowed prefixes that were mentioned earlier in around the association of the TGW with the DX Gateway. One needs to explicitly update that list to include the new CIDR block. Furthermore, the exact CIDR block needs to be advertised and not a superset of it. For more information you can check here.

Another limitation related to the propagation of CIDR block to on-premise is the fact that the maximum number of allowed prefixes is capped at 20. This means that you can connect to on-premise a maximum of 20 VPCs. This is a major limitation considering the recommendation from AWS to isolate workloads into different accounts and VPCs as much as possible. It becomes an even bigger problem when DTAP comes in the picture.

The last point can be tackled in 2 ways:

1. Follow the DTAP approach also for the TGW implementation and have a Production and a non-Production TGW.
   An example architecture of this is shown below.

   

2. Connect up to 3 TGWs to the same DX Gateway.
   An example abstracted architecture of this is shown below.

   

Both of these solutions are suffering from the same problem; you cannot peer, as of the time of writing this article (August, 2020), TGWs in the same region. The fact that all these TGWs are connected to the same DX Gateway does not create the magic bridge one would hope for. This automatically means that some of your VPCs won’t be able to talk to other VPCs, unless they are associated with the same TGW.

Conclusion

Using the TGW to connect the on-premise environment to VPCs on AWS could simplify things a lot. On the other hand, one needs to carefully plan and execute this solution taking into consideration the growth that is expected for the solution on AWS, in order to avoid hiccups down the road. Knowing AWS, these limitations should one by one be tackled in future announcements, but for now, this is the state of things.