Here is my two cents on the best practice among your solutions:
While developing products, swagger or apiary are great tools to document your API and quickly mock the API before implementing them. With a mock API and documentation in the hands of (say) a product manager, it becomes easy to get started with a solid plan for development. But tools like swagger can auto-mock an API specification and if you wish to import this specification only to mock an API, then this import feature is a great tool to use, otherwise it is not. Let me explain why.
By importing an API and orchestrating AWS resources directly from swagger, you bring in lots of limitations, the primary one being your development process does not include a framework such as serverless or zappa. This would force us to directly write lambda functions using AWS console or AWS cli, and make the project architecture complicated.
In writing lambda functions without a framework, if we know upfront that our functions would be orthogonal to each other and do not share much common dependencies, then great, this would work, but for any project with (say) a database, functions accessing external API, some endpoints being guarded by an authorizer and having other resources, using a framework is definitely the better option. It is easier to create layers and common code, for example a database wrapper class.
When using any framework, it is better to start with the framework boilerplate and make the implementation to match the documentation. By studying the advantages and limitations of that framework, we can decide if it fits our architecture.
Also, IMO, this method is not widely used, and finding help might be tough later on as the project becomes more complex.
hope this helps.
